Developer postOriginal post (opens in a new tab)

Diary Page #4: Boards and Metrics

Dear Scholars,

There is something satisfying in bringing an imaginary world to life in a physical and tangible form. Although it doesn't beat the joy brought by the sole process of the world's conception and development, the sensation of touching baroque style furniture, wallpaper, and decorations makes it seem like Selenwald is no longer confined to a program.

Selenwald has recently seen the light of day for the first time. It was shown at Poznań Game Arena - a gaming expo in Poznań, Poland. One of the major things I was focused on in September was bringing the rough demo to a somewhat presentable state so I wouldn't feel bad showing it publicly. Luckily, despite having many flaws and requiring a lot of assistance and explanation, it has made a much better impression on players than I had anticipated.

If you were there, thank you for visiting and playing - it was nice to meet you! If you weren't and you feel like you missed out on playing the game, no worries - there will be more opportunities in the future. On top of that, remember that the demo was still a very early version of the game that's not fully indicative of the final experience so you didn't miss that much after all!

One step closer

As some of you might already know, I'm actively looking for a publisher and/or an investor. It is imperative that I partner with one because I need to hire over a dozen of people to finish Selenwald in reasonable time and I am in no way capable of covering such costs all by myself.

In case you're wondering - crowdfunding is not a viable option for the project yet. It would require an enormous following for it to actually work and cover the entirety of development costs. Don't get fooled by crowdfunding campaigns that aim for sums like $50k. Games are much more expensive to make unless they have a tiny scope and can be done entirely by one person in a short period of time. If developers of more ambitious games run campaigns with small goals like this it probably means one the following scenarios:

  • the game is already fully funded and crowdfunding is only used as way of marketing
  • the game was funded but the studio has run out of money before finishing the game so it's looking for some additional cash
  • the developer or the publisher wants to sell pre-orders (for example, Steam rarely allows indie games to sell pre-orders directly on the platform so crowdfunding might be an alternative)
  • the developer is inexperienced and runs a crowdfunding campaign before realizing how expensive the development is really going to be which may lead to some bad things

Anyway, back to the topic. I'm already in contact with a lot of publishers. But what is it that prevents me from moving forward and signing a deal with one? Publishers and investors typically require several things in order to consider funding and/or publishing a game:

  • vertical slice
  • development schedule
  • budget breakdown

A delicious pie

What on earth is a vertical slice, you ask? It is part of the game development jargon and a metaphor for a playable demo that feels like a short excerpt of the finished game - a single slice of a tasty pie with all the layers. Now that's a bit of a problem. In the case of a system-heavy game such as Selenwald, having an actual, true vertical slice would mean being probably like half way through the development process. Selenwald now has a playable demo that is far more advanced than a mere prototype but also far from having all its systems and features in place. This means that publishers that strictly require a full blown vertical slice are a no-go because getting to that stage of development without external money would take too much time. However, I am also trying to get more government funding but more on that later. Luckily, some publishers are already expressing their will to publish Selenwald without requiring a demo in a more advanced state than it's currently in. Therefore, this bullet point can finally be crossed out!

Money and time

The other two, tightly related things required by publishers are a detailed budget and a crystal clear roadmap which will prove I actually know what I'm doing. That is something I have roughly had for a long time. I knew what the approximate total budget is going to be, how many people need to be hired and how will the budget be distributed. What I haven't had until very recently is the project schedule planned out all the way until the release. So far I've only ever created tasks for up to a couple of months ahead. However, time has come to carefully plan out everything until the release. Not only it is needed in order to provide an overview of which project milestones could realistically be expected at which deadlines but it's also the only real way to confirm that the budget was estimated correctly. In a perfect world every single project task should be laid down upfront. And that's precisely what I've been recently doing.

The perfect plan

In case you don't know much about game development, the headline of this paragraph is a bit of a poetic stretch. In this industry no such thing as a perfect plan exists. Like the documentation, most plans are out of date the moment they are written down. However, it's still extremely useful to go through it and prepare as much as possible before the project enters the stage of full production. Now is the time to identify some possible problems, determine exactly how many people will need to be hired, and calculate the total cost that is close enough to ground truth to be treated as such. So how to actually go about calculating the budget? There are mostly two ways - making a detailed spreadsheet or creating tasks inside a project management tool right away.

