This is the first in a weekly series of articles I’ll be doing, charting the development of Rogue Kaiju and some of the design decisions I’m making along the way. I’ll be looking at things like coding patterns, game mechanics and even stylistic choices for asset development.
Right now, I’m working on the pre-Alpha/proof-of-concept demo for Rogue Kaiju, so my efforts are focused mostly on how the world will be built and function on a fundamental level, versus specific interactions. I’ve built a lot so far using what I’m calling a 1-Example Rule. The demo currently has:
- 1 kaiju
- 1 attackable feature
- 1 non-attackable feature
- 1 indestructible feature
- 1 basic attack
- 1 special attack
- 1 tile condition
Pretty much all the sprites you'll see in the world. (Not even the cows, yet.)
It makes for a homogenous world, admittedly, but it also helps me focus on getting the mechanics to work for one, extensible example, rather than getting bogged down in the minutae of whether fire should do more damage than electricity or how much defense one kaiju should have versus another.
The crux of it all is making sure that my tile-based system can work, accept inputs, and let the player interact with this rudimentary world without crashing. I also want to test my particular style of inputs and action points. Lastly, I am decidedly not worrying about things like:
- AI
- Line of sight
- Animations
- Sound
Those will certainly come in time, but they’re not necessary for a proof-of-concept. I come from a background in tabletop game design, where you can build a prototype game with index cards and sharpies – the important thing is making sure the mechanics work together.
Pre-alpha preview. Red dots are "on fire" at this time.
The Rogue Kaiju pre-alpha demo should be releasing within the next few days, barring any unforeseen obstacles. It will just be a web demo for now, for ease of access. Stay tuned to my devblog or Twitter feed for the most up-to-date release information.
Thanks for reading!
