itch.io

One optimization I think I see: You apply a heuristic by generating all replies for every single possible move.  This is potentially a lot of wasted recursive effort, especially if the first solution we check is valid anyways.  Just what I saw on sight read, I could very well be wrong. Otherwise it looks like a very clean recursive dfs implementation.  Especially compared to my  spaghetti-fied C-like abomination: 

int checkBoard(const int current_player, const int player_count, int player_locations[], int board[16], int depth, Metric &metrics, bool outputResult = false)

Very nice!  You should read through some of the previous posts.  I also made a c++ solver, you may be interested in some of the data aggregation I did.

Love the graphics and sound effects.  Y'all did a great job!

I checked and could not find a single 9 card deck (2 jacks, cards 1-4) that exists where 100% of the permutations have valid solutions (Assuming my code is correct).

Some possible rule changes:

1.  Random Start, end anywhere
   1. Here's a list of valid decks.
      1. https://pastebin.com/addd2RL
         
   2. Invalid decks
      1. https://pastebin.com/VNSREHCQ
   3. Here's a list of every possible solution for the deck -1 4 4 3 3 2 2 1 1
      1. https://pastebin.com/GpyyWJeC
      2. https://pastebin.com/mpdcuqLu
      3. https://pastebin.com/uf1JM63G
   4. All starts are shown in the top left, but since the board wraps that doesn't matter.   
2. Portals
   1. Jacks (or a different card) are wild, and you can teleport anywhere 
   2. Even one jack may allow for more combinations
   3. Need to test this

I know you mentioned that you have your own solo collapsi solver, so apologies if this information is redundant.  

