Mechanics iterations

For the last few days I focused on iterating on and refining the mechanics and rules (although I haven't yet iterated on actual object scoring). I also got my first batch of player feedback and collated it on my Miro board with speech bubbles:

Restricting tile placement

The biggest change I made to the interaction was restricting the placement of vines so they can no longer overlap. This felt like a huge improvement, as it stops the game from getting cluttered, keeping everything more readable and adding more of a spatial challenge. This includes not placing vines into the ground, and allows me to add other obstacles (e.g. terrain or other objects) in later levels. 

The first fiddly part of this was visualising it to the player so they'd know why they can't place a tile in a particular place. This was the solution I came up with, which isn't perfect but I think communicates the idea enough:

The system has one noticeable flaw right now, which is down to how I calculate the vine collisions: I generate an edge collider from each line renderer. But of course, every tile collides with the vine you're placing it on, and to get around this I added an exception to allow that vine. The side effect of this is that you can technically loop a vine through itself, as long as it's all part of the same line renderer/bezier curve. To get around this I guess I'd need to use the individual contact points and add an exception based on distance of those, but I don't think it's worth doing for prototype.

A bigger problem: how do I know when the game has ended?

This change meant that the player no longer finishes the game by ending all their branches with "finishing tiles" (as I discussed in a previous post). Though I did add an exception that allows such tiles to be placed on otherwise-stuck vine ends, there's no guarantee that the player will get these tiles - this is deliberate: if the player corners themselves with a bad placement strategy, it should be game over.

But how do I now detect when it's game over?

I was initially reluctant to get into this problem as I knew it'd be fiddly, but ultimately decided it was unavoidable. I'm not the best at complicated maths-ing, so I opted for a route using circle colliders. It took around a day to get working properly - when a tile is placed, the system looks at all the open nodes and uses a circle collider to sweep through the possible angles of placement (at 5 degree intervals) to see if a node can be added to or not. If there are no nodes with space for another tile, the game ends.

Here you can see it in action with a debug visualisation - the moving circles are looking for a solution for each node, and they stop moving as soon as they find one (if a circle moves through the complete 180 degrees, it hasn't found a solution).

Sun changes

A piece of feedback I'd had was about the placement of the sun spots making them too unpredictable/difficult to use. I made some changes to the system to try to improve this. Instead of appearing randomly, the player now starts with 3 sun spots. Any time the player uses one to bloom a flower, it moves, or it will move randomly itself after a while. They spawn within the bounding box of the plant, plus an extra margin, and they try to spawn a minimum distance from each other. 

Overall I'm still not happy with it - it seems to work ok when the plant is relatively small, but as the plant grows larger and the bounding box grows, they feel less reachable. I think the best improvement would be to spawn them near open nodes, rather than simply within the plant's bounding box.

Card limits and rewards

Since the game is no longer about completing all your branches with finishing tiles, I needed a new approach to the game mode. For simplicity, the first version gave the player a limited number of deals, and allowed them to win more by reaching certain score thresholds. 

This felt like the right direction, so I built on it further by adding a choice of random bonus rewards each time the player levels up in this way. (For example, they may have the choice of an extra sun spot, a few special tiles, or just adding x more tiles to their stack). I haven't playtested enough yet to make my mind up on these rewards - I need to spend time experimenting with what they are and how they are balanced to see if they can feel like a meaningful choice. If I'm convinced, I'll work on replacing the placeholder UI.

Balancing and tile dealing logic

Throughout this week, I also experimented with adding more intelligence into the card dealing system. For example, the game will not deal you a finishing tile unless you have a certain number of open nodes available (so it will never force you to end the game). It will also "throw a bone" to the player when they're down to their last tiles, by giving them at least one they can use to finish a segment and potentially score enough to continue.

I've kept as many of these configurable in a settings scriptable object as possible, along with moving all the chance curves of the card dealing into the scriptable. I'm not sure how well it's working just yet - I do have more ideas for pieces of logic like this that I think would benefit the game, though.

Ultimately, I'm limited right now by the random approach of the tile dealing code - it selects 3 random tiles at the point of dealing them. I did this initially for simplicity, and because I didn't know what direction it was going in. Now, I suspect a better approach would be to generate the stack in bigger batches, e.g. the first 20 at the start, and then more when the player reaches the next reward or runs out, etc. So instead of saying there's an x% chance of them getting a new branch or a finishing tile this deal, I could say there will always be between x and y of those types of tiles in the stack. It would give much tighter control on, for example, the ratio of branching cards to branch-ending cards. If I continue the project, I'll switch to this system.

Next steps

With all these changes, I haven't yet spent time trying to rebalance the game, so that's a necessary next step. However I also have questions about whether the object scoring rules are still the best route. It feels like there are different challenges going on now with the placement and the rewards mixed in, and it might be that these original rules are no longer ideal, or perhaps even needed at all. I need to take some time to evaluate whether and how to simplify again.

Finally - WebGL woes are over??

Lastly, one of my biggest victories this week is that I was able to upgrade Unity, find a template for WebGL exporting and finally create builds that a) work in Chrome on Big Sur and b) work both embedded and in full screen mode. At some point I may have to go back to my previous projects to create fresh builds, as this is something I have not been able to do with WebGL on itch up until now!

That's all for now - I'm aiming to get the new build up today, so stay tuned!