After I have some ideas for what my game might look like, I outline the actual development, roughly in order of importance, so that I can play the game as soon as possible. I want an actual checklist with things to do, so I can see my progress as I go through the list.

Never write code that’s already been written

Since I’ve been toying around with unity for the past 5 years or so, I have a lot of code lying around in various projects that may be useful for me. The first thing to do, is import whatever is relevant into my project. As it stands, I have two very obvious code pieces that need to be used. My premade roguelike core for unity project, which is essentially a system for defining entities that take actions in turns based on the speed of the actions they took. The second is AStar pathfinding, which I have also written a tutorial for.

I have to make some slight modifications to my roguelike core system. The first is that the core roguelike code assumes that moving into a location occupied by an enemy translates into attacking that enemy instead. Since locations, or rooms, can be occupied by a number of entities, I don’t want moves to be delegated to attacks.

My AStar system also requires I implement a cost interface specific to this project, in this case based off BoardManager that is part of the roguelike core.

I’ve actually already done all of the above, it took about 2 hours of relearning my code, and making the required changes.. Now to list the things I need to do.

Step 1: The absolute essentials

Rooms and connections between them - Can’t play a game without seeing the world you’re in.
Player indicator - Need to know where you are in the world.
Basic enemy - So I’ll have something to do.

Input controls - Allow the player to take the core actions: Attack, Move. We’ll get to buying cards later.

At this point I call it a game. The roguelike core should handle damage, and AStar control enemy movement. The player can move around, and the enemy will chase and attack them. The player can attack back and kill the enemy, and can die if it loses all health. Not a very fun game, but a game nonetheless!

Step 2: Make it special

While it’s already a game, we haven’t gotten to anything that will make this game unique. I need to implement the core deck building aspect so I can tell if it’s fun or not. A lot of people like to rapid prototype game ideas, the “fail fast” approach. If you have an idea, try it out as quickly as possible to see if it’s fun or not. My approach is different, as I’ve spent literal years thinking about my idea, I am fairly certain that my idea is fun. I might need to tweak some things, but the core is most likely going to work. Still, I want to see it in action ASAP!

Define a card - For now, it needs cost and description.
A deck of cards - Hidden from the player, a pool of cards with some methods for getting cards based on cost.
Active card display - For now, simply showing some text will work.
Morph trigger - A way for the cards to change from one to the other.
Card effects - Both static and active.
Force Morph - Allow the player to morph the current card for an action.

At this point, I can start playing around with the cards, but I’m missing something essential: Designing some interesting cards. This is the hardest part of the design process. It is much easier to think about abstract system rules, than designing specific entities within the system that will be interesting to play with. It is easy to make a card that does +1 damage, and maybe at some point in the game design that card will exist, but right now what I want is some fancy cards to make a playtester go “neat”.

To round it out, I’ll likely need to make some spawning algorithm for enemies, to put more and more pressure on the player. Once I have that in place, I can finally show my game around and hope for some feedback!

Up next, follow me as I tackle the absolute essentials.