Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
We built 20XX over the course of four years, most of which ended up being public development via Early Access. We talk about the game's timeline, lessons learned, and how competition affected our development.
Hi! I’m Chris King, and I recently released a game called 20XX. 20XX is a Mega Man X-inspired co-op roguelite, combining classic action platforming with random level generation and permanent death.
20XX’s final visuals. We iterated a lot.
In this postmortem, I’ll go over the inflection points in our story, then talk a little more generally about what we’ve learned over the past four years.
--
Jump to the part of this post you care about by CTRL-F-ing between the bracketed text. For example, if you’d like to skip right to the lessons, CTRL-F for “[LRND]”.
Quick Facts [QKFC]
Timeline Detail [TMLN]
Lessons Learned [LRND]
--
20XX is built in a custom C++ engine. I built 20XX’s engine from scratch to build my resume, assuming I’d shoot for a job at a big developer once the game was finished. I started with one of those “here’s how you render a triangle!” tutorials, and built 20XX from there. We probably should have just used Unity.
Only 2 people worked on 20XX full-time over its four years in development, but 16 individuals created game content of some kind. “How big is your team?”
Production timeline summary:
Day One: July 1, 2013
Steam Early Access launch on November 25, 2014 (512 days into development)
1.0 launch (left Early Access) on August 16, 2017 (1507 days into development)
--
June, 2013: Development begins on 20XX.
I build a super-basic 20XX prototype, and use reddit (/r/gamedevclassifieds, /r/forhire) to find the game’s artist, Zach Urtes. We sign a contract for a “six month project,” complete with ridiculous overscoping and features we’ll never be able to implement. He creates the first Rollster model (seen below with the rest of my prototype art).
The first “prototype” picture we saved. Note the “ix” health bar - Nina was actually “model 9”/”Nine” at the beginning of development, but we had to change that when Mighty No. 9 became a thing. That purple column is a ladder, which we ditched from the final product. Ladders are terrible.
August 31, 2013: Keiji Inafune, the “father of Mega Man,” launches the Mighty No. 9 Kickstarter.
I spend the better part of a week obsessively checking their Kickstarter and the surrounding hype wave and generally feeling beat-up. I spend a lot of time (inadvertently - I thought I was just sulking) researching MN9’s value proposition, and I realize two things.
ONE: The incredible show of support for MN9’s campaign proves that there’s an unmet market need for that old-school Mega Man feel.
TWO: We’re both wearing our inspirations on our sleeve, but we’re very, very different games. I knew that trying to “make a Mega Man game” in the same vein as the classics was foolish, so I made some big design changes to stand out. Given my love of roguelikes and desire for strong replayability, we gave 20XX random level generation and permanent death. Given my love of scope creep and unreasonable features, we designed the game with local & online multiplayer in mind. These were both big selling points that MN9 didn’t have.
We almost stop working on 20XX entirely. Instead, I choose to believe that the world is wide enough for both 20XX and Mighty No. 9, and carry on.
January 1, 2014: Zach’s original contract goes past its “six month” expected period. (20XX releases 1,323 days later.)
We decide we’re going to show at PAX, and kick off our Kickstarter and Greenlight campaign in April, all at the same time. We pitch every reputable publisher I can find on 20XX, and are universally rejected. (We think those publishers made super reasonable choices; we weren’t a very good game at the time. We basically pitched with an ugly prototype.)
We start hunting for a composer. (Did we really pitch publishers with my placeholder music in game? Oops.) Our first choice is unimpressed with what we’ve done so far, and tells us so.
I remember how excited I was to send him that early build, and how crushed I felt when he didn’t want to compose for 20XX -- specifically because the project itself was bad. I felt defensive, but instead asked him for specifics - what’s bad? What can we improve? - and thankfully he gave us a laundry list of what he felt wasn’t working. It gave us a lot to chew on, and the game got better for it. It also taught me how to extract information from criticism. This ended up being one of the pillars of 20XX’s development.
We find our composer in Brandon Ellis (aka Cityfires), who’s responsible for all of the awesome music that made it into 20XX. Brandon nails the tone we’re going for, and the game instantly improves by leaps and bounds. A++ 10/10 would recommend.
April, 2014: We show at PAX East, start our Kickstarter and Greenlight campaigns simultaneously, and generally just sort of hate ourselves.
Kickstarter is a full time job, and we decided we just wouldn’t be around computers for the first days of it. If you’re going to combine KS with a big show, start the KS after your show and aggressively collect email addresses from the people who dig your game on the expo hall floor. Your sanity will thank you.
We learned a lot from our first PAX -- those lessons are here from when I wrote them up a few years ago. Past-me probably said it better than present-me could, anyway.
Kickstarter was miserable and stressful, and we were right on the fence between making it and not the entire time. In hindsight, we ran the campaign way too early and would have done better if we’d waited for better visuals, but we didn’t know we were going to expand the scope at the time. Our messaging was also pretty flippant/unprofessional, which likely hurt us.
Our Kickstarter month was the most stressful month of my life. We would not have survived this period without the incredible patience and support of some of my closest friends, most notably Bianca (early marketing/social presence/got us some attention at East/put up with all my mopey garbage during Kickstarter/agreed to marry me which is pretty great), DJ (did not agree to marry me but built our initial internet presence, which we sorely needed), and Chase (playtested the crap out of our early builds and just generally supported my game development while I was making garbage).
20XX’s visuals as of April, 2014 (first PAX showing + Kickstarter).
September, 2014: We team up with Fire Hose Games.
I meet Eitan at an IGDA meetup. We agree that he can help us make the game more professional so we can actually sell it. This is one of the better decisions we make. Eitan has a lot of industry experience and connections that I lack.
We expand the project’s scope a good bit. Instead of releasing the final product in November, we agree that we’ll release the Early Access version, and build the rest of the game in front of a live studio audience.
November, 2014: 20XX launches on Early Access.
On Day One, we sell 64 copies of 20XX. I’m thrilled. We make a series of promises to the community up front, and do our best to keep them:
We set a strict bi-weekly update schedule, promising that during Early Access, we’ll push a patch every other Wednesday by 6:00 PM Eastern. We add a clock in game that I update every patch that clearly says when the next update is coming. Folks love update clocks - if you’re certain you can patch your game on a schedule during EA, add one. It earned us a ton of goodwill with the community, and gave us a reliable, routine way of getting feedback on our latest work.
Don’t do this if you aren’t certain you can meet the schedule - promising a schedule and not delivering is worse than not promising a schedule. IIRC, we missed two update deadlines out of over 70 - one by a day, and one by an hour.
I read every single post on our Steam Community, every post on our subreddit, /r/20xxgame (/r/20xx is taken by a different, defunct 20XX), and every email. I reply to every single one, and as the community grows, a number of our veteran players rise to take on some of the more common questions for me.
We owe a big chunk of our success to reasoned evaluation of feedback over a long period of time. Strip the emotional content of your user feedback before evaluating it - it’s awesome when fans love your game, but don’t greenlight a suggestion solely because a big fan made it. Don’t block out good suggestions made by assholes, either.
I’m as open with the community on what we’re working on as I can possibly be, and let their general consensus impact our schedule. If lots of players have a specific pain point, I’ll usually stop what I’m doing to fix it. If the majority of the community thinks we’ve made a misstep, we sit down and seriously evaluate whether or not we’re in the right.
A few weeks before our beta launch in Sept 2015, we spent a ton of time revamping both Ace and Nina’s character designs.
ABOVE: 20XX's pre-redesign characters (Summer 2015).
BELOW: The "failed" redesign (August 2015).
The new designs got the most overwhelmingly negative community feedback we’ve ever had. We had some tough talks, dropped everything we’d planned on doing before our beta launch, built better versions of our old character designs (using the lessons learned while making the “failed” designs) and could cut entirely new trailers and media just in time for our beta launch.
Redesigned characters. (We still revamp them one more time before launch.)
The resulting publicity push was the biggest one we ’d had to date by an order of magnitude. I’m pretty sure if we’d stuck to our guns and said “these are our characters now,” we’d’ve died in the water right there.
Note: being “open with the community” does not mean overpromising. Share what you’re sure about.
March, 2015: Realizing the game needs visual direction beyond what our team can provide, we hire Clemens Scott.
Clemens (most recently the amazing artist of Old Man’s Journey, by Broken Rules) spends six months with us, bringing the game’s visuals up from “unattractive” to “polarizing” (a huge improvement). 20XX’s current marketable form would not have been possible without Clemens’ help.
April, 2015: We show at our second PAX, this time with the lovely Indie MEGABOOTH.
It goes much better than our last showing, and we even get some press! Later in the month, MANvsGAME and Zeke (Ezekiel_III) start streaming 20XX at 2 AM while I’m at Bianca’s (then-girlfriend-now-fiancee-also-ilu-Bianca) parents’ house, and none of them kill me when I watch it until they stop at 5 AM. Reception to our first batch of Clemens-improved environment art is encouraging; maybe this is the real deal. We sell another 64 units in a single day, and I’m Christmas-morning-excited about the whole thing.
Mighty No. 9 announces their first delay to September 15th (4.5-5 months). This isn’t a big deal. Delays happen, and (other than the timing) they do a good job of explaining what they’re up to and why the game’s been delayed.
May, 2015: Money’s super tight, and Bianca mostly supports us personally. She is a saint. I take out a loan so I can afford to continue to pay Zach.
August, 2015: Mighty No. 9’s second delay happens. This one is less well handled. (Lots of good articles about it hit around the same time - here’s one that does a good job of explaining it.) The MN9 team burns a lot of goodwill, and we decide this is our shot at a pressworthy story.
We announce that 20XX will finally be entering beta on the day MN9 is no longer using as a launch day, and it sticks. We get a more concentrated press hit than at any time before or after (including our final launch), and we go from selling nothing to selling a pretty reasonable amount.
We’re still way in the red on the project, but from here on out, 20XX generates more money than it spends. The influx of fans, money, and feedback lets us take the game farther than we previously thought possible. Over the coming months, we maintain a stable sales rate and I eventually pay back the loan.
January, 2016: 20XX has grown, and we decide we need community feedback before each patch.
We start our “Superfriends” group, aimed at getting early builds of game content in front of 20XX’s biggest fans for feedback before they go live. We try our best to make sure the content Superfriends get is interesting. Seeing new items and stages before they go live is awesome; “test our engine changes!” is not.
We give them super-early-access to the game’s final stages, which ends up being a godsend. Our first builds of these stages needed an embarrassing amount of refinement, and the feedback we get from our Superfriends is a critical component of that refinement.
May, 2016: We decide 20XX should have a few cutscenes (“all professional games have a few cutscenes”, we said), and start hiring.
Cutscenes prove to be really difficult to get right. We go way over budget, and the entire process ends up taking 14 months. None of us are experts on this sort of thing, so communicating exactly what we’re looking for proves difficult. We get the scenes before 1.0 (by two weeks), but having gone through all this, I feel more like we survived it than that we really learned a lot.
June, 2016: Mighty No. 9 launches on PC.
“Play this instead.”
In the weeks leading up to MN9’s release, 20XX’s “most helpful” review on Steam read “Play this if you’re tired of waiting for Mighty No. 9.” Mighty No. 9 comes out, and it’s pretty okay, but doesn’t live up to the hype it built. The review changes. Fortunately for us, MN9’s release date lines up nicely with the Steam Summer Sale, and 20XX is well-positioned to benefit from the hype-vacuum MN9 leaves behind.
From here, 20XX’s development follows a pretty straightforward pattern. We maintain a resting sales rate we’re happy with, and mildly discounting the game (20-25%) during big sale events treats us well. It’s mostly smooth sailing until our 1.0 release in August 2017.
December, 2016: We launch 20XX’s “piecemakers” experiment, aimed at teaching the game’s fans to use my really-awful level design tools.
The game’s tools suck, and we fail. Out of a hundred or so volunteers, two players submit segments, only one of which makes it into the game. This is 100% our fault - our level design tools are clunky and have a steep learning curve.
Making a better editor becomes a post-1.0 concern - we’re still (as of now, Nov 2017) figuring out whether or not this is a feasible project for 20XX. (If you have experience making a good level editor, get in touch!)
August, 2017: After 71 consecutive bi-weekly updates, 20XX releases on PC, leaving Early Access.
We make a new trailer, but it’s still 100% action-oriented. (We’d love feedback on this - we think there’s lots of room for improvement here.)
One month in advance, we reach out to pretty much every influencer who’d either covered us in EA or told us they’d cover us on release, and wrote lots of non-form-letter individual reachouts. We didn’t get much back. Three big outlets told us they’d cover our release, and of those, one came through. (Tim’s video is amazing, even if you don’t like 20XX.) The day the Kotaku video is released (day 3 of our launch week), our sales spike up ~30% compared to the previous two days. It’s hard to pinpoint how much of this is due to the video -- 20XX has always done better on Fridays and Saturdays -- but it definitely has an impact.
We spent a good chunk of our launch week between #20-25 on the Top Sellers list. Steam’s organic visibility saved our butt. Despite our failure to get press/influencer attention, Steam’s algorithm deemed us worthy, and we performed pretty competitively with similarly scoped titles that released that week.
Final product.
--
Early Access was a huge win for us. We’ve learned a lot about it.
--
“What’s not done?” If the thing that isn’t done is “delivering your core hook,” don’t launch in EA. If you release a pretty game on Early Access that doesn’t live up to your game’s core promise, you’re going to get bad reviews. If your game delivers on its core promise, it’s okay if the content isn’t finished/it’s a bit buggy here and there.
"Does my game play better than it looks?" Your sales (in Early Access, but also in general) depend on your Storefront’s appeal. Your reviews are based on how well your game delivers on that appeal. 20XX’s review score was better when our game looked worse -- anyone able to look past the game’s art knew exactly what they were getting into, and every version of 20XX we released on Steam lived up to the tight platforming and crisp controls Mega Man fans expect.
"Is my game's impact repeatable?" If your game is meant to be played again and again, you’ll have better luck getting your players to keep playing as you develop it.
"Can I afford the time burden EA puts on my team?" As 20XX’s main designer and only programmer, I spent 10-15 hours a week interacting with the community and fixing bugs that I couldn’t push down the line because they actively harmed the 20XX experience. You might be able to hire someone to handle these interactions, but unless that person really feels like part of the dev team to the community, it won’t pay off. You can’t avoid having your schedule bumped by must-fix-now bugs, either.
"Am I ready to establish a public update schedule?" Establishing a strict release schedule and properly supporting it (fixing gamebreaking bugs same-day, etc) earns a lot of community goodwill, but trying this and failing -- either routinely delivering late, or delivering broken stuff you can't fix -- is a great way to burn goodwill.
"Do I want player feedback?" Having a community help you tune your game and identify pain points is awesome, but only if you're actually going to use that feedback in ways they can see. (If your veteran players don't think you're at least reading their feedback, they'll stop giving it.)
In general, players are wary of Early Access developers for the same reason people shy away from Kickstarter. Trust is earned.
The standing Early Access advice of “you only get one launch” holds up in our case, but when that “one launch” happens depends on the influencer. 20XX has been covered by most major press outlets and by a handful of influential streamers exactly one time during its development, all at different times.
Whether or not this is a good thing depends on your team. If we could have funded 20XX all the way to the finish without the extra revenue and player spikes from our Early Access press hits, being able to cash them all in at launch would have been a strong play. That assumes you can get the coverage all at once, though. You don’t usually have control over when your game gets covered.
For the record, we couldn’t have funded the game fully without the publicity spikes we got in Early Access. If you’re a smaller developer, be happy to get press whenever you can, and don’t think too hard about the consequences for your “final launch.”
It’s very possible to gain traction after a “failed” EA launch - if you understand why it failed. 20XX entered EA with lacking visuals and an unimpressive Store Page, and made zero noise as a result. We greatly improved 20XX’s systems/gameplay over the course of EA, but a user seeing your game on the store page for the first time doesn’t know that -- all they see is what’s in front of them on the game’s surface. Art sells games.
--
Early Access is a great barometer for what issues your game might have (as defined by the relationship between your trailer/screenshots/storefront text and the game you’ve released). Pay attention to your negative reviews! (Read the positive ones, too, but really dig into the negative ones.)
20XX has four kinds of negative reviews:
technical issues, where a user has an issue with actually getting into the game and playing it,
“but I didn’t want a roguelike!” reviews, where a user buys 20XX without paying attention to its roguelike elements,
“useful” complaints where the user identifies what they didn’t like about the game,
and “garbo” complaints where the user gives a thumbs-down with little to no information about why.
“Garbo” complaints happen to everyone, but they’re still valid reviews. I’m not making an effort to discredit them. Not everyone wants to take the time to tell you what your game could do better, and that’s okay.
For charting purposes, I’m counting reviews where a user cites incorrect information as their pain point as “useful”, because it at least tells me how my game was perceived. If enough users see your game world differently than you intend them to, you have a messaging issue.
I set the bar for what I’m counting as “useful” pretty low.
This is a “useful” review. The user plainly states he dislikes the game because of the art. Note that our in-game models aren’t “flash-tweened,” nor did we ever say anything about building hand-drawn sprites.
Here’s a breakdown of 20XX’s English-only negatives. (We localized into 8 other languages in June 2017, and it’s harder for me to be confident about what those reviews are saying. More on that later.)
There’s a lot for us to digest from the chart above:
31% of our negatives came from the the “roguelike?!” crowd, meaning we had a messaging failure. 20XX’s store page calls itself a roguelike multiple times on its store page. It’s the fourth word of the game’s top text, and the fourth word in the game’s description. The description called out the random levels and powerup sets, and we thought that was good enough. We were wrong. Much later in development, a user suggested we call out the specific roguelike elements 20XX brings to the table - we did that, and the frequency of those negative reviews decreased sharply.
There’s a confounding factor here, too -- many of those negative reviews were part of the MN9 publicity rush, where people expressly purchased 20XX as a “MN9 alternative” without looking too much into it. Still, a good chunk of these reviews are the result of a messaging failure.
14% of our issues came from people having tech issues or controller issues. In an engine that dealt with all controller types perfectly from the get-go, about half of these reviews would never have been made. (Steam Controllers don’t support DirectInput fully -- multiple controllers are detected as one device, which isn’t great, and caused more than one negative review.) The other half are people trying to play the game on potato computers, which we can’t do too much about.
No matter how low your specs are, someone will play your game on a potato and complain. Know when to say no.
The above two issues represent failures on our part. Assuming perfect messaging and controller detection from day one, we can conservatively estimate getting rid of half of the 45%-slice of the negative review pie caused by technical/”a roguelike?!” issues, which would comfortably bump us back into Overwhelmingly Positive. (We don’t know conclusively that Overwhelmingly Positive boosts sales, but we believe it does.)
38% of our negative reviews involved the user actually saying what they didn’t like, which gave us a lot to chew on. More than once, a rash of negative reviews about a certain topic made us realize our EA product had a glaring deficiency we needed to fix, and we shifted gears to get it taken care of. Read and pay attention to your negative reviews!
This is another instance of EA forcing you to move your schedule around. You might be fully aware certain things need a rework and have them scheduled in your backlog, but if they’re causing your EA users pain now, you have to move that task up.
When a user posts a negative review, engage with them, even if they’re a garbage review. Many users that want to see the game improve will respond with additional feedback, and sometimes even change their review. “Right after the review is posted” is usually your only opportunity for this - if you wait, they’ll be gone. I’d estimate one user in four changed their review over the course of EA after I listened and responded to their concerns, which (to me) is an awesome conversion rate.
On the other hand: on our out-of-EA launch day, I wrote 70+ comments to users who’d posted negative reviews, many of which “hoped the game would get better on release.” Two users responded, played the game, and changed their review. One user changed his review from positive to negative, and weirdly turned into an overnight banworthy forum troll. Users who have already moved on from your game negatively during EA are probably not coming back. Count on their feedback as final.
Steam’s refund system is pretty good for (most!) developers. Players buy with confidence because of the 2-hour no-questions return guarantee. Downside: many negative reviews are instantly set in stone, since the user often refunds the game before writing the review. There’s no room for interaction unless you openly give that player a key to try it out, which feels scummy (and sends a bad message to your happy players).
--
20XX succeeded (in part) because we treated our Early Access community right. Some benefits of treating your community well in Early Access:
Players are much more likely to report bugs and go to great lengths to document them (videos, etc) when they trust that you’ll act on their info. However you track bugs, make sure you respond to user posts in a timely fashion. For example: netcode testing is a nightmare for a developer working alone. In the weeks leading up to release, we had multiple users submit long, annotated videos full of bug descriptions, including one that was edited down from 4-5 hours of footage!
When you build a community that loves your work and respects your time, members of your community will come to your defense when they come across someone shit-talking you or your game, which is usually great. Building a community means not having to answer the same questions over and over yourself, since your fans will handle the softballs for you.
This has an extreme case you need to be careful of, too. Zealous fans will sometimes block out legitimate dissent. It’s one thing when your fans shout down an obvious troll - it’s another when someone explains an issue they have with an aspect of the game, and your fans attack them for it. It’s important to set the tone where you can - 20XX’s forums are for all discussion about the game, not just praise.
This one’s obvious, but the fans you please the most will tell everyone they know about your game. Maximizing your k-factor is a real thing, and fans that love you tell more people about your work.
Don’t make promises you can’t keep. If you have an update schedule, stick to it. Make cuts to updates that might miss their target to get them out on time. Don’t promise a feature in patch X unless you’re 100% sure it’ll be in there. Use uncertain language if you’re not sure you can get a feature in on time -- “we’re shooting for this feature on day X, but we’re not sure we’ll get it in shipping shape in time yet.” Don’t set your release date until you’re 100% sure you’ll meet it. (We might be oversensitive about this last one because of our competitor’s failings, but it’s a good practice.)
Manage expectations. When you know you’re going to fall short, tell your community as soon as you can. If an Early Access feature is pretty rough, state it upfront: “This is an early draft of Feature X, so please give us feedback!” If you have to delay a patch or other scheduled deliverable, tell your community as soon as possible. No one likes delays, but players respect a developer that does everything they can to keep the player in the loop about when a deliverable is coming, and infrequent delays are usually tolerated with no loss of goodwill if they’re well-communicated.
No lying. It’s more trouble than it’s worth. Having to remember what you said that may or may not be true a few years down the line is a lot of emotional effort to get right, and you’re usually better off long term just coming clean with an issue.
Make sure all constructively-expressed opinions are welcome. Set this precedent yourself. This dovetails a bit from the zealous-fan thing above, but it’s important that your users respect people with different opinions, or you’ll block out both potentially useful feedback and new community members. This applies to both forum posts and review comments.
Listen to your players. They’re giving you feedback about your game because they’re passionate about it. Strip their comments of emotional content, and evaluate their suggestions neutrally (this takes a lot of practice, so work on it). You’ll get lots of suggestions exactly one time that end up making your game better because you hadn’t thought of them/experienced a specific pain point, and you’ll get lots of suggestions that are more “hivemind”-based, where a good chunk of your community feels a certain way. They’re both important, and figuring out which feedback to act on and which to say “sorry, this isn’t the direction we’re taking!” is good both for the game and for the community.
Be ready to accept that you might be wrong. This is your game, but if you make a change that’s universally disliked by the community, you might want to rethink your position, and at the very least, you need to clearly explain your stance on the issue. (This is part of “listening to your players.”)
Stay professional. When a player with 0.2 hours played leaves a negative review that says “not enough content”, resist the urge to call that player a laundry list of (apt) foul names. They’re wrong, but saying so yourself in public doesn’t get you anything, and just makes you look bad. (I’m of the opinion that it’s okay to let your players dump on these reviewers, but YMMV.)
Help everyone (efficiently). The goal: for every avenue of communication with you, the developer, make sure everyone gets answered. Doing this efficiently means directing players to make contact via methods your fanbase can intercept for general questions. (Bug submissions should go to a bugtracker - that’s different.) Make an FAQ of common problems if you don’t already have one, and link people to it. With 20XX, we left a support email accessible in several places where we should have put a Steam Community/subreddit link - it’s important that your users can get in touch, but I too-often had to write email responses to players with issues covered in the FAQ.
Be aware that when you localize your game, you’re going to lose connective power with part of your community. Google Translate only goes so far, and you’re (probably) not hiring CMs for each language you’ve localized to. This hasn’t been awful for us, but there are definitely users I can’t adequately respond to and reviews I can’t properly interact with because they’re in languages I don’t speak, and my Google Translate responses don’t quite get the job done. If your game is currently in a technically-unstable state, consider holding your localization patch until it’s stable.
Having creative and business control of a project is awesome. It’s also hard.
Your motivation is 100% internally-generated. Going from having a boss helping you figure out your tasklist to having to chart the entire course yourself is a rough transition, as is being responsible for setting your own deadlines. Be prepared to invest time figuring out how you work best. For example, I’ve learned that I do my best technical work in the morning, which means I try to do business stuff later in the day. No matter what time I get up, if I start my day with video games (say, I get up an hour before my normal wake-up time), my day’s down the tubes. It’s really hard for me to shift from game-mode to work-mode.
Identify your team’s best work modes, too. Don’t interrupt your team when you know they’re doing their best work - if your artist is best in the afternoon, don’t schedule meetings with him/her in the afternoon. If your artist has “feast/famine” cycles where they sometimes just get in the zone, tell them it’s okay to ask to postpone meetings with you if they’re in that good good place.
Strict scheduling helps. A nice bonus of Early Access for us was setting goals for each patch, so I had a very real measure of how productive the team was from patch to patch.
Be prepared to develop a strong sense of guilt. Unless I can justify taking a day off in advance, nothing makes me feel worse than ditching my workload early to go play games. This might be controversial, but guilt was a key player in my self-motivation strategy while making 20XX.
When struggling with motivation on a specific task, switch gears. You’ll get a feel for when this works and when it doesn’t, but if you find yourself constantly tabbing to Twitter on your current task, see if there’s something you’re a little more excited to work on to tackle. This obviously has limits - you still have to tackle that task eventually! When you’re really not making any progress, though, it’s often better to do something else for awhile than slog through your boring task.
DON’T PLAY MMOs. Seriously. Just don’t. The social features of these games are deadly for self-motivation, and it’s really easy to justify spending big parts of your days accommodating your habit. You may have analogous weaknesses - games that, when you’re invested in them, become really tempting to play during the day and are hard to put down/not easy to play for 15-20 minutes in a sitting. Don’t play them. They’re traps.
If there’s no one on the team making the go/no go call for each type of game element, you’ll release garbage. You’ve hired your team because you trust their judgment and skill in their area of expertise. When they do awesome work, this is awesome.
When they do sub-awesome work, someone on the team has to be able to tell what’s wrong with it, and how best to move forward (scrap and redo/improve a few things/use as-is because of time constraints/etc). Learning to do this professionally is hard - nobody likes to hear that a piece of work of theirs isn’t usable as is. On the other side of this, “takes criticism well” is an awesome trait in a team member.
If you’re the head of a small team, you’re the last line of defense in every category. If an in-game model or audio track doesn’t fit what you’re looking for and you don’t evaluate the cost of fixing it, it’s your fault -- not the asset producer’s -- when your players don’t like it. Similarly, if the asset produced *does* fit your vision and the players don’t like it, that’s your fault, too. Small team projects live and die based on the collective vision of the team and their ability to realize it.
Project Management is super important. Don’t work on tasks arbitrarily until they’re done - keep a backlog of the things you need to do, and periodically meet to decide which ones will get done by the next meeting.
Take care of yourself. Make healthy choices. Doing this job from home full time is emotionally taxing. You don’t see other people during your workday, so if you don’t have a routine hobby that involves seeing other people in person, you might want to find one. Not seeing other people on a routine basis does weird, bad things to your mind.
When you spend so much of your week at home alone, it’s very easy to fall into unhealthy eating habits. Do whatever you have to in order establish a healthy routine. Spend some time outside! If you can, spend some time working in coffee shops. (I have trouble doing this. It’s too distracting for me.)
Sometimes, this tip and the “keep your promises” tip conflict, resulting in crunch. Crunch is acceptable in small amounts, but it’s definitely an admission of failure (Hi, Tanya!). Avoid crunch by picking reasonable workloads and deadlines, and if you have to ask your team to work overtime, do it sparingly.
Self-selected crunch (when a team member is super passionate about what they’re doing at the time, and chooses to work overtime on it) is fine, but be careful that your culture doesn’t shift towards crunch as a result. If half your team is voluntarily putting in 60 hour weeks, your other team members might feel like they have to do the same to be “team players.” This is bad.
If you live with a spouse/partner/SO, be aware that your work arrangement might cause friction. YMMV, but my fiancee and I had to put in significant work with making the “CK is always at home” arrangement work. The fact that your office is your partner’s home is not easy.
--
Don’t launch a Kickstarter campaign if you aren’t ready to devote 100% of your time to it. You’ll need to, and if you’re not able, you’ll go through more stress than is necessary.
If you want to sell your game, do some market research upfront. Make sure there’s room for you in the market - if there are other games like yours, does yours really stand out?
--
I spent four years building my first game team, making the game I’d dreamed of since childhood, and getting super lucky because someone else built a hype wave my game could ride.
I’ve learned a lot along the way, and hope what I’ve shared will help someone. If you’re reading this and have other questions, feel free to reach out on twitter or via email (chris AT batterystaplegames DOT com).
Thanks for reading!
Read more about:
Featured BlogsYou May Also Like
