Project C playtesting build

This devlog is intended to be a sum-up of the entire development process for the playable build of my Project C. It encapsulates all of my thinking, learning, and implementing over the last three weeks, since I didn't do much in the first two weeks (and hence no devlogs - I didn't do anything for gamedev except brainstorming in that time)

Date: 14.05.2025

Activity:

• Came up with idea and general design direction for the game
• Discussed ideas with professor during practicals
• Learned UI Toolkit and other tools, as well as gathered assets for the game from itch.io (in this collection) and Unity Asset Store
• Implemented version of Project C game for playtesting

Notes: 
Going into the course I knew I wanted to make a roguelite style game for my Project C, so I did! However, I didn't know what I wanted it to look like/ which theme and mechanics to choose for it. I talked with the professor about making a roguelite during the practicals, but mostly about the technical details and how to implement them with our current knowledge, where to look for assets, coding patterns etc. To keep the scope reasonable (indeed, with this type of game it is very easy to think up new features and all of them make the game much more fun, even with the simple gameplay mechanics and loop), I decided to go with a pixel art, arcade style game where the player shoots enemies coming at them from two sides so that they can earn money before they die, and can buy upgrades to make it further next time,  eventually beating the game by killing all of the zombies. There are 5 different upgrades for different stats, some being debuffs for the enemies instead of buffs for the player. This is my favorite genre of games, and I really enjoy the pixel art style (for which there are a good number of assets for my use case, even with nice animations) so i made something that I like. For the implementation I had to learn one of the options for the UI, and since we didn't do anything practical with UI (even scripting part 7 was just a set of links to documentation for the different options), I was impartial to all of them, so I just went with the modern one, UI Toolkit. This is the first thing I implemented while learning and getting more comfortable along the way. The fact that the UI Builder is essentially code-free is relatively nice and intuitive to use, but visualizing the layout (e.g. the upgrade menu) to make it easy to implement in the way UI Toolkit is set up was the most challenging part. Setting up bindings, however, requires code (as far as I am aware), and it is just a lot of boilerplate code and a matter of keeping all the interconnected parts straight in your head, but maybe this is down to the way I structured my code as well. Speaking of which, I did my best to keep the code reasonable, which also required a good amount of planning, but in an effort to ship the game in time for playtesting, some corners were cut and separation of concerns in the code took a little bit of a backseat. Still, I believe it is not to the detriment of further development and I should be able to implement playtesters' feedback with little trouble - the core elements appear stable. After doing this project I am much more comfortable and confident with the way gamedev is done in Unity. I got a lot of intuition for the workflow of adding features by watching different tutorials from experienced developers. For example, my favorite pattern is now the Singleton, I have a persistent GameManager singleton that holds different core elements of the game, such as the player/enemy stats, and allows different parts of the code to easily access references to the ones they need without worrying about their implementations. This was particularly useful for the UI that updates stats when an upgrade is bought - the drawing functions simply subscribe to a OnStatChange delegate (actually UnityAction) and do only what they need to do! I also learned how hard it is to balance a game like this, even as simple as this one, a lot of playtesting is needed and probably by different people, so in the end I have what seemed reasonable and fun for me. One note is that the build took forever, mainly at the dreaded linking .js stage, so I am not sure if this is inherent in building for WebGL or if I did something bad with the assets or something similar.. The game is not super polished yet, there are certain major things I would like to add (BG music and sound effects, health bars and hit effects, currency counter in game etc.) if I have the time before the final submission deadline, and probably others that the playtesters will suggest, but I am quite happy with what I made and it is also very fun to me at least.

Invested hours:  

• Learning necessary parts: 4-5h
• Estimated/actual time for development: 8-10h/ closer to 15h

Outcome: 

Playtesting prototype build of the game, available as an HTML embedded WebGL version (attached also build .zip)