Considerable Content is a studio of two, Edward Blanch and Scott Beca, who have spent evenings and weekends over the past three years making the old-school 3D platformer Rogue Singularity. Both have day-jobs in the games industry, so they have struggled to maintain momentum on their personal project. In this article, Edward and Scott talk about the most valuable lessons they have learned trying to get their game finished. To check out their progress for yourself, Rogue Singularity is currently available through Steam Early Access. The full release will debut on Nintendo Switch as a console exclusive in 2018, alongside the full release on Steam.

Many years ago, the two of us started making a very strange action adventure game called Postman's Odyssey. It was almost the perfect opposite of the game it would one day mutate into: slow-paced, atmospheric, and almost entirely hand-crafted.

After quite a lot of work, we had a working prototype and were getting people to try it out and give us their feedback. We learned two important things: players were really only enjoying one small part of a much larger game, and (if we continued) we were looking down the barrel of year and year of work on a game with limited appeal.

A screenshot of Postman's Odyssey, showing the procedurally generated buildings

The silver lining was the one part of the game that people really got into. Despite being mostly made by hand, it featured procedurally-generated towers that players needed to climb, which were complex and full of dead ends and tricky traversal. We decided that since jumping around on weird procedural shapes was fun, we would discard everything else and make a game based just around that gameplay loop.

The result was Rogue Singularity, a Mario 64 inspired 3D platformer which put players in control of a plucky little robot that was traversing a solar system being torn apart by a black hole. To simulate the random, chaotic nature of this cosmic destruction, all of the levels would be procedurally generated, as we described in this Gamasutra article from earlier this year.

Simple, we thought. We can knock this over in a year or so!

Well, not quite. Three years later, Rogue Singularity is close to being done, and we are much more experienced game developers. Here are five of the biggest lessons we've learned since beginning work on this little side project of ours.

Set a clear and modest scope (but accept that it will slip)

If we ever do another game in our spare time—and right now that is not an appealing idea at all—we will insist on a strictly limited scope that we both agree is achievable in the time we have available to us. The most likely option if we do a follow-up will be a Rogue sequel, since that will allow us to build on everything we already have instead of starting from scratch.

Because Rogue kind of started organically, emerging from that earlier project, we got into it without a clear design in place. Feature creep was inevitable because we began without a real sense of scope. This is not a mistake we will repeat: any project we work on in future will be carefully planned in advance.

This is not to say that feature creep won't happen, or even that it shouldn't. Your own games can surprise you: features you never gave any real consideration to may turn out to be the most fun, prompting you to reallocate resources to develop them further. However, you need to make these kinds of decisions very carefully, weighing up how much they will improve the game against how much extra work they will require.

An early version of Rogue with smaller platforms for slower movement

Rogue is a very different game now from the one we originally envisioned. The broad strokes are there, but the fine details have evolved dramatically. Speed is one of the key changes. Since we were so inspired by Mario games, we automatically included two running speeds: a slower default and a sprint that was enabled by holding down a button. In practice, we found that all our test players were playing the entire game with the sprint button held down, because there was no advantage to moving slowly.

With this new knowledge, we got rid of the idea of two running speeds entirely and instead changed the character's default speed to the original sprinting speed. With the character always sprinting, the gameplay began to speed up as well, and then we decided to bring the camera in much closer, double that character's size on-screen, and make the platforms larger, which made it faster again. Suddenly our game, which had been about carefully picking a path through obstacles, was much more frenetic, focused on not just getting through the level safely but also quickly. From that was born the idea of timed runs, which gave rise to leaderboards, player ghosts, and Rogue's entire online functionality.

A more recent version of Rogue with faster movement over larger platforms

On the one hand, all of this social content blew out our release date by at least a year, but on the other, it definitely made it a better game. For many of the most engaged players in our Early Access program, competing on the leaderboards is the main thing that keeps them playing. Was it worth it? Well...

Learn to live with your decisions