For me the choice was simple. Lots of tasks needed to be prepared so this time I skipped making a spreadsheet altogether as I would later need to manually transfer the tasks anyway. Additionally, project management tools have proper metrics so there wasn't really anything I could gain from making a gigantic spreadsheet.

The right tool for the job

I have been using HacknPlan as my project management tool of choice ever since I started making first prototypes for Selenwald in 2016. What is it, really? It is something akin to Jira and Trello but made specifically for game development. If you're an existing or an aspiring game developer and you don't use it, let me show you why you should consider trying it out on your next project.

Of course it has an obligatory Kanban board where you can keep your tasks on display. It also has a lot of metrics, various planning tools (including a Gantt chart), is pleasant to look at, and is highly customisable. However, there's one feature that makes it stand out the most.

The tree of life

The Design Model is probably the most important reason I like HacknPlan so much. It's a tree-like structure that lets you map out the planned features and content in your game. Design Elements are entities separate from tasks. They can be arranged in a hierarchy and each design element can have a description. It's basically a nice alternative to a classic Game Design Document but it comes with some clever solutions that also tie it to the production planning infrastructure.

In my opinion the single most important feature of HacknPlan is that every task (that isn't already parented to a Story task) can be parented to a Design Element. Here's what makes it so useful:

  • Work becomes oriented around content and features No more searching through different boards to find all tasks that revolve around a certain enemy in the game just because the enemy was being worked on continuously through different milestones. U can simply select the enemy in the Design Model and immediately see all the relevant tasks.
  • Changing task names Imagine that when you start working on a character you only know that they're going to be a mage you first encounter in a tutorial. So you name the first task "Draw concept art for a tutorial mage". You have some discussions in the task's comments, you make the art and close the task. Then much later in the project you decide that this character is named Diana and all further tasks around her mention her name (e.g. "Write dialogue for Diana"). Now good luck if someone wants to go back to that old discussion in the comments but nobody remembers where it was and you can't just find that old task by the name Diana. That problem is gone with the Design Model because when you start working on a placeholder character you create a Design Element for them right away (e.g. "Tutorial Mage #1") and tie all tasks to it. It becomes your go-to place whenever you want to discuss it and you can later rename the entity to "Diana" while retaining the link to that first task (still named "Draw concept art for a tutorial mage"). Everything remains connected and you won't ever lose track of the old tasks still using placeholder names.
  • Wiki-like structure There's a useful feature that lets you easily link tasks and Design Elements to each other inside their descriptions. This eliminates the drawbacks of the linear nature of a tree hierarchy and enables the user to easily find elements from different branches using a network of links.
  • Feature/content based metrics You can very easily see what is the progress on specific parts of the game as every Design Element has its own metrics based on the tasks associated with it. Every entity with tasks gets a progress bar and the metrics propagate up through the hierarchy.
  • Design Elements as task templates You can duplicate Design Elements together with all the tasks that are attached to them. This way they serve as templates and you don't need to manually create separate sets of task for every e.g. weapon in the game. Plan out just one and quickly make as many clones as you need.
  • GDD exporting In case you ever need an old fashioned Game Design Document that nobody reads, you can always export the Design Model tree into a linear text format.

The current status

I haven't finished building the detailed production plan yet but here's some data in case you're interested in numbers:

  • 3103 tasks have been created in total so far
  • 2093 tasks are currently open
  • the open tasks add up to 3787 work days, which approximately means that there's work for 12 people assuming a 1.5-year development time or 9 people assuming a 2-year development time

These numbers will further grow as I wrap the schedule up in the nearest future but hopefully it already gives you some insight on how much it takes to make a game such as Selenwald. By the way, this is typically one of many responsibilities of a producer. Obviously, here that's just another hat I need to wear but in the future there will be a dedicated person to handle production in the team so I can spend more time directly working on the game.

Something brewing

While partnering with a publisher is the most likely future for Unnamable Arts, I'm still always on the lookout for alternatives. One of such options are government grants. They would not be enough to fund the entirety of development but could help me grow Selenwald enough to make crowdfunding a possibility. Most programs have very specific requirements and rarely fit Selenwald. Others are a bureaucratic nightmare and the enormous effort isn't always worth the money. But recently a nice little program popped up and I decided to apply. A success would help tremendously. The results should be revealed next week so make sure to join our Discord server if you're still not a member as I will surely share the news in case I manage to get that financial help.

Thank you for reading,
Wiktor