Summary
After hearing how much efficient the new Unity DOTS was, I decided to test it by myself while taking the opportunity to improve upon a previous project.
In the end, I detected a considerable performance increase, but the feature it's still lacking support by the engine and its community, which further slowed down the development.
Specifications
- 50 days half time (4h/day)
- Developed in Unity
- Endless runner game
- UI icons from Material Design Icons
- Plugins used: CodeMonkey Utils, Custom Hierarchy, DoozyUI, Editor Toolbox, Graphy - Ultimate Stats Monitor, In-game Debug Console, LeanTween, PlayerPrefsEditor, Procedural UI Image, TextMesh Pro, Translucent Image - Fast Blurred Background UI, True Shadow UI Soft Shadow and Glow and Ult Events
Project goals
- Getting acquainted with the Unity DOTS
- Improving my previous game Ploppem
Gameplay
The concept around which everything revolves is simple:
Endless waves of enemies spawn on the screen, touch them, and they will disappear.
If you don't, they detonate by themselves after a specific amount of time, and you lose a heart.
Running out of hearts means Game Over.
But this time, mindful of my previous attempt, I kept the game simple and intuitive, while trying to make it fast and fun.
Enemy design
When it comes to the enemies, much has improved from the first game. Gone is their complex AI designed to avoid a collision between them or their visuals packed with all sorts of data.
To encourage a fast reaction I reduced the enemies to simple shapes, I provided them with a direction of movement that changes only once they reach the edges of the screen, and their self-destruct timer is shown in a gradient from green to red. The enemies can now overlap each other, but killing more than one at a time does not affect the points earned.
Difficulty
In Ploppem each time you killed an enemy, a substitute was queued to spawn after a short time. The main problem with this approach comes with the long time the player must wait after eliminating all the enemies on screen.
To avoid it I separated the spawn from the kill system, and now the enemies keep coming independently from the player performance. Over time the stats of the newborns become more difficult, keeping the player on the edge of collapsing. This change also simplified the game design, therefore opening it to a more broad audience.
Coding
By using the new Unity’s Data-Oriented Tech Stack (DOTS), I was able to further improve the performances by replacing the usual MonoBehaviour classes with components in ECS.
Instead of an enemy object acting independently from the others, I have now an entity that is just a container for every data that defines a single enemy. This data is then processed by a system that efficiently moves each enemy simultaneously by using multi-threading processing through a Job. It has allowed me to introduce the aforementioned independent spawning system because even with more than 100 enemies on screen, the fps didn't drop below 60.
The only aspect of the game I was not able to code using DOTS was the UI.
User Interface
I started implementing the UI of the game using scripts made by myself, carried over from the previous project Tunnel, but while searching for a plugin capable of showing the console in-game, I stumbled across the page Game Assets Free, that allowed me to download various useful plugins, including DoozyUI, a complete management system for the UI. From that point forward I was able to more quickly create all the necessary parts of my interface.
But even if that helped me with the more technical part, I still had to put some effort into the design.
A bit of UX (User Experience)
The interface that was redesigned the most while developing, was the game one.
During the prototyping it contained only the pause, a timer and the remaining lives in the center of the screen.
This didn't change until about the middle of the project, where I introduced the score, and moved the lives to the top right, and in an attempt to reduce cluttering I also removed the timer. The pause button has been moved to the center to please both right and left handed.
After further tests I decided to increase the size of the texts, reintroduce the timer and then move the score to the center, adding the highscore (which was previously in the pause menu), both numbers have an alpha to show the monsters below.
The main menu also got through quite the change. The originals 5 buttons (play, customize, about, settings and game stats) were reduced to 3 for the seek of simplicity.
Both the game settings and the game stats were relived of unused functionalities, and incorporated in the main menu. I then took the game version and author from the about menu and also putted them in the main menu, leaving only the social links and credits.
Monetization
To sustain itself, every game needs to generate an income, and usually, for Android's games, this comes in the form of a monetization system. Although Ploppem 2 didn't need one, I still theorized how I could implement it.
Right now, the game rewards skins to who beats a specific highscore. They only slightly impact the gameplay difficulty, based on the skin shape size.
Currency
I would change that by introducing a currency earned by playing, usable to buy the already mentioned skins. Being detached from the player's performance allows introducing higher costs than what can be collected in a single run. Less capable or experienced players should just play more runs. However, it takes time to do so, which brings me to the second and most important addition that makes monetization effective.
Premium Currency
A second currency that can only be purchased with real money would allow me to offer those who do not have the skills or the time some support, in the form of shields or boosts to help them achieve the same accomplishments as others.
The addition of other customizations, such as themes for the UI or different enemies' colours, could also boost the monetization, especially if some of them were premium-only.
Closing thoughts
Ploppem 2 was a great opportunity to grow and despite the difficulties I encountered in adapting to DOP programming, it allowed me to do justice to one of the first concepts I ever developed, showing how much I have improved over the years.
However, if I could go back in time I would:
- I would have addressed a few bugs right away, and although I now know they are unsolvable, it would have spared me a lot of headaches towards the end of the project.
- Plugins come in handy to speed up the development process, at the cost of build size and engine performances.