In Golden Moose Studios' 2nd indiedev diary, they share mistakes made with their first prototype and how they recovered...plus tips for other indie developers!
This article is republished from Golden Moose Studios' blog.
In order to help others going indie (or thinking about going indie), we want to give back to the community a little by maintaining a certain level of transparency during our journey as independent game developers. That means it’s time for our 2nd IndieDev Diary entry!
We published our last indiedev diary just a few months ago, back in December. Given how much has happened over these last few months, it feels like we wrote that a blog post a lifetime ago already!
At the time of our last indiedev diary, we were deadset on getting a playable prototype ready to show potential investors for Summer 2017. We were coming along with animations, 3D models, concept art, story & world building concepts.
According to our internal timeline, we should currently be polishing our prototype and practicing our pitch before submitting the prototype (and additional materials) to investors.
This requires further explanation (continued below), but what ended up happening is that we started over entirely, with a completely new concept and a whole different game genre.
In this blog post, we will share many of our previous misconceptions and what happened along the way leading us to this decision…and causing us to shelve a game concept we spent approximately 4 months working on (and a decent amount of cash – remember, neither of us are artists, yet our game already had characters that were modeled, rigged, and animated…this equals money).
I want to start with what helped us realize we were going astray. We believe this part will be more useful to other developers than simply giving a list of where we went wrong. Hindsight is definitely 20-20.
Since I started in the game industry 5 years ago, I watch and read game developer lectures & articles almost daily. In fact, lunch breaks at Golden Moose Studios usually consist of our team watching game development lectures and applying other developers’ philosophies to our own experiences. (If you have any lectures to recommend, let us know in the comments below or tweet us @Golden_Alg! We love a good game dev talk!)
The thing is, indie gamedev is a lot like being a teenager – a parent can tell you all of the mistakes you shouldn’t make…but all that advice that doesn’t stop a whole bunch of teenagers, every generation, from making the very mistakes they instructed not to make! When it comes to gamedev, we found that just by “walking the walk,” we are now fully starting to understand the “should nots” of development.
By watching gamedev talks and reading blog posts – just like this one! – we heard (repeatedly and often) about all of the mistakes we eventually ended up making. These same mistakes have been made by multiple developers for years, yet developers will continue to make these mistakes.
It’s easy to hear developers talk about the mistakes they made in the past and then mentally gloss over them, “Well yeah, duh, that was a dumb thing to do. They should’ve known not to do that from the start, but it all turned out well for them in the end at least.”
As we quickly learned, it can be really difficult to see the mistakes as you’re making them (otherwise so developers wouldn’t make these mistakes in the first place!).
Now that we’re further into our indiedev journey – and hopefully a little wiser! – let’s talk about what made us realize we were going astray…
All right, now that we’re (hopefully!) on the same page that most developers (if not all) make many of the same mistakes and it’s extremely difficult to see these mistakes as you’re making them, let’s move onto how we got our wake up call.
Let’s face it, there are periods of time where, despite the progress you’re making, you feel like you’re getting nowhere (in the grand scheme of the production cycle). It was definitely disheartening to work for months on our game and still feel like we were nowhere near our goal.
This is where a “working break” saved the day. One late night discussion (and a bit of soju – we were in Korea after all!) led us to talk about a game design idea I had years ago – an idea I keep coming back to but thought was better left to tackle at a later date. As the design ideas flowed and we reignited that design spark, we decided to schedule a little reboot – a Saturday-long design jam pick-me-up that would (hopefully!) give us the mental break we needed from our actual game.
That Saturday, we figured we’d talk through design concepts for a few hours, type up and sketch out ideas, pat ourselves on the back, shelve it for a few years, and that would be that.
What happened instead was that, our design concept quickly snowballed into a flurry of ideas, inspiring another idea and another, ultimately kept us designing all day. (We wish now we had recorded that conversation!) There came a point where we had to tear ourselves away from the computer so we could get out in the brisk winter air for one of our frequent walks at Hannam University in Daejeon.
As we walked, it was the first time we discussed the possibility of shelving our “actual” game to work on this other game concept. It meant throwing away roughly 4 months of work (and the cost associated with it) and ceasing work with our freelance artist, animator, etc.
Despite looking at all the work we would be losing by doing this, we quickly agreed it was the right thing to do for us and Golden Moose Studios.
We quickly realized this new concept was a better fit for us in the long run, as:
It was a better fit for our skillsets (design and programming). This meant:
We could complete this project mostly in-house (and stop feeling like we were simply hemorrhaging money by working with external contractors, although we found some really amazing people to collaborate with and hated to see them go).
I would spend less of my time overseeing contractors (asset creation) and could spend that time actually developing.
We didn’t have enough experience with 3D models and rigs to know when something should be done differently. This is where you really need someone on your team who knows this stuff extremely well and can do a solid quality control check. (There were a combination of oversights that slowed production too much at times.)
Despite our best efforts, we fell into the overscoping trap. We thought we found a way to circumvent this issue – after all, it isn’t that hard to make a small story-driven game that is manageable enough to develop. We could always cut it down if we needed to…Yeah, there was a flaw in our thinking, especially when we didn’t have 1 dedicated story person! (I’ll get back to this further on in this article.)
We tried to accomplish too much with our first prototype. We were making a full vertical slice of the game rather than just proving the game concept worked. This, coupled with relying too heavily on contractors, made it feel like we were moving at a snail’s speed when it came to actually finishing something. At the rate we were going, it could have easily been 5+ years before we finished making the game, when our intent is to complete a game within a few years max.
We were trying to solve too many new problems at once. This included design challenges we haven’t even seen tackled by other games, as well as programming challenges that would take too long to overcome.
From the gamedev talks we’ve heard over the years, we heard countless times how important it is to:
keep your first project small,
play to the core competencies of your team,
fail fast.
It didn’t matter how many times we had heard it in theory – we really did make nearly every mistake in the book!
We certainly don’t condone scrapping months of work and starting on another project…not unless you have a really good reason…preferably, many good reasons. (After all, you don’t want to start a never ending cycle of projects and never complete any!)
When it came down to it, we simply weren’t able to gain the perspective we needed until we took that working break. It became much easier to see all of the issues with our “real” game by comparing it with our much smaller game idea.
Unfortunately, we held onto our first prototype longer than we should have, believing we needed to give design and programming issues more time to really see them out. It was a valiant attempt on our part, and it’s good we cared enough to try to see the concept through, but in hindsight, we should have put that project on hold a long time ago. I’m just glad we didn’t spend even more time on that first prototype and that we were able to let go of it when we came to that realization.
Shelving a project you invested time and money into can be difficult. Read about the principle of the “sunk cost fallacy” if you’re interested in the psychology behind this.
If you don’t have much outside input on your game, it can be difficult to know when you are reaching that tipping point. There’s a fine line between giving a project the time and attention it deserves vs. wasting your time. (That isn’t to say we won’t return to our 1st prototype at a later date – hopefully we will! – but we simply don’t have the resources in-house at present.)
You can read these tips a billion times and think you know their implications…but it’s a much different thing to experience them and therefore, take them fully to heart.
Disclaimer: There’s actually very little point in reading this list. These tips will sound ridiculous and elementary, but these are honestly the most valuable lessons we learned from starting a prototype that was too big and later realizing we should scale back.
Here are the highlights:
Play to your strengths.
Do what you or your team is best at.
Do not rely on outside help unless you’re able to do most of the work in-house.
For your first game, make sure you have 1 full time person working on each of the things your game needs (I mean, at least 1 full person for design, 1 full person for programming, 1 full person for story, etc.). It was not a good thing to essentially have ⅓ of a designer (who was ⅓ story and ⅓ business) and ⅔ a programmer (who was ⅓ story).
Keep it simple!
This sounds much easier than it sounds. Everything will take longer than you anticipate. We still have to remind ourselves to keep absolutely everything simpler. Give yourselves a break and simplify everything – the code, the design…absolutely everything. The design won’t magically fix itself when it’s prototyped!
Usually the simplest solutions are the most elegant. When it comes down to it, you want to make a game you can ship…not some beast that will take you years to develop! …Not for your first indie game anyway!
Again, all of this sounds stupidly simple now, and if someone told these things to us when we started, we may have said, “Of course we’re going to do those things!” We may have even explained away why we were doing the opposite in certain aspects.
In our minds, we were making the game we wanted to create, and we were going to create it no matter what.
However, a good adage to follow and some actually useful advice: make the game fit the team, don’t make the team fit the game.
Some food for thought: In a fairly recent interview, Ron Gilbert (Double Fine, Thimbleweed Park) said that even with 30 years of experience in game development, it was hard to avoid production issues, particularly without a publisher.
Some of my favorite quotes from the article:
“A good publisher will be there to pull you back when you’re about to derail. They’re look over your shoulder and keep you honest. They’ll question your decisions, and not in a bad way. They’re making sure that everything has been properly thought through.”
“‘Even with 30 years of experience, I still got caught with stuff on this game,’ he explains. ‘The recording of the voices ran way late—I should have had that done four months before it was. If we’d had a publisher, they’d have been telling us to get into the studio and just get it done. It all worked out well in the end, but it was a scramble.’”
Another challenge we weren’t expecting as indie developers is how difficult it can be to be your own producer (as Ron Gilbert alluded to in the aforementioned article). Over the course of my career thus far (in my assorted roles across the video game industry), I was once a producer.
Big surprise – it is significantly easier to be a producer when producing is your primary role… but when you’re designing, programming, arting, or otherwise working directly with the product as well, it can be hard to take a step back and see what the minimum is that needs to be done in order for the game’s vision to come across.
We’re in an odd situation at the moment, where we’re spending a year or so traveling across the Asia Pacific as we develop our game. We began our journey in Korea for nearly 3 months (check out our blog post on Korea if you’d like!) and are now Thailand for another 3 months, before a quicker trip down to New Zealand and Australia (too expensive to be down there long, but you can’t beat Hobbiton & LOTR scenery!) before circling back to Southeast Asia.
We were even able tomeet up with our California-based business lawyer, Zachary Strebeck, in Bangkok for dinner. Our apartment was just a couple train (BTS) stations away from him. The game development community truly is global!
At some point, we’ll write a blog post on the costs associated with traveling and dev’ing (otherwise known as “digital nomad”), but it really is affordable, especially compared to living costs in our hometowns – Stockholm, Sweden or the San Francisco Bay Area.
Since we flew all the way out to Asia, we figured we’d also see a few things along the way (Gangnam style anyone?!), rather than spend all of our time trapped inside an apartment!
This means that when we go to a new country, we typically spend the 1st week or two exploring the capital and then continuing on to a cheaper region for the majority of the time.
Contrary to what you might think, what initially seems like lost time (1-2 weeks off every couple of months) is actually hugely beneficial to us! We found that taking a week or two completely off from the project helps us gain the perspective we otherwise wouldn’t have without outside input (such as from a producer or publisher). (Of course, if you have a lot of outside input from a publisher, you should have some additional perspective, without needing to take time away from the project.)
Like the tips we mentioned above, this is also a hard one to explain without you experiencing this phenomenon yourself (taking time away to gain perspective). You may be surprised with how a few days, or even a full week off, can help!
In our case, we find that we get the “best bang for our sprint” when we gain some perspective and refocus our milestones.
To recap this now massively long blog post:
As someone new to indie dev, you will make mistakes – the same mistakes other indie devs made in the past. Probably some of the same mistakes we made. They may be mistakes you heard repeated at every GDC ever. It can be hard to avoid these mistakes, but you can try to minimize them by sticking to the following tips:
Play to your team’s core competencies. In other words, make the game fit the team. Don’t make the team fit the game.
Keep your first project small. The phrase “Keep it simple, stupid!” exists for a reason! What can you remove in your game to focus the player experience?
Fail fast. Make the smallest possible, playable thing and see if your design assumptions hold up. If it hasn’t been done before, it may not be the best idea for your first indie game!
Also, your milestones should be very short (such as feature X will be playable at the end of this week), and you should not make your prototype as if it were your final, shippable product. This is the time to cut corners! Just make your design playable and then test it. (If you need inspiration on corner cutting, watch The Fullbright Company’s GDC talk “The Programming of Gone Home: How to Succeed by Being Lazy.” It’s a simple concept but brilliant.)
Once in a while, everyone needs a reboot.
If you can only take a day or two off from indie deving, take a “working break.” Focus on a completely different concept. This could be an idea you had from even before you were a game developer. What new perspectives does this give you on your current project? Do you need to refocus your design, simplify your code?
If you are able to take a few days or even a week off, do it! Do it quarterly or do it every couple of months (if your team members are cool with it – I know this is advice contrary to the crunch trend). You may find it’s a little hard to get back into work again when you return, but you may surprise yourself with what you now think is the most important thing to work on. The ideas that come from time off aren’t always revolutionary! Sometimes it’s as simple as seeing the project with fresh eyes and realizing you don’t actually need feature Y that saves weeks of design or programming time. (You may use this time to just play more games, which is also a great help when you get back to work, as it well likely generate more ideas and inspiration.)
Now that we’re basically 2 months into our next prototype, we can confirm that we made the right decision to shelve our first prototype. Our milestones are shorter, and within our first week on this new prototype, we already had something playable.
It will, of course, take plenty of time to turn our concept into a full-fledged game, but we feel much farther along (again, in the grand scheme of production) than we did with all of the work we – and our contractors! – poured into our last concept.
There’s something to be said for tackling unsolved design challenges on the scale of what we faced before, but now our project feels more manageable on many levels. When it comes down to it, manageable is what you want for your first indie title.
Feel free to post your thoughts, experiences, and tips for us and other indie developers below! We would love to hear how working breaks, indie jams, even vacations have helped you and your team!
Also, if you’re in the Asia Pacific region over the next year (specifically Thailand, New Zealand, Australia, Vietnam, and possibly Cambodia), we’re always looking to meet other game developers!
Thanks for reading!
Contact: [email protected]
Sign up for our (very infrequent) newsletter!
Follow us:
Read more about:
BlogsYou May Also Like
