Another week has passed and we have been hard at work…

The release of our first beta version draws ever closer, and while checking off the last few points of our roadmap we also thought about all the features we can’t include in this version which have to wait for the beta 2.0. This brings us to today’s topic:

Scope and Planning

Everyone who ever wanted to create a game has stumbled upon one problem: Too many ideas. The scope of a game includes all its features, from its core gameplay, its story, dialogue, music, SFX, etc. And sadly it is all too easy to completely lose yourself in an ever-growing list of creative and awesome features you’d really want in your game… if you just had the time. In the end you want to release something worthwhile, but without proper planning and caution your project might grow so large that releasing it becomes completely impossible instead.

We Goblins burned our fingers multiple times on this problem, with countless casual projects over the years. It starts with an awesome, compact idea and after a single round of brainstorming you’re sitting in front of a mountain of a project that would take years of work to actually create. Over time, we had to scrap a lot of projects because of this, and many other people out there had too.

But today we don’t really want to talk about those “learning opportunities” yet, but instead about five strategies that helped us to keep our project actually doable. We hope this will also help you with your projects.

1. Aim for a Proof of Concept. You got an idea for a game? Fantastic. But instead of just starting somewhere you should first create a Proof of Concept: A minimum playable version which showcases your core gameplay. Boil down how your player will interact with your game and try to build this in the easiest and fastest way possible, while mostly ignoring all the bells and whistles. Want to make a shooter? Make a room to move around in and blocks to shoot. A platformer with some form of gimmick? A square room with a couple of platforms and maybe your core mechanic to play around with is enough. Such a PoC will help you see if your idea is fun and allows you to gradually carve your actual game out of it.
2. Lock your features. Idea? Check. Plan for a Proof of Concept? Check. At this point it’s very easy to get more and more ideas, so you need to use precautionary measures so you won’t fall for the dreaded Feature Creep! For us, a simple document explicitely outlining the features of our PoC was the first step. The second was to never, ever, ever add to this list of core ideas without a good reason. It helps you remember your initial, often more simple, vision you had and might make it easier to steadily work towards your PoC. Try to add to this list only when you’re already done with the other points.
3. Structure your work. Roadmaps, Kanban Boards or even a simple text document can help you with structuring your ideas and features. Break down the parts your Proof of Concept is made of, and break down those parts even further. Try to think about the time frame each of those steps might take and in what order you want to do them. Give lower priorities to parts which aren’t actually integral for your Proof of Concept (e.g. music and graphics, story and dialogue). Deliberately try to shrink down and order this list, and soon you will notice how your scope and progression is not only realistic, but also leads you on a way where you will see the most impactful and motivating results much sooner.
4. Don’t be afraid to walk back on ideas. If you notice how you got more and more features on your plate, don’t hesitate to remove some of them for now. Stuff can always be implemented later, so try to remind yourself of the actual core ideas before losing yourself in a workload of non-integral features.
5. Review your work regularily. While absolutely necessary when working in a team, this is still important when working alone. Try to set a certain rhythm you want to plan your work for (weekly, bi-weekly, whatever works for you). Think about what points on your list you want to do in this phase (called “Sprint”) and, most importantly, think about what you did and didn’t manage to do afterwards. Everytime your Sprint ends, try to make yourself an image on how you’re progressing, on what comes next and review if your current goal still aligns with your initial vision or has accidentally grown in size. It might need some trimming if your features have put on a bit too much weight!

This stuff is difficult. We Goblins are literally professional software developers and still struggle with this from time to time. But once you manage to keep these principles in mind you will soon see all the progress on your project - one of the most satisfying feelings this hobby has to offer!

Wanna see what happens when you don’t manage to do this though? Join us next week when we will share the interesting (and a bit embarassing) story of the original version of Tales of the Shepherd and how not to develop a game.

We also hope you enjoyed this Devlog and are looking forward to the first proper beta version for Tales of the Shepherd.

Cheers

GG