As game developers, we are often immersed in worlds of science fiction and fantasy, but here in the real world there is no time travel, and no way to hop sideways into alternate realities. We're stuck with the decisions we make, and all we can do is try to make the best of them.

It was very late in Rogue's development that we realised the theme was all wrong. Because of the shift to speed-driven gameplay and competitive leaderboards, we realised that the gameplay would have worked much better as a kind of extreme sport. Imagine a televised sporting event with robot competitors trying to make the best times on extreme obstacle courses, and with Rogue's evil overlord character replaced by a coach or trainer who tries to keep the player motivated.

Robot overlord

We recognised two things: this would almost certainly be a much better fit for the gameplay that the theme and story that we had, and we absolutely could not do it. Making that change would have forced us to discard years of work, restarting much of our development from scratch and pushing our release back even further. Even though we were certain it would have made a better game, we realised it far too late in the development process.

We've had to simply live with this, and with a multitude of other decisions where we committed to doing things one way and then felt later on that we'd made arguably the wrong choice. Rogue Singularity is a great game that we're both very proud of, but it's natural to wonder what might have been. Ultimately, however, you need to accept the choices you've made and move on.

Of course, in some parallel universe, there may be some alternate Edward and Scott shouting, “Why didn't we go with the black hole? This sporting theme just isn't working at all!”

Just because nobody's paying you doesn't mean your time has no value

This might be the most common mistake that young indie developers make. When you're working on a project you love in your spare time, deciding on your own priorities and with no boss telling you what to do, it is easy to equate “no pay” with “no value”. This is a dangerous attitude, and it can really set young developers back.

Every now and then you'll see an article pop up in the gaming press about a team who claims they're making a game “for free”, with “zero budget”. One such group that made headlines were hiding out in their university and sleeping under desks, and when they got caught they all moved into a single house and just made their game 24/7. This kind of process can certainly be interesting and fun, but it isn't free.

Cost is about more than just money. Your time is also valuable: every hour spent on a personal project is an hour that could have been spent elsewhere. In the case of the share house of developers making their “free” game, what happens if the game flops? If it fails to connect with an audience and makes no money (and let's be honest, even great games can be financial failures because of factors outside the developer's control) then those people have lost years of their lives. They're two or three years older, but without financial security, without the business contacts, and without a portfolio they might have built up working a salaried day job.

It's all about the coin

Worse still, even if the game succeeds they will have no experience of what it's like to work in a professional studio. When they want to begin work on their next game, they will have no idea how to write a design brief, or manage a budget, or prioritise tasks, largely because they have never thought of their own time as being worth something.

Trying to complete a game by working during evenings and weekends has come with its own challenges, and it hasn't gotten any easier. When we started, both of us were working part-time on contract with variable hours, and now we're both full-time permanent staff at two different professional studios. Even so, the experience we get in our paid roles makes us better developers, and Rogue has improved as a result.

We work faster, we work smarter, and there's stuff we've included in the game that we would have never discovered if we hadn't encountered it in our day jobs. Put simply, you don't become a better developer by doing it less.

Find ways to sustain your momentum

Actually keeping the project moving when time is short and energy is low is perhaps the greatest challenge the two of us face on this project, but we have found motivation in some unlikely places.

One of the strongest sources of motivation was money, and ironically it wasn't money we lacked, but money we had in-hand. We received a grant from Film Victoria which allowed us to do many things, including hiring Trevor Powell to code our camera controls. Trevor is a world-class expert in video game camera systems, especially in 3D action platformers, and brought 14 years of experience onto our little project.

Trevor's presence affected the way we worked in a lot of ways, but mostly it just motivated us to work. Even though we tried to remember that our own time had value, it was easy to think of the hours we put in as “free”. Trevor, however, was getting paid, and we were the ones paying him. The thought of having him waiting on us for work, twiddling his thumbs because we hadn't finished the prerequisites for his tasks, was horrifying to us. The waste of our small but precious budget was one thing, but Trevor was also someone we greatly admired. Leave a legend of the industry hanging because we didn't get our work done would have been intolerable, so we pushed ourselves to get it done.

