Gameplay Issues (Oct 24 2025)

While working on the game, I found some issues with the game's design, and I found solutions to most of them.

First is the areas you visit each turn. My original plan was you shuffle a deck of 6 cards, and each card names 2 areas that you visit. But then it just sounded bad, because if one of the cards shows 2 areas you have no cards in, you were screwed. This also meant you can try to remember every single card that's come up so far, and what's left in the deck, and this also seemed bad. Now my solution is: at the start of the game you get 3 tokens for each area. Each turn, you spend 2 of those tokens and visit those areas. When you run out of an area token, you can't visit that area anymore. I think this is clearly better.

It turns out that moving cards around can have rules issues. I have a couple ideas for cards that have abilities when you play another card into the same area as them. But then what happens if card A moves one of those kinds of cards into the same area as card A, does that moved card trigger? I think it has to be a yes there. Then there's moving cards when you visit an area. If visiting an area causes you to move a card from another area to the area you're visiting, does that moved card trigger? It sounds like a yes, but I have to be careful here as it could cause loops (I move a card out of the area, then I move it back, those abilities now trigger infinitely).

Then there's the issue of not having enough control over what cards you play. This is sort of a baked in issue with the whole game of bluffing with face down cards, but for this type of game I think it'll be more apparent because the point is to find combos among your cards. One idea I have is, you start the game with (just one) delay token. When you are about to play a card, you can choose to delay it to the end of the game. Instead of playing it right now, you will play it after all 6 rounds, and afterwards you'll also get another chance to visit an area. This also helps if you play a late-game card super early, as instead of it being bad for you, it could be quite good for you.

Then I think, maybe this player interaction thing where you give cards to another player isn't a good fit at all. It certainly takes a while to resolve (both in deciding what card to put face down, and reading the cards you're given), and I'm sure there will be players who wouldn't enjoy the loss of control (they'd rather just play whatever's in their hand). But I don't want to completely remove it, as it's filling 2 important roles: player interaction (some people are fine with multiplayer solitaire games where you don't interact with other players until you compare scores at the end, but I prefer interaction throughout); and card balancing (the loss of control over what you play means the cards don't need to be as balanced as compared to something like Battery RAM). Which means I would have to find another mechanic that also addresses both issues, and this is difficult.

While I think on this, maybe I will start that new fighting game I mentioned. The one where in phase one you can only do things that affect you, and in phase two you can only do things that affect the other player. A lot of the online stuff I figured out for this game will carry over to that game, so it's not like the past month of work was worthless. And I don't think that game will have any blocking issues, other than making cards.

Improving the Log (Oct 17 2025)

For now I'm going with making a larger-scale game. I ported over some old code for downloading content from spreadsheets, and I'll be using that for card texts and numbers. I'm not going to have the spreadsheets do the card instructions though, since I plan on the cards having a variety of triggers and abilities that would be completely infeasible as spreadsheets. And like before, the spreadsheets will handle translations too.

Most of this week was spent figuring out how to do the log. The log has multiple issues I had to address. The first is that the current way I do log messages is messy. I create a new object for every single message and there's no way that's any good. The reason was because each log message needed to draw a yellow line underneath it in case you can click it for an undo (and undo multiple steps at once), and I didn't see any other way to do that other than having each log message technically be a button. For now I decided to give up on that, and just have it be that the undo button undos your most recent decision and that's it.

Then I had to figure out how else I could do the log. I created a 2nd Unity project just to experiment, and I eventually got something I liked. There are just 4 text objects, except that only 2 are on at once. There's one for: all messages from the past; all messages for the current turn; the most important messages from the past; and the most important messages for the current turn. When a log message is added, the text gets added to all messages from this turn (and if it's tagged as important, it also gets added to most important messages for this turn). Also when you do an undo, it just deletes the most recent line from the text object.

Adding messages to the log is also tricky though. The log has to be recreated for when you reconnect; some log messages have to be different for other players due to publicity (for you it says "draws [card name]" but for other players that card has to be hidden) and translation (in case they're playing with a different language than you). My eventual solution is to send over the text to translate and any variables, and the game goes from there. There is also a check for if it needs to be translated differently for other players. Explaining the full solution here is a bit complicated, but the spreadsheet helps here by having different elements for if information needs to be displayed differently for other players.

Finally when making cards, I realized I needed a way to differentiate the cards that get played into the different areas. I didn't want all cards to be able to do anything, it just seemed like "what area card does this card get played into" is arbitrarily chosen. My solution was to have an ability pie, like in Randomly Generated RPG. The 4 areas are themed: cards that get played to the Coast can make money and move cards; the Village makes money and makes boxes; the City makes money and removes boxes; and the Woods can do everything but make money. I enjoy it when games split up what things can do what, and this division seems solid to me.

Put into Practice (Oct 10 2025)

Progress for this week went well. I got in a bunch of the things I wanted to work on for the new online system, and I think the code is better than ever. You can now draw cards, undo stuff, and confirm when everyone has finished and the game can move onto the next action in the game rules. One optimization is I split up the code more into different scripts, and now the scripts are at more reasonable lengths (it used to be, 2 scripts would go over 1000 lines, now the lengthiest ones are about 500 lines).

I think the only major weakness is that if you disconnect in the middle of your turn and reconnect, you have to click through all your previous decisions again. I think I know a fix for this (it's to keep a track of your decisions with a number, and if you reconnect the game replays the turn for you by applying your past decisions), but I'm putting it off for now as it's not too mandatory.

One new feature is I added a little chat area. It's kind of like a 2nd log, except that the only things that get posted are: notifications for when players join/disconnect/reconnect, and anything that players type into chat. I don't know why I never did this before as it's really easy. I guess I just assumed anyone playing my online games would be in a voice call with anyone they're playing. But putting notifications for if something goes wrong has been useful for me when testing the new system, and it should still be useful to have it in the game.

I still haven't figured out what a simple game could be. Which means maybe I just immediately dive in and make a larger game that uses all of this new code. My choices are either the Pacific-like game, or the 2-player fighting game. Again the first one seems like an easier project.