Hello again!!

This post is going to be about how I try to lay out a roadmap for a game. In particular, we are going to use the roadmap for PITVYPR as an example. As of the time of writing this, I haven't decided on a clear roadmap. However, by the end of writing, we should have one sorted out. This process will be very helpful for me, and I hope it will be helpful for you, too.

Let's start with defining what we mean by "Roadmap" so that we can attack it better. I could do some light research into the topic and find a standard definition - but I'd like to try my hand at defining this myself.

"A roadmap is a plan for getting some task done, by getting lots of smaller tasks done in order. An effective roadmap arranges these smaller tasks in such a way that makes completing the roadmap easiest." - me, circa right now

I'm sure this definition has a lot of holes in it - but I think it does a good enough job for us to figure out what we are trying to achieve. Notice I included the definition of an "effective" roadmap in there - it is important to zero in on exactly what the roadmap should do. It sounds obvious, but it's there to make our lives easier. Considering the order of the features and implementations on the roadmap is really what is most important. And we should consider them carefully, too.

A reminder here from last week's post: While it is in the nature of roguelikes to "just start", we can consider what we are starting on first. How deep you want to go on this is probably inversely proportional to how likely you are to "just start" at that very moment. As in: if you are raring-to-go and are going to start programming right away (maybe like me, you already have), then you might need to channel that enthusiasm into figuring out where you should focus yourself throughout development. On the other hand, if you are the type who feels like they want to design and analyse their project requirements for weeks or months before they've even written a single line of code: then you probably need to settle with what you've written, and just begin writing code already. Analysing without actually having done some of the work yourself yet is kind of like trying to figure out how to build a Lego set just from looking at the box: You might have some idea of the pieces that go into it, but you wont know for certain how you should build it until you open the box. That analogy is very poor... but I am fond of it and wont throw it out, because it almost does the job (and who can fault it for doing its best)?

A roadmap is best when it is made after having tinkered with some of the parts of your project first, so you have some idea what you're going to be working on/with. This is especially true if you have a deadline you need to work with, as it allows you to also plan the expected development time for each task. In programming, you only really know what you're going to be working with once you've worked with it once before.

Now with that self-justification for my late roadmap out of the way, we can begin to actually jot one down. First, we need to decide what the end-point of the roadmap is: What task will have been completed?

[A playable, barebones Demo]

THIS <-- (say it like Jeremy Clarkson) will be the roadmap I am making for this devlog. There is no need for your roadmap to be just [finished game]; not only will such a roadmap either be too big and convoluted to work with, or too broad and vague in it's sub-tasks to work with, but it also likely take you a LOOOOONG time to get through, which could hurt your morale when looking at the progress you've made during development. Notice I also added in some adjectives for my demo: "playable", and "barebones". These are here for my sake, so that I know more concretely what I am looking for in the end product besides it being "a demo". I want a certain level of functionality, but I want to keep it limited to only the essentials. This is going to inform what goes in to the demo, and therefore what goes on the roadmap, AND in what order it goes there.

We can begin this process by making a list of requirements for the primary gameplay loop of PITVYPR. If you don't know what I mean by gameplay loops, all you need to know for now is that the Primary Loop refers to what the player is going to be doing moment to moment in the game: as in what process they will be repeating over and over again every few seconds/within a minute, depending on the style of game you are making. If you are more curious about gameplay loops, I recommend looking into the Dev Diary video series done by Yahtzee Crowshaw. Anyways, here are those requirements/features for our primary loop:

• Movement and Collision
• Basic Entity rendering
• Interacting/Battling with enemies
• Interacting with objects
• Line of sight and visibility functionality
• Scavenging for items
• Inventory Management
• Failure state

These are the things I can think of that the player might be thinking about and managing at any given moment in the game. Already, we have a lot, and so will need to break these down and prioritize them.

First, lets give these all a priority:

1. Movement and Collision
2. Failure state
3. Line Of Sight / Visibility
4. Interacting with enemies
5. Interacting with objects
6. Scavenging for items
7. Inventory Management

The order above is an order of priority in terms of qualifying for the Barebones Demo. Which of these do we absolutely NEED? and which of these are less important? Sure, we need all of them - but pretend you might not be able to do them all: which would you leave until last?

Next, we need to figure out the systems that go into each of these requirements. I'd recommend just listing these out on a piece of paper, as I did:

My handwriting might not be the neatest, but hopefully you can see that the systems required for many of these requirements actually overlap. The Object Definition system, for example, is used in every single one of these requirements. The Action System comes in second. Also, I missed including the "Map", which would be a system used in these requirements, too.

We can, therefore, write the roadmap using the frequency of appearance and order of priority with the requirements and systems. You might need to fiddle around with your order a little bit, but the first few should be fairly clear. In our case:

1. Object Definition: Player, Wall
2. Screen Rendering with Map
3. Action System: Movement
4. Health/Damage System
5. Visibility System
6. Object Definition: Monster
7. Turns & Time
8. Simple Monster AI
9. Action System: Combat
10. Object Definition: Door, Switch
11. Action System: Use/Open/Close
12. Object Definition: Item, Consumable
13. Inventory Definition
14. Action System: Take/Pick up
15. Object Definition: Item (Weight & Size (?) Properties)
16. Inventory Definition: Stacking items
17. Action System: Drop/Use Item

This is our basic roadmap for the game. Notice how we will be looping back into systems a LOT during development? This is totally fine, and will help us to get features implemented without needing to fully complete each system we work on.

This roadmap is pretty simple, but it is already a great help to me with development. Just from looking at it, I can see what I've completed, what I've missed, and what I'll need to add next. I'm going to be circling back to making a health system once I've added in Combat Actions: which will be the next part I work on. The way the combat works will probably be very simple at first - and tweaks might be made to it to make it "deeper" if I feel like it is missing something. However, for now I will be working on Combat.

This post is already fairly long, so I am not going to touch on what a broader development roadmap might look like - nor go into making a non-linear/branching roadmap. Partly because of the space in this article, but also because a simpler roadmap is better. Sure, it can be handy to split tasks into groups and sub-roadmaps, and be able to work on each of them individually. But, for the solo dev who is making a Demo, most of the work is just linear implementation. If we end up needing to re-jig and de-linearize the roadmap, that's fine, we will do it once we are presented with a point that we can do that effectively. It isn't static - and can change to suit the project's and the developer's needs.

I think that the next post will likely be about combat development. Either that or just a recap of where exactly development is at right now. I will be thinking about that throughout the week.