Rogue Kaiju (working title) is a roguelike that ventures out of the dungeon and into an open-world setting, where rooms are regions, equipment and weapons are mutations and powerful attacks, and your cunning rogue is a massive monster inspired by kaiju films and other sci-fi disaster epics.
Rogue Kaiju uses grid-based movement and combat, along with a turn-based action point system for commands that blend real-time control with tactical decision-making. On their turn, players have a number of actions they can use. Green actions can only be used for movement. Blue can be used toward movement or basic attacks. Yellow actions (which are earned like a sort of currency), fuel special attacks like toxic breath or sonic bursts.
Every world is procedurally generated, with terrain to navigate and cities to destroy across an infinite map. Cities grow (and rebuild after attacks), and tailor themselves to your abilites and notoriety, so the game progresses with the player. Players will need to attack cities to get upgrades, but will find each venture more difficult than the last.
Players will customize their monster as they play by unlocking mutations for attacks and passive abilities. New base monsters can be unlocked by battling other monsters as well. Rival monster battles will be triggered based on certain conditions the player must meet. Some will happen naturally throughout the game (e.g., reaching a certain "level" or destroying n cities), but others will be more obscure.
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:
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:
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!
No articles were found matching the criteria specified. We suggest you try the article list with no filter applied, to browse all available. Post article and help us achieve our mission of showcasing the best content from all developers. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.