It’s been two months since MAGFest, so I’d say it’s about time for another one of these. With plenty of time since our last large public appearance, we’ve been developing the alpha build for our mailing list subscribers, which we sent out last Friday. The game has come a long way since that showcase with some new features, so let’s take a quick look at what Runaway veterans can expect:
Two New Game Modes
We’ve created a new Capture the Flag game mode in which players compete to steal the opposing team’s flag and bring it back to their base to score. Whoever reaches the max score first wins. We’ve also added a free-for-all version of our Last Gang Standing mode called Deathmatch. In this mode, players lose a life each time they are sprayed and replenish lives by tagging signs scattered across the map. The last player alive wins.
A little sneak-peek at Capture the Flag when it was first developed
A New Level - Peak
A new level called “Peak” is playable in single-player Time Trial and two-player Tagging Race. The level is our take on a parkour race: each player competes to reach the top of the symmetrical race track first. This level placed a larger emphasis on verticality than past levels so that players feel like they’re climbing and not just running.
A preview of the level layout
A HUD Overhaul
The heads-up display (or HUD) is all the text and graphics used to give the player information about what’s happening in the game. The most basic example in Runaway is the arrows that point toward tagging targets. The HUD has gone through a major overhaul to improve readability and accessibility to all important information. Before, each player’s screen only gave a small amount of info relevant to that player.
In every team-based mode, we now show the team logo above each player’s head as well as every sign they’ve tagged. This was a move for accessibility because color-coding doesn’t work well for color-blind players, and the color coding made it hard to see any details on the characters or their tags. Now, you only have to compare the logo above your head to the logo above what you’re looking at. If they’re not a match, then spray away.
We’ve also changed the way we show score in each game mode. We’ve shifted away from showing only each player’s score on their own screen to putting all the score in the center. For example, the Deathmatch mode used to show each player’s lives at the top of their part of the screen. It wasn’t hard to see how many lives you had, but you’d only know how everyone else was doing by looking at their screen. We’ve since made it so each player’s lives left are shown right above their character's head. That way, you only need to get in view of someone to know whether you should chase them. We’ve also put headshots of the characters into the center of the screen where it’s easy for everyone to see. When a player loses, their headshot is grayed out. Down the line, we’d like to also add a giant X graphic to make it more noticeable at a glance, but this was a good start.
The Deathmatch HUD in action
New Artwork
Just about everything in the game has gotten a face lift in a new style. The characters have a whole new set of animations that we like to call “graffiti in motion”. The background has shifted away from pixel art to an illustrated style. We have new tag artwork (a lot of which came from the graffiti board at MAGFest) as well as a concrete tileset. While the concrete is a placeholder, it gives a better sense of the style we are going for than the pixel bricks we’ve had in the game up to this point.
To give you all a sense of how big an event this is for me, this is the first time in the two and a half years I’ve been working on this game that people I don’t know personally are able to download my work onto their own machines and play it on their own time.
Events like MAGFest are fun, but they’re also incredibly nerve-wracking because I must watch as something I’ve poured my heart and soul into breaks… Time and time again. But at least I’m watching. When things go wrong, I’m right there to do something about it. And even if I can’t fix it in the moment, I know I’ll get to it. Not to mention, when people enjoy it, I can share in that with them. Sure, some people may not understand my vision. Or worse, they get it and yet disagree with it wholeheartedly. Facing that doubt is troubling, but understanding why they feel that way can help me to build a better game. At least then, I can discuss it with them so that, even if we disagree, we know where the other is coming from.
Now, I must give up all of that. I’ve built a nice little boat for this game, and it’s time to let it sail on its own. From there, I can only hope that people who find it will help it get to where it’s going. I can only hope that people will tell me it’s doing okay - or how I can help it to be okay. Like I said, this is big. It’s scary, but it’s also necessary. I can’t keep it to myself for its whole life. I have to share it with the world. I had to make the boat, and now I have to let it sail.
So, I’m writing this for everyone else in the same position as me, now and anytime down the line. I want my experiences to help you prepare yourself for this inevitable time when you put your work out there. When you express yourself, you want nothing more than for someone else to be able to relate. You crave it, that someone can see it and immediately understand what it means to you - more than that, to know that it means the same thing to them. But you can’t be sure how your work will be received until you put it out there, and your gut will endlessly convulse in anticipation. The closer you get to that inevitable release, you will review in your head each of the steps you’ve already gone over a thousand times to make sure you aren’t missing anything. And yet, you’ll still have the nagging feeling that you are forgetting something, something important.
But it will be okay. Things may go wrong, and that’s alright. You’ll learn to adapt. The majority of people will be understanding of your shortcomings. There will be probably be shortcomings, and that’s fine. The issue won’t be in what comes up but in how you handle it. And that’s why I’m here.
1. Plan on things going wrong.
My best advice is, plan on things going wrong and take steps to make solving those problems as easy as possible for everyone involved. To that end, we included with the download a nice little guide (which Olivia did an amazing job designing!) with the basics to play the game. In it, we also put links to a general feedback form as well as forms designated for bug reports and suggestions. Just in case those were all too formal, we also created a Discord server where people can more easily and quickly get in touch with us. That way, they have several options to let us know there’s an issue. On Discord, we could also follow up easily in case we needed more information. Likewise, the bug reports form requests (but does not require) the submitter’s email address and a space to include links, just in case they took screenshots or recorded videos of the bug. I even considered implementing a bug reporter right in the game, but it seemed a little excessive given that most people will be playing with a controller anyway. Maybe next time. Realistically, not many people will read the document, and most won’t use the feedback forms. A small group of people who have tried the alpha have migrated over to Discord as well. Statistically, our playtesters are not likely to use these tools, but at least we gave them the option.
In the build-up to the release, I hoped that, the moment the email went out that Friday, I could let out a sigh of relief and take an extended weekend to relax. That’s not how it played out, so I had to act. The next day, I was at a small Drexel event where Runaway was on display, and it did not take long for me to discover a bug. In fact, the bug surfaced before the event actually technically started. Granted, it wasn’t game-breaking per se, but it still was immediately and incredibly noticeable anytime the player went into a specific game mode. Once I got home from the event, I immediately booted up Unity and got to work. I had expected it would take a few hours (as bugs in the game’s UI tend to) but it luckily took maybe half an hour or so. I replaced the online build and then posted in the Discord announcements channel to let everyone know what the issue was and that it had been fixed. A couple of days later, I discovered another bug, and so I had to repeat the process.
2. Test early and test often.
Of course, planning for the worst is good, but it’s also good to take steps to prevent it from even coming to that. For that, the best advice is to test early and test often. Put your game in front of as many people as possible, both internally and externally. If you’re working with a team (which is usually the case), then have them test. Everyone will likely have different ways of playing, so you won’t necessarily need someone with 10 years of QA experience to do an extensive search to find some of those pesky bugs. It’s a little tricky for my team to test much because we all work remotely, making it hard for me to lend anyone controllers. What we do have going for us is that, in my experience so far, Runaway isn’t very resource-intensive, so at least anyone with a semi-functional computer and a controller should be able to play without much hassle. But even if you don’t have a team right there to test, I’m sure you have other options, be it friends or family, neighbors, classmates, and the local community. The internet is also a great resource, as there are plenty of communities dedicated to helping people develop their games.
3. Set clear goals.
Beyond that, make sure you have clear goals. You need to know what you want to get out of your demo, what you want to put into it, and what comes after. The adage is a little vague, so let’s explore in a bit more detail what that means. First, you need to have a sense of what the demo is for - why you’re making and releasing it. Do you want some feedback on the mechanics, art, levels, or something else? Or maybe you’re hoping for a little promotion or mass testing. Whatever it is, knowing what you want to accomplish by releasing a demo will help you to determine the scope of it. That way, you can focus all your efforts pre-release on furthering those goals. In our case, we wanted to get feedback on how the game felt (especially whether/what parts of it are fun). Because of this, we added a bunch of different game modes (to see which ones stick) and gave our players a few ways to get us their feedback. I’ve also added analytics into the game to see what our players are (and aren’t) up to. It’s also a good idea to decide early what you plan to do after the demo is released, both short-term and long-term. In the very short-term, know how you’re going to spread it. Know whether you plan to update it as you work on it and issues are found or if you will keep it pretty static. This choice really depends on you. If you plan to do a lot of development on new features immediately after release, I’d recommend keeping it static so you don’t distribute half-baked and broken features. However, if you’d like to do little bugfixes as they’re found, then go for it! And of course, have a long-term plan ready. It should be flexible in case you get hit with big bugs you need to fix quickly or have any revolutionary feedback (like that your game just isn’t fun yet). But either way, having a basic game plan will give you direction so that you keep your momentum after the release.
4. Analytics are cool to look at.
Overall, we have 58 views on our itch.io page and 30 downloads, which is roughly half. Interestingly enough, that has been pretty consistent on the day-to-day too, but it’s hard to say what it means. It could be that half the people who visit the page check out the game and then decide against downloading it. That, or one person goes on the page, leaves, and then comes back and downloads it. Of course, some of those downloads and visits are our own as well; itch tracks literally all traffic to the page, even when it’s me logged into the Burning Sky account. It also includes downloads by the Burning Sky account, which I had to do a couple of times to make sure the files had uploaded properly. The only way to filter out your own activity is to keep track of it yourself and do the math.
itch gives you a little breakdown of what it calls “Referrers”, which is the source of all visits to the page from different places in the last 30 days. It lists each website where someone was linked to the page. The actual URL of the download will also show up to represent any direct links, which for now has really been all of them. When the page is public, there will be more insight to gain from this, but right now, we’re sticking to the analytics given by MailChimp. You can also connect your itch account with Google Analytics in case you want to keep all that info in one place for multiple sites.
You can see below that the first day has more than most of the other days, which is how it usually is with game development. From there, each little bump is from sharing the link here and there, but it never leads to anything big. The largest spike in views and downloads is from one day when I posted to a couple of Discord groups, but otherwise, it’s been a slow trickle. The best you can do with it is to try a bunch of promotion and see how effective each method is. So all in all, the analytics are pretty cool to look at, but I don’t know that there’s much useful information in there, at least right now.
A total of 58 views and 30 downloads of our alpha so far in a week and a half.
In case anyone wasn’t able to get in on the private alpha, we have set up an automatic email for any new sign-ups with a link to the download. The mailing list sign-ups themselves are at the bottom of every page of our website with the heading “Subscribe”. I hope you all find this helpful as you prepare for your own first release.