Changing directions

Things I implemented this week:

• Created + implemented the store UI
• Created and implemented a sort of "Arena"
• Created and implemented a Clicker UI
• Managed to create a system of upgrades, yet still have to define each upgrade and the action they will pull off once bought.
• Managed to finish interactions between enemies, proyectiles and the player.
• Player can now die and lose progress.

What changed since last entry:

General

• The objective of the game is more straightforward for the demo: Collect a certain ammount of 'Score' to click a button and win the game.
• I have implemented a system where a single currency is used for upgrades AND the 'ammo' for the player to be able to shoot inside the arena. This currency has been defined as 'pixels' or rather 'secured pixels'. This same currency is the one used as the same parameter for the player to win the game.

• The previous design for the game was focused on a more static gameplay, where the player stood still on the center as enemies swarmed from different directions. The player could use the mouse and the arrow keys to attack and destroy the enemies that approached. Now, the player has free movement inside an arena and is chased around by the enemies.
• It is planned for the player to keep all upgrades that they buy using the currency, but if the player enters the arena with a low 'secured pixels' number and uses up the ammo until it reaches zero, the player will not be able to shoot its proyectile anymore. 
• A series of upgrades will be divided into two sections: Player Upgrades and Enemy Upgrades . They both will use the same currency, but will focus on the increased difficulty of entering the arena.

Arena

• In order to develop skill-based gameplay and replayability, I have implemented the system where the arena manages two separate 'pixel scores'. One is the 'Secured Pixels' which is used as the 'ammo' and buy currency and the other is the 'Unsecured Pixels'. Unsecured pixels will be gathered up by defeating enemies inside the arena. All enemies will add double (x2) the ammount of weapon shots it needs to be destroyed. (If an enemy only needs for the player to land one shot to destroy the enemy, then two points will be added to the unsecured pixels. If an enemy needs 4 shots to die, it will add 8 points once defeated and so on...).  

• There is no way to convert 'unsecured' pixels into 'secured' ones inside the arena, so if you manage to collect a bunch of them from defeating enemies, but your ammo reaches 0, you won't be able to shoot even though you have added arena score. 

• In order to collect pixels from outside the arena, I have implemented a sort of 'cookie clicker' scene, where the player adds a single pixel for every button press on the clicker.  For now, I haven't looked into being able to provide the player with a clicker multiplier to increase the number of pixels per' click. Playtesting should clear doubts on this.

• If the player dies inside the arena, it will not only lose all of the 'unsecured' pixels, but will also keep the score at the moment of death. Meaning each shot will have consequence in case the player is not skilled enough to exit the arena safely.

• Now, in order to convert 'unsecure' pixels to 'secure' ones, there are two pathways forward in terms of design: 

1. I could develop a sort of 'Find an exit' system where the enemy spawns (in both in speed and dificulty) increase as the player spends more time inside the arena. The 'exit' could be randomized, so each time the player engages with the arena it will not prove repetitive each time. Maybe I could also create some sort of compass to guide the player towards the exit as to not frustrate them.  Although this seems like the most challenging option, I would not like the risk of the rng making the arena engagements unfair or too short.  That's why I also thought of the second option.
2. The arena would become a sort of "survive the wave" type of gameplay, where the player must eliminate a certain ammount of enemies (the ammount of enemies per wave would be randomized in each instance, as well as the chances of tougher enemies spawning on the first waves to not bore the player with weak enemies once they reach an advanced stage) for two gates to appear: One gate provides the option to return to the 'clicker' interface, where the score collected inside the arena will become secured. The other gate, however, allows the player to engage in a new round of enemy waves, but it will drastically increase in difficulty. Of course, the more challenging the enemies, the higher the reward. Maybe I can implement a sort of 'fountain' for the player if he decides to advance into a new set of waves and provide them with the chance to use unsecured pixels to recover HP or have a temporary powerup. 

Current objectives

• Provided this is a demo, I have set my sights on developing a limited ammount of upgrades for the player to be able to buy. Right now, the focus shall be placed on planning these upgrades and playtesting to observe the new necessities the players might encounter as they progress.
• I'd also like to design a couple of simple enemies to add into the arena. The sprites and mechanics MUST be different from one another.
• And even though it's my least favourite part from gamedev, I must look into bettering the UI design. Currently, it looks like garbage. I guess I'll look into improving it if I feel stuck on other aspects.

Current Issues

• As of writing this entry, I have managed to develop an automized list for the Store in the UI that spawns a UIElement "prefab" for each upgrade instance I've developed in code. Even though the way I have created this was surprisingly efficient, there's a memory leak. The way unity UIToolkit works, in order to give a specific command for a specific button, I must subsribe each enabled button to a callback so it won't lose functionality; problem is, callbacks are subscribed to each time the store UI is enabled, but since the callbacks are instantiated for each upgrade integrated on a List index, there is no simple way to Unsubscribe from them once the UI is disabled since the list is unable to be called before the OnDisable method is able to summon each instance on the list to UnregisterCallback all of them. (Actually, as I'm writing this maybe I should summon a method with all of the UnregisterCallbacks and a disable trigger if the player presses the 'close button'? I'll try it out. )
• Another thing to iron out is the enemy Spawns. They are mostly predictable since right now they are only four points attached to the player GameObject. I must either: A) Create a larger area for the enemies to spawn around the player from these four points, B) Randomize spawners inside an area that instantiate enemies if the player is close to them. C) Increase the RNG value from the current spawn points, randomizing the enemy instance position and spawn timer more frequently.  In any case, I think playtesting will come in handy with this.

Final thoughts on entry

As I continue with my developing journey, I encounter one problem after another, but honing my skills and knowledge has actually been paying off. My coding has become faster and I've been able to understand the way Unity works a lot better. Still, I have to keep grinding on my creativity to find ways to code the things I actually want my game to do. Being a solo-dev doesn't really speed things up either. I've managed to show some early builds to my friends and some of them actually got excited enough to want to pitch in, but in reality they can't do much but support me on the art side of things (the game doesn't have all that arsy style anyway) and those that actually know coding and Unity are too busy with school to be a reliable support. For now, I have to keep going as I am. 

Also, making this DevBlog entry was a lot more fun than I expected. It's inspiring to write and read all I've done in these past couple of weeks, as it is useful to have current objectives planned out for the next entry. Anyway, I guess this is is for now. Thank you for reading this far, even though I still have a long way to go.