Rogue Singularity at PAX Australia 2017

Committing to events was also a great tool to keep us moving. We've shown Rogue at PAX Australia several times now, and each time the couple of months before the show has been incredibly stressful. (We've actually written a primer for first-time PAX exhibitors on Gamasutra previously.) Getting the current build polished up so that we have something to show the public was hard but necessary. The effort and expense that go into preparing a booth space are an investment—one year we even had official PAX pins made—and that investment will be wasted if you don't have a functional game.

Looking back, those pre-PAX crunch periods were probably the most productive times in Rogue's entire development. It damned near killed us, but it kept the project moving along.

Early Access is a mixed blessing

Committing to Early Access on Steam has been a very mixed experience for us. It certainly has its benefits, but we strongly urge all small indie devs to weigh up all of the pros and cons before committing to Early Access. The positive aspects are obvious, of course, and we would never deny that having real-world players enjoying our game and giving us feedback has helped to improve it.

That said, Early Access really is a commitment, an agreement between you and your players to keep updating the game, preferably on a regular schedule. Fail to hold up your end of the bargain and you risk alienating your players. I have friends in the industry who launched games in Early Access and committed to punishing update schedules—fortnightly like we did, or even weekly—and after exhausting themselves meeting that update schedule for months, they've found a major bug or caught the flu and ended up missing just one update. That single missed deadline nearly always resulted in a noticeable drop-off in the player count.

The ingame leaderboard machine, one of the social elements of Rogue Singularity

There are also marketing considerations to keep in mind. When you're finally ready to do your official release, you need everybody playing it at around the same time because that's when people are going to be sharing it, and talking about it, and streaming it. This will maximise your exposure, increase the likelihood that your game will trend of social media and reach a critical mass of media coverage that should result in strong sales.

Drawing your launch out over months of Early Access can rob you of that momentum. Too many developers get a lot of press attention when they first launch into Early Access, but by the time they are ready to release that interest has died down. Players, too, will lose interest given enough time in Early Access. Even our game, with its theoretically endless procedural levels, will only hold a player's attention so so long, and even the most hardcore fan will eventually take all the enjoyment from your game that they can.

We deliberately downplayed our Early Access release, because you don't get a second chance to make a good first impression. When you go to the games press and ask them to check out your game, if they already covered your Early Access launch they will ask you, with good reason, ‘what's so special about this release?'. Telling them that this time it's the real deal, the absolutely official version 1.0 release, will lead to many of them just shrugging and ignoring you unless you have something that makes a splash for the full release.

As such, you should ask yourself what you are hoping Early Access will achieve. Whatever benefits it provides, you need to remember that there will be drawbacks as well, and only you can decide if it's worth it.

So, should you do you make a game in your spare time?

It's tempting to answer “no”, but that's a little simplistic. You need to be really real about it, doing this kind of work, and the reality is that it's sometimes really brutal. You have to be willing to compromise, throw features overboard when they're not working, and just generally be brutal to your beloved electronic baby.

However, if you keep your scope modest and achievable, commit to the decisions you make, remember that your time has value, come up with strategies to keep progress rolling, and make an informed decision about whether or not to do Early Access, it is possible.

To get a taste of what no-budget part time game development can be like, I recommend trying out a game jam event, such as Global Game Jam. A jam compresses the entire development process down to one weekend, or sometimes an even shorter time, forcing participants to make hard choices quickly and to ruthlessly cut ideas that aren't working. If you find that you thrive in such a high pressure environment, maybe spare time game dev is for you.

We were lucky enough to have Nintendo show interest in Rogue Singularity and they exhibited Rogue at the Nintendo booth at PAX Australia 2017. Through this event and others, we have been building up and good relationship with Nintendo, and their support will definitely make the final stages of development easier. Being exhibited by Nintendo is rare and kind of like winning the indie game dev lottery, though, so you can't plan for it. The best you can do is make the best game you can and hope that a publisher finds out about it and likes it.

Now, if you'll excuse us, we have a game to finish.