Swift Downhill 2 - the (re)making process

Hello everyone! I'm super excited to share this major Swift Downhill update with you. The last time Swift Downhill was updated was a little over nine months ago and i during these nine months, I significantly improved my skills in (almost) all aspects of game development. Of course, i wanted to use those skills to create an amazing game, but unfortunately, I couldn't come up with a unique game idea in a popular genre. So, I decided to take a look at my old games which hadn't been updated in months and decide which one to update. The game that almost immediately came to my mind was „Swift Downhill“ because it was a simple, fun and addictive concept. 

Upon taking my first look at the project after porting it to the current version of Unity, I realized how much work I had to do because that version of Swift Downhill had three major issues I had to resolve before working on new features:

1. Bad world building. The ones who played the older versions know how terrible the terrain pieces looked. There was only bad ground texture which didn’t tile seamlessly creating visible lines on the ground. There were also clearly visible holes between the terrain pieces and trees weren’t dense enough to cover the „void“ behind them. 

2. Ugly generic UI and default font: the buttons used in Swift Downhill are generic-style buttons which would fit better into a mobile game with low-poly graphics. And yes, I tried to give them a more realistic look, but they just ended up looking wrong. The thing that also looks wrong is the text with the default font(Liberation Sans) which I tried to style with outlines, but I think they made it look worse.

3. Slow and cluttered „code“: At the time of making the first versions of Swift Downhill, I wasn’t very familiar with writing c# code and therefore I chose to use Unity’s Visual Scripting system to define my game’s logic. If you have used Unity’s Visual Scripting before, you know how messy script graphs can get. Luckily, Swift Downhill’s logic wasn’t too complicated, but I still didn’t want to declutter my old script graphs which I hadn’t touched for roughly nine months (I stopped using Visual Scripting shortly after making the last version of Swift Downhill). There were also some pretty major performance issues caused by the „code“ (more on that later)

To fix the first major issue, I decided to completely remake the terrain piece(s), which wasn’t absolutely necessary, but way easier than modifying the old ones(especially because I converted the project from the Built-in Render Pipeline to the Universal Render Pipeline which forced me to use different tree prefabs). Besides chasing the ground textures and replacing the trees, I also made the hills higher to better hide the „void“ behind them without using too many trees (I think the terrains even have fewer trees now). The last thing I did was making a skybox with pictures of trees on the right and left side and a picture repeating terrain pieces at the front to create the illusion of more trees (which will come in handy later).

Then, I started improving the UI by replacing the default font with a font called „Bangers“ (still pretty generic, but looks much better). I used color gradients instead of solid colors and added bevels to title texts. Moving on to the buttons, I replaced their generic graphics with other generic graphics which fit the style of the game better. I also decided to squeeze the intractable UI elements on a panel on the left side of the screen and expose the settings instead of adding a settings menu because I noticed that the old settings were often overlooked.

After that, I came to the hardest part which was updating (or actually rewriting the code). As I mentioned earlier, the old „code“ was constructed using Unity’s Visual Scripting system which I hadn’t touched for over half a year when I began updating Swift Downhill. That combined with other flaws in the script graphs (e.g. A LOT of instantiation and destruction of GameObjects which led to a lot of garbage collection causing the game to lag at certain times) led to me just throwing the script graphs out the window and rewriting the code from scratch. The first thing I did to fix the aforementioned issue was to „pool“ the terrains which means that you deactivate the unused terrains instead of destroying them to prevent the garbage collection associated with destroying objects. I also made the terrains only spawn the next terrain after the player enters it which leads to just two terrains being active at a time instead of 20.

The ones of you, who played the old versions, might have noticed that I removed the rivers from the game. I decided to do so because I haven’t found a decent-looking performant way to make water…YET. Realistic and performant fluid simulation is a very complex topic which I only started learning very recently, but I already came up with some ideas to make it work which means rivers might come back, but even if they don’t, I planned to add water puddles or small lakes which will definitely be performant enough.