Farreign - Development Journey

In this devlog, I’ll be summarizing my work on this game apart from what the course provides. The major sections will be

• Game Balancing
• Tutorial
• Tests (EditMode and PlayMode)
• CI-CD

This game was made following this course by CodeMonkey https://unitycodemonkey.com/courses.php?c=builderdefender This in itself has plethora of knowledge, of developing the entire game from scratch and learning awesome things like Writing Clean and Modular Code, ShaderGraphs, Cinemachine and lots more along the way.

Personally, I used this course as a reference and developed things on my own, like first watching the video to get a gist of what needs to be done and then implementing things on my own - taking helps from the video and internet along the way. As a call to fellow game developers, you should also use this methodology when watching tutorials. As Mark from GMTK also specified in this video https://www.youtube.com/watch?v=vFjXKOXdgGo&t=439s, just blindly following tutorials will make you feel like you have learned everything only to come back a month later and realize you have learned next to nothing. So, I’ll be starting with what extra I did along the way and how it benefitted me and impacted the project.

Game Balancing

One of the major challenges I faced was Game Balancing. As a strategy resource management game, balance is of utmost importance. Infact in any game, balance is something that can take lots and lots of time and effort to get it right. So, to handle this I first created a tool which lets me load and save all the parameters that I wanted to change like enemy damage, enemy speed, arrow damage, building construction time for each building type, resources required to construct, resources returned on demolishing, health, minimum closeness of building, resource collection rates and lots more…(meanwhile I had ScriptableObjects to store parameters wherever possible)

Once I had the tool, I started playtesting and iterating. In each iteration, I’d note what went wrong, what didn’t feel good, whether I was way too overpowered or underpowered and then made adjustments for parameters that can change these outcomes. Some sample iterations of my raw notes for Game Balancing :

Alongwith this, the tool saves exact parameters for all the entities so that I can load that in my Scriptable Objects and use the desired set lateron. This exercise requires playtesting, observing and iterating to push the game in the direction you want it to go. And these can even give rise to new mechanics, limitations and early identification of dominant strategies. And as Mark from GMTK has again suggested in one of his videos, this dominant strategy might not always be fun. Infact, given a chance players can optimize the fun out of the game.

For eg: When my sister was playtesting the game I noticed that since you could Repair without any timer limit between successive repairs, it led to dominant strategy of creating as many Gold Harvester as possible and then keep protecting them always, so constantly just keep healing the Gold Harvesters and other buildings that were under attack. This led to the introduction of timer between repairs, and thus enhancing the overall play… :)

Tutorial

Ah… The tutorial!!! Which everyone hates making and everyone hates going through. But for a game like this having so many complex mechanics, limitations and multiple elements to juggle with, a tutorial was much needed. To make the tutorial fun, I integrated it into the game, just a separate level with no enemies initially and some buffer of resources to start with. Created a state machine for tutorial manager, which brings up tutorial pop-ups one by one. It waits between tutorial pop-ups : not too less - to allow players to register and practice what they learnt and not too long - so that player leaves the arena before even completing.

This served 2 functions : First, of giving the player a place to practice their skills(like the Void in DMC5) and slowly and steadily figure out the rules and mechanics of the game. Second, it also helps in showcasing features and enhancing player knowledge, for eg: the repair timer mentioned above or the building efficiency % during building placement preview, things that are necessary but might go unnoticed if not specified otherwise.

Tests : PlayMode & EditMode

This might seem overboard like okay we don’t need Tests, but believe me this was very necessary. Not saying Tests are needed for each and every functionality, but atleast for the core game mechanics you should definitely have. Again you can watch how to setup tests from InfalliableCode or Jason Weimann, and it’s super simple. For this game, I had tests for the core functionalities like

1. Building Placement Rules
2. Damaging objects
3. Health never going negative even if large damage taken
4. Arrows following targets and rotating accordingly etc…

A snip of tests present in this project :

On second thought, I should have had Tests for Resource Management too, which checks the updating of Resource Values, since that is a pretty important too. And this practice of writing Tests evolve as your project grows and demands.

So, you gotta have Tests(at the very minimum for the core mechanics) and yes it saved me lots of times. For eg: Once I changed some code which essentially if went untested, would have broken the Building Placement Rules, which is the core game mechanic, but since I had Tests for it, I was able to catch it early. Without these tests, it would have been caught way later and I might have had to redo lots of things.

As a part of writing these Tests, you’ll learn about Assembly and Assembly definitions and how to use them effectively and structure your projects to reduce your compile time by many folds everytime you make some change.

CI-CD (Continuous Integration - Continuous Deployment)

This one again might seem like an overkill, but it’s literally an hour of work and would take things extra miles. I myself set this up pretty late and this might seem pretty daunting at first, but it’s not. CI-CD in simpler terms means whenever you make your changes, your build gets created for all the platforms you have specified(say windows, webgl etc) and it gets deployed to whichever platforms you want(like github pages, steam, itch.io). The power this provides is to catch any build and performance related issue early on and then fix it at an early stage. A sample workflow run for this game :

Again going for an example : In one of my games (Cruel Programmer), I used FMOD for audio. And FMOD for audio sucks for WebGl, and it was for a Game-Jam so obviously there was a time limit and hurry and a need for WebGl build in any case. After we did everything and integrated FMOD into our project, finalized it, built it, uploaded it to itch, we find out the sound isn’t working on WebGl. In the last moments that’s very painful and time-consuming to fix. We frantically searched around, tried various fixes, delaying sounds loading and what not. Thankfully it worked at end, but we could have caught it earlier had we created the build and deployed it early on and might have pivoted away from FMOD.

And did I mention that by offloading the build and deployment to cloud servers like github, you save lots and lots of your own time building it locally on your machine. For one, cloud machines are generally way faster and two, you can work on your game while the automation is happening and your build is getting ready and getting deployed. And as the game grows, the build times only go up so the initial 1-2 hour investment actually pays off many fold in the long run.

So, all in all this was a very fun project to work on and I learned lots of things along the way. I had a blast creating this and am so glad to finally finish and upload it. Incase, anyone wanna chat, I’m available on discord as luffy_703. Adios and happy game development to all!!! :)