Posted May 10, 2023 by SKu11zZ
Hello!
This will be the last update for a short period of time. In this update I have added 8 new squares for players to unlock and I have changed the "unlock a square every 20 steps" to "unlock a square every 15 steps" in order to shorten the flow of the game.
The game also has some UI optimizations.
In addition, this article will discuss why I have not changed the core gameplay.
I received a lot of feedback after the last version was released and played by players and it was all very useful and I really agree with the points made. However, I have not included the features in this update that players were expecting from this feedback, and this is because I was faced with a number of technical difficulties that were difficult to solve in a short space of time, which I will explain one by one.
Before I start, I'll describe how my code implements the core functionality of the game, which will help you understand why I couldn't implement what some people suggested. In my code, each hexagon will be divided into three parts, the first being those squares you see in the game that will be hidden at the start of the game and cloned one and placed in the appropriate position when they are spawned. The first part is stored in Prefab Lists. The second part is the actual model of the cube you see on the unlock screen. It corresponds to the hexagon in the first part, and each time you unlock a hexagon, it is added to the Unlocked List, and when you click on it, the game selects a random hexagon clone from the Unlocked List using Random(0, ListLength) and generates it. The third part is the thumbnail image which is used as part of the UI, the one you see when you unlock is the third part. So how does the game know where to place the hexagon? This is actually calculated using maths. Each time you click on the corresponding Ref Hexagon, the game generates a random hexagon in that position. The game itself does not store information about the type of squares that have been generated, nor does it keep track of what squares have been generated where. Now you know the basic logic of how the game works and the logic of the core functions.
Back to the feedback I received (I've excerpted a few of the more representative ones here, but everyone who provided me with feedback, I'm very grateful to them)
1. The first thing is to unlock a biome each time you unlock it (thanks for the feedback from Selina). It's a great idea to make the player feel like they're unlocking a "theme" each time, rather than a separate item. This allows the player to feel more purposeful in their play. But the technical problem that comes with this is that "I have to sort the blocks and each unlock will unlock all blocks in a category". If you remember what I said earlier about the underlying core logic of the game, you'll find this a bit difficult to do. The original game divided each hexagon into three parts, which were stored in the PL, UL and UI. But if I were to unlock one category at a time, this would involve changing the underlying logic of the game and I would need to rewrite the entire core gameplay to do it. This is why I couldn't finish the changes after receiving feedback, as the technical issues and time I faced would not have allowed me to do so.
2. Feedback from Gabby was to add an achievement system or a quest system. For example, after the player has unlocked 3 adjacent ocean cubes, an achievement is unlocked. This could be in the form of a pop-up window or something else. That would be a cool idea too! Players would be motivated by the feeling of completing an achievement and thus be more inclined to keep playing. But let's look at the technical difficulties that exist here. Remember how I said that the game itself doesn't keep track of the type and position of every generated cube? Yes, you can find clones in the view hierarchy on the left side of Unity, but the biggest problem that exists in finding these cubes is how to detect what cubes are around a particular one. And if there's an achievement called "Four in a row is water!" then it means that I have to detect all the square types in a large circle around a square. Every time you click on a step, you have to do this. Not only would this mean an optimization disaster for WebGL, but I'm not sure how to make such a complex detection system. It would also mean rewriting the underlying architecture, as I hadn't designed the game to store information about the position and type of each block.
3. Ember's feedback was about randomness. Ember said that I should control randomness in some form and give the player better prediction and control over hexagons. For example, adding a UI on the left side of the game that shows what colour the next 10 squares will be. I don't need to show the exact squares, but I just need to show the colours. This also retains an interesting randomness to the game, but it is predictable and controllable. I really like the idea that it allows the player to plan the distribution of the colour blocks on the map themselves. But when it comes to discussing technical difficulties, the topic is not as interesting. Again, I need to start by having the game generate 10 random squares, store them in a separate List, and display the type of each square in the UI. This also meant I had to do the cube sorting. Secondly the first hexagon of the List is generated and placed in the appropriate position each time I click on it. And at the end of the List another square is generated at random. This conflicts with my existing generation logic and means that I need to reorganise my entire generation logic, which is unlikely to be done in 4 days. And it involved a huge amount of functionality that I didn't really understand. Learning and doing it in 4 days was just beyond my capabilities.
4. Another way to control randomness was suggested by Tina. She mentioned that I could create a reference system at the origin and the closer I got to a particular direction, the better the chance of generating a particular block or type of block. Just like Minecraft, the probability of birch trees appearing in a particular terrain is increased. But this also involves two difficulties. The first is that my game does not record the player's position based on the origin. It only works out the position of the next hexagon based on the player's current position. The second is that my current approach to calculating a random hexagon is to use Random(min, max) in the Unlocked list to calculate a random value. Changing the probability for each square would make this random system extremely complex, considering that there are currently 18 unlockable squares and 5 initial squares in the game. This means that a separate random function has to be made for each hexagon.
That's all I wanted to discuss in this issue, and I appreciate all the valuable comments and suggestions you've made after playing. However, due to technical constraints and time, many of the excellent ideas and feedback will have to be regretted for now. I've also learned a lot from making this game, and I hope to do better and better in future games!