I misread the rules for Shift (not the document's fault), and assumed that the cards re-wrapped around (so when shifting right the rightmost card will be moved all the way to the left.  Still an interesting variant though, I think it combines the new complexity of shift with the compactness of the base game.  Preliminary testing: Averaging 12 million states per game (compared to closer to 1 million per for the non-shift variant.  And also, academically, a 90-10 bias for player 1.  Not confident on any of these numbers, as the additional complexity makes it much harder to verify computationally.  Hoping to do some more work on collapsi, just life getting in the way.  Cheers :)

Sims show 5, but I would say that number comes with caveats.  Here is an example game.

https://pastebin.com/9ceEzqmp

In this game player 1 is guaranteed to win.  Because both players are "perfect," player 2 also knows this, and kinda "gives up."  Or in other words, plays randomly.  But the move on turn 4 is obviously a bad move for p2, because it's a guaranteed loss in one. 

So, if you mean in all cases, then yes, 5 is going to be the least turns until game ends (I couldn't construct a game that purposefully loses faster than that), but that may require a player to lose faster than what may be "normal".

Changing the heuristic so that the bot extends the game as long as it can (more opportunities for a human opponent to make a mistake) is on my to-do list, but will be a slightly more involved change, so I'm putting it off.

Fun fact:  Collapsi has 378,378,000 unique states.  (16!/(4!4!4!2!2!))  This isn't counting the fact that if you shift the board left or right, the board is technically the same due to wrapping.  (I think that's /12, so 31,531,500 but not confident.)

Napkin math says that 30% is far too high for the four surrounding starting cards to be all 1's or 2's
Deck: 1,1,1,1,2,2,2,2,3,3,3,3,4,4.
(four 1, 2 in a row)
(8*7*6*5)/(14/13/12/11)
= 1680/24024 = .069 = 6.9%.
This is an upper bound, since drawing 4 for your surrounding cards in a row is the ideal circumstance.  In almost every other case you will have less than 8,7,6, or 5 1's or 2's left in the deck. 
Simulated:
100,000
p1: 5180 = .0518 = 5.2%
p2: 5168 = .05168 = 5.2%
both: 392 = .00392 = .3%

If your generation has 30% 1's or 2's in all starting positions then I would guess that your generation is wrong.  

https://gpoquiz.itch.io/collapsi

Done now!

Oh, sorry to highjack this thread, but you're linking digital versions in the youtube description?  
https://gpoquiz.itch.io/collapsi
Just in case you hadn't seen it yet.  

I haven't played with the shift rule yet, but really like the concept!  I'm trying to force myself to take a small break from programming, but it will be an interesting challenge!  Adding shift will double the mathematical complexity, and so I may need to even run simulations overnight!  Oh, and then of course adding shift to my digital version when I get around to it.  

My guess is that the shift means that it's much easier to "escape", so like how p2 was favored when the first turn could move anywhere, I would guess p2 is favored in the shift variant.  And for the cards left, I would guess that there may be more cases where there are no collapsed cards left at the end of the game. (aka p2 wins)  Again, just hypotheses.  

All sims are 100,000 games.

I'm happy to have been proven wrong here, it seems like on average, 5.5-6 cards will be uncollapsed by the end of the game, regardless of level of depth.  The standard deviation goes down as depth increases, which is to be expected.  
Oh, and depth here = 1 person's turn, so 3 depth == If i do this, then he does this, then I do this, do i win?

https://gpoquiz.itch.io/collapsi

Finally done!  Let me know what you think, if there are any issues, or if I should change any of the attribution. 

Alternative to alternating or determining randomly: If there is an innate advantage with going first, then the person with the least points can go first, as sort of a comeback mechanic.

Oh, and please don't take any of this as trying to explain your own game to you lol.  Just thinking out loud.

I can definitely do that.  I'm putting the finishing touches on my digital version, but after that I can tweak my base code for whatever metrics you want.  

My initial thoughts on the scoring system:
If I'm understanding the design correctly, you want to reward  the winner of a round for winning quickly?  Or maybe just because score adds some variance that can be fun?  And of course you need the average so you can determine the number of rounds.  I like the idea, but I'm not sure first to X is the best.  Perfect players, (or even possibly adequate players) would have few cards, but new players may make mistakes that end the game much earlier. 

My guess would be that "great" players should average 2-4 cards, and new players may average 4-6 cards (vibes based statistics).

• Low Score Threshold
  • good length for great players
  • too short for new players
• Mid Score Threshold
  • Potentially a good compromise, but potentially not good for anyone
• High Score Threshold
  • good length for new players
  • too long for great players

With that being said, a better system might be highest score in X rounds.  But I know very little about game design beyond my own personal experiences, I would love to hear the full thought process.  

Sorry, another long winded post.  As for your data query.  What parameters would you like?  Perfect play, or a lesser depth?  Or a more complicated set of rules to better simulate human play (Depth 1 perfect play, prioritize higher numbers, prioritize reducing opponent moves, etc.)

As in you personally played against your bot, or you had your bot play against itself?  If just you playing against your bot, I would encourage you to set up bot v bot play and see if there is bias in your algorithm!  Also is your minimax algorithm full depth?  Theoretically you should be able to determine who has a guaranteed win at the start of every game.

Actually sorry, I was misreading my metrics, it seems to be the opposite.  I initially though that reducing p1's options at the start meant that there are less opportunities for a guaranteed win.  But I forgot to account for the fact that p2 also has much fewer options for "escape" on their turn.  

Metrics:

• 10,000 Games
•  56,205,893 end states calculated.
  • .000295 ms/end state 
  • Takes first path found to victory and trims sibling branches
• 50.2% states where p1 wins
• 49.8% states where p2 wins
• 7,803 guaranteed p1 wins
• 2,197 guaranteed p2 wins

Again, this is with no maximum calculated depth aka perfect play.  Thinking 8 turns into the future with generally 4 options each turn is not something possible for most people. 

Also, I was misremembering the original metrics.  Previous bias was actual 37-63~ Anecdotally, when playing against my wife I went second a lot and it felt like I was losing more, but I figured it was a skill issue. (It probably still was)

P1 moves 1, P2 moves 4 is more fair computationally (5193-4807), but of course I'm not saying you should make balance decisions off of this.  Reducing starting options to 4 makes the start of the game less overwhelming, and also having different starting rules for p1 and p2 could overcomplicate a game that excels in its simplicity.  

If anything, my only suggesting would be adding a line like this: 

WIN
The last player able to complete a move wins the game.  For the next game, swap who goes first.

Sorry, that was a long winded post.  But just to reiterate, I'm not trying to tell the designer how to make their game, just thought the data was interesting!
Thanks so much for the game.  (Oh, and if anyone sees this and has experience in c++ or decision trees generally, it would be great if I could get my algorithm peer reviewed for correctness.)

I'm still working on mine.  Should be in a good state soon, just polishing.

That's of course with perfect play, probably not for the average humans playing the game.  

Changing from moving anywhere to having 1 move at the start is great!  I don't know if this was a data backed decision, but my code calculated around a 60% ish advantage for player 1 before, and now it's much closer to 50-50.  (Which offsets the fact that I'm annoyed that I had to change my code ;) ).   Also planning on uploading my own digital collapsi, thank you for the inspiration!

A 'look' command that gives you layout of the room (available directions, interactables) is a must for these types of games.  It's easy to get lost otherwise.

Talking to interact might work better without the leave command.  'talk' to get the options, 'talk #' to select.

up, down, left, right is semi-abnormal text adventures.  NESW is more familiar. (Game also swaps between the terminology, which is confusing.)  

I'm not sure if I missed it, but there needs to be some way to interact with things before you have the proper tools.  For instance, the bat gives no indication of how I should draw it.

The console refreshes after each input, which isn't ideal.

If I have a key, I shouldn't have to use it on a door to open it, it's an unnecessary extra step.

After an item is out of use, it should be removed from inventory.  (gets pretty bloated later on)

Bugs:

You can take an item multiple times in a row.

Running execute on the bat does not check for the ram. (execute id_key anti_hacker_bat works)

Spaces aren't trimmed properly (' go right') fails.

I only gave a mousecord to the tavernkeeper, and still got the password.

After killing Frank (spoiler), inputs stop working, and no other output is produced.  Is this game over?

Otherwise GG's, impressive quantity of writing for the time constraint.  

Ok, so my current time is 3:34.  Basically I found a skip: you can press shift to jump during dialogue, and you can collect 3 pizzas this way.  Beat my time!

Use 7-zip to unzip the gametest_data and download the .exe

Run the exe alongside the unzipped folder.