Developing Tiny Army
I’m currently developing a rogue-like game in Unity called Tiny Army, and through these posts I’ll try to express my ideas and my workings, so I can motivate myself to continue developing the game, and to also understand it better.
Who am I
My name is Luca, I’m from Brazil, and I’ve been developing games in my free time for a couple of years now. In 2017 I’ve launched with a couple of friends the game Fit It on Android.
It didn’t get a lot of traction, but we also never tried to advertise it or anything, just showed to some friends and family and tried to spread the word. After one year, we made around 8 dollars, so I guess we can call ourselves real game developers now¯\_(ツ)_/¯
What I want to build
The basic gameplay of Tiny Army is something similar to Fire Emblem Heroes, but instead of different maps, you progress through a continuous map and try to get as far as you can. There you’ll find enemies, chests, traps and other objects to interact.
Since in you’ll be starting over each game, I didn’t think it would make sense to have an experience and leveling system, but to make each play stand out from the others, random items will be spawned along the map (from chests and enemies), and they will affect the play style you’ll use for that run.
These items will have randomly generated attributes (like bonus damage to a type of enemy, give some status buff, etc.), so you’ll have to adapt to what you get and try to create the best strategy with them.
In the future I’ll would also like to make the map and enemies randomly generated to increase the diversity in play styles.
What I have done so far
I’ve been following the posts from John Parham on his blog TheLiquidFire, and I’ve created the basic units and board following his Tactics RPG project. In each round all units from an alliance makes their action (movement + attack), and when there are none available, change to other side.
The values for the player movement and attack range, starting stats (HP, base attack damage) and items can all be easily changed, to be able to easily develop different enemies and units.
The main aspects from the code architecture, that I’ll try to cover better on another posts, is the notification center and the battle state machine (both from John’s blog). Both of them helped to develop a clean, decoupled structure.
In the next post I’ll try to explore the notification center, and how it’s used to separate the main logic from other pieces of code that don’t really need to be directly connected, saving from having connections to random scripts everywhere.
You can check the game progress on GitHub!