Why did we choose Unity? Are there better options?
The answer is really simple. We’ve been working with Unity since the very start of our company. The engine has its quirks and issues, but it’s really flexible in terms of multi platform deployment. Not to mention, it’s also free and has a large and dedicated community. These things make it perfect for small and mid sized projects.
There was an interesting topic published on reddit recently:
The author checked 250 of the most popular games published on Steam and listed the most popular engines:
- Unity: 23
- Unreal: 6
- GameMaker Studio 2: 4
- Other/custom: 16
Even though Unity still has room to grow in comparison to Unreal’s graphic rendering, it’s still a better choice for projects such as H1Jack.
The C# scripting language used inside Unity gives us the power and extensibility of OOP. The Unity community is trending toward the Entity Component System structure, but we still use the good old S.O.L.I.D. (link leads to nice lectures about ECS and SOLID) approach and stick to known solutions.
Unity tends to provide a lot of unfinished or not completely stable tools to developers so we rather prefer to stick with stable and tested solutions.
Finding a proper art style
Asset production is always the longest and the most expensive process. Proper planning and pre-production plays a critical role since the game initially exists as a set of ideas on paper and will probably change several times during the development process.
The target audience and platform are other important things that one must consider. For example you cannot scare casual players with gore or dark themed graphics and user interface design for mobile games must work around the limitations of small displays and touch screens.
Below you can see the process of how we handled the art design of particular game modes.
You can notice that during the initial prototype phase we were not focused on graphics at all.
At this point we were not confident about core visual elements like proper game camera placement and asset count. We also weren’t sure about what ideas looked good on paper and were in fact fun while playing. This is the main challenge of the game development process: each game is always a new adventure. You never know where you will end up.
We also made some radical changes to the art since we weren’t satisfied with the final outcome of certain parts of the game during development and testing.
To give an example, we initially wanted all enemies to be designed without using procedural generation. However, this left us with a big lack of content for a casual game like H1Jack. We then decided to construct monsters from procedural parts, but this gave rise to its own set of complications and challenges.
The results from procedurally generation our monsters were simply too generic. Even if we added some additional rules to have the monsters be less random, the final outcome was not satisfying. We decided to restrict and tie the monster parts used in procedural generation to our level themes.
Our protagonist also changed several times during development.
The story of the game is centered around telling a young hacker working a dead end job. At first the design was meant to be ultra casual, almost chibi style. However in the middle of development we decided to make a radical change. We chose a more slim yet cartoonish style. This created several new problems and we spent a lot of time which could have been used on creating new content or improving existing assets.
These challenges and tradeoffs are pretty common in game making. It’s hard to estimate the development roadmap when you sometimes have to cut already existing elements only to not end up in a production dead end.
This altered look was a tough decision but it opened up several better options for growing the game in more interesting directions.
Like for example cool NPC avatars
What are Stances and Hacking Paths?
The foundation for the game’s design was to make an idle battler game with tamagotchi-like meta gameplay and to fit this concept into hacking culture. Our challenge here was that we wanted to include real technical knowledge for an audience that is not technical at all.
We decided to go with a well known design technique used in games called Rock x Paper x Scissors. Our stances work along this theme but we flavored it with technical terms from realistic hacking.
This division might not be realistic, however you must remember that we are still talking about a casual game. The first priority of this game is to be fun, not realistic. We aren’t making a simulator. At least not now!
Author: Cobble Games