Stretchy Dash Post-Release: A Look Back at Marketing Media

Yesterday, I released Stretchy Dash on the Google Play store. This is my first independently published game ever, so I'd like to share some of my experiences. I'll divide my thoughts into categories for better skimming and readability.

Stretchy Dash's brand logo. I think it's pretty simple and clean.

Deploying to Google Play

This game is only being released on Google Play, at least for the time being. Being the first time I deployed to a store, I figured it was a good idea to keep things simple.

Actually deploying my APK to Google Play was way simpler than I had imagined; it's just a matter of uploading the file and typing in some patch notes. In fact, using their dev console is generally a good experience. It's really something anyone can do. Since it's relatively simple, I won't go into the details of the console. The real challenge that I'd like to discuss comes in all the stuff surrounding the APK and Store Page.

My Google Play Dev Console, so easy to use!

Marketing Media, Oh My!

This part took as long as making the game, maybe longer, but I'm really glad I went all out. Going through the entire process gave me a good idea of which things I should start working on earlier. Also, this is stuff that you can't just leave out if you want to be successful. Even if this game flops hard, I don't regret any of the work I did for marketing. Okay, what do I mean by marketing media? Let's look at some examples.

• Business Website
• This one may be optional, but the way I see it, having a hub for your users to see all of your content in one place is an effective and easy way to market. You don't have to make it from scratch (although I did for the experience), but you should at least look into a Wordpress site or a service like Squarespace.

• Game Landing Page
• Having a landing page, however simple, gave me a link to send people who were curious about the game. My landing page just has the game trailer video, a link to the Google Play Store page, and some social media links. It's like a business card for your game.

• Game Screenshots
• This one is required if you want to release on Android. You need at least a couple, so you might as well make several to show off the various parts of your game and to get people excited. Screenshots are the very first things, past the icon, that your players will use to judge your game.

One of the screenshots I used on my store page.

Added the text on the bottom because everyone else is doing it,

so it must be right!

• Trailer Video
• A video is also required on Android, and is possibly the most time consuming marketing media to produce. There are tons of resources online that give you tips on how to make a good trailer. All I can recommend is to make it short, fast, and to-the-point.

• Game Icon / Logo
• Your game's icon is literally the first thing people see when they search in the store. For mine, I tired to capture the essence of the game, which was going fast and stretching a ball. It's simple and colorful.

Stretchy Dash's Google Play icon. So slick and vector-y.

• Tagline and Description
• The description is the really important part here. Google recommends to describe your game as concisely as possible. I agree; just make sure to get lots of keywords in there that will help players search for it. For example, the first line of my description includes the keywords "unique" and "runner". "Runner" will capture the players who already like this sort of game, while "unique" may capture players looking for something new. Now that I think about it, maybe I should work the word "endless" in there somewhere.

Finishing all of that was exhausting and time-consuming, but it makes my store page and experience around the store page feel more complete and trustworthy. We'll see if it pays off.

I have a few more experiences I'd like to share, but that will have to wait for another post. There's so much social media left to do. Time to up my hashtag game.

Getting Past Those Creative Bumps

If you're an independent game developer, especially if you're a solo dev, chances are you have specific vision for your game. You can envision in your head what the player is doing, how the world looks, and how you want the player to feel. Having this idea is a good first step, but once you start working, reality can get in the way.

What I mean is, during development, you will run into a planned feature that proves too difficult to implement, or that doesn't turn out to be fun. You'll be frustrated, because without this feature your game won't match the perfect vision you have in your head. It will be ruined.

The first thing you should do if you start thinking like this, is stop feeling bad about it. Don't start a cycle of depression that could result in you losing all motivation. This has almost happened to me several times while working on my current project, and I don't want it to happen to you. The best thing you can do at that moment, is let it go.

That's right, forget about it for now. Don't stop working on your game, just focus on another piece of it for a while. The creative process doesn't run on a waterfall method. You can't start with a design document for a piece of art, implement it as specified, and release it in a perfect state. Creativity is fickle and ever-changing. Your ideas will shift and warp during the development process, and you should let them. I'm not saying let your mind run wild with possibility and let scope creep take over. I'm just saying to give yourself a chance to work through the possibility of changing your grand vision.

I read some advice in an article once, and some version of it has stuck with me. It's "let the game tell you what it needs". I've interpreted this to mean - play your game, and always be reevaluating. If something is not working, would take too much time, or you don't possess the skill to accomplish it, you need to quickly decide either to give it up or figure it out. It's a tough decision to make, and both options have their merits depending on the situation. You can postpone the decision, but until you make it your brain won't let it go. The most important thing is to make that decision and move on, instead of giving up on the entire project.

I'm starting to ramble a bit so I'll try to wrap up my thoughts. I've found that it helps to go into a project with an understanding that you don't fully understand your idea yet. Give yourself time to prototype and experiment. Brutally cut features when you need to, and always be open to adding features that the game tells you is necessary.

The Mechanics of Stretchy Dash - Part 4: Lane Boosts

If you're interested in how I developed the basic concept of Stretchy Dash, check out my post about it's prototype.

This is the final post about the mechanics of Stretchy Dash, my upcoming mobile runner game.

A bit into development, I realized that I wasn't fully utilizing the stretching mechanics that is so central to the game, especially horizontal stretching. I wanted to add something that would make your position in the lanes matter more. There should be a decision between grabbing ALL the pickups, and increasing the value of just the ones you care about most.

I decided to make the lanes themselves into a mechanic. What if sometimes, a lane would be highlighted a certain color that matched the color of a pickup. When you were on that lane, and pickup up a matching pickup, that pickup would count double. This worked out great! It provided interesting micro-choices while playing to maximize your efficiency, raising the skill ceiling of the game.

The Player Boosted by a Green Lane Highlight

With the Lane Boost mechanic, I was able to design groups of pickups with varied amounts of complexity. Overall, it's this mechanic that made Stretchy Dash feel most complete, and it's the one that I'm most proud of.

I'm currently in the final stages of developing the game. If you're a game developer too, you know that also means I'm in the longest stretch of the development process. Since this is the first game I'm releasing to the world, I've been learning a lot about marketing and polishing. You can look forward to some posts about that in the future.

Thanks for reading!

The Mechanics of Stretchy Dash - Part 3: Pickups

If you're interested in how I developed the basic concept of Stretchy Dash, check out my post about it's prototype.

In this post I'll continue describing the mechanics of Stretchy Dash, my upcoming mobile runner game.

I'm excited to talk about this post's topic - Pickups - since I'm very proud of the way they've turned out. First off, I should say that in runner games, pickups are commonplace. Often, there will be a generic "score" or "coin" pickup that is everywhere, as well as rare "powerup" pickups that do various flashy things. This is where I started, and then I added a few interesting features into the mix.

In Stretchy Dash, you're goal is to gather as many points as possible. The simplest way to do this is to run over "point orbs". Every point orb you pick up adds to your score. The amount of score you receive per orb scales with the game's current difficulty. Okay, sounds pretty standard. So where's the unique part?

There are a few interesting ways you can increase the amount of score you receive from a point orb. The most important modifier is your overall score multiplier. Picking up multiplier powerups adds to your multiplier bar at the top of the screen. Whenever this bar fills, your score multiplier increases and the bar resets.

A Multiplier Powerup

You'll also find shield powerups during play. Shield works similarly to multiplier in that you collect powerups to fill a bar. Once your shield bar is full, you receive a protective shield around you that protects you from one collision. You can have multiple shields up at once. While the shield bar takes awhile to fill, having a shield is very helpful for getting past those difficult obstacle groups.

A Shield Powerup

These mechanics for multiplier and shield reward you for consistently picking up powerups throughout the game. It's a slow build that feels good. As a designer it allowed me to place more powerups for you to pick up, which I think is more engaging than just finding a temporary boost once in awhile.

Next time, I'll finish up this set of posts by describing how I pushed the concept of pickups even further with Lane Boosts.

Thanks for reading!

The Mechanics of Stretchy Dash - Part 2: Obstacles

If you're interested in how I developed the basic concept of Stretchy Dash, check out my post about it's prototype.

In this post I'll continue describing the mechanics of Stretchy Dash, my upcoming mobile runner game.

Let's continue with a mechanic that comes standard in the runner genre, Obstacles. Obstacles exist to encourage movement and to give you something to avoid. Colliding with one will cause you to lose the round, although there is a way around this that I'll explain later. As the game goes on and difficulty increases, you'll cross paths with more and more complex and scary obstacles.

When you think about a runner game, obstacles are a given. So, I wanted to make sure that my obstacles were unique in look and feel. I decided to continue with the theme of combining basic shapes and simple materials to create more complex objects. My obstacles have a red color to designate danger, and are often spiky to differentiate them from other objects in the scene.

The first obstacle I created was the "barrel" type - the only type present in the prototype. Barrels are unique in that they extend slightly beyond their lane, intruding into adjacent lanes. Even if you're not in the barrel's lane, if you're in an adjacent lane you'll still be wide enough to collide with it. This encourages stretching vertically to make yourself skinny and avoid the barrel.

The barrels are interesting, but are quite static. By the time you reached a barrel on the path, you already had plenty of time to know how to avoid it. I wanted to create moving obstacles that would keep the player guessing as they approached. The "roller" and "spiky ball" obstacles move around, so it's more difficult to guess the position they'll be in when you cross paths with them. To keep things fair, they do move in a predictable pattern, so skilled players may be able to guess they're intersection point sooner.

Besides gathering more than one point orb at one time, there were no obstacles that encouraged stretching horizontally. To encourage this, I created a "low wall" obstacle and changed horizontal stretching to make you shorter as well as wider.

Now that I had some individual obstacles, I was able to combine them together into preset groups that would spawn in game. Some groups are more difficult to avoid than others, and some are more rare than others. As difficulty increases, you'll start to see more and more complex groups of these basic obstacle types.

At the time of writing this post, I'm still trying to come up with a new obstacle that will encourage vertical stretching. Right now, only barrels accomplish this. Otherwise, vertical stretching only helps to dodge the occasional spike ball that came a bit closer than you thought it would. Once I come up with a solution, I'll be sure to let you know.

Next time, I'd like to describe the unique way pickups are used in Stretchy Dash.

Thanks for reading!

The Mechanics of Stretchy Dash - Part 1: Stretching!

If you're interested in how I developed the basic concept of Stretchy Dash, check out my last post about it's prototype.

In this post I'm going to dive right into the mechanics of Stretchy Dash, my upcoming mobile runner game. I'm going to keep these introductory posts concise to give you a quick-and-dirty idea of how the game works.

Stretchy Dash is based on a few core concepts: Stretching, Obstacles, Pickups, and Lane Bonuses.

Let's start with the core mechanic of Stretching. On top of switching lanes left and right, which comes standard in most runners, you can stretch yourself  both "forward" (making you skinny and long) or "backward" (making you wide and flat).

Stretching will allow you to interact with various situations in different ways. Want to fit between two wide obstacles without hitting them? Stretch skinny! Want to grab two pickups at once that happen to be in different lanes? Stretch wide! The rest of the game's systems have been designed with this base concept in mind, making stretching and movement decisions more interesting.

Stretching "wide" to grab two pickups at once.

Stretching "skinny" to squeeze between two obstacles.

It was incredibly important to me to get the feel of stretching right. In the original prototype, you could hold down the stretch controls as long as you wanted, providing you had enough energy. This worked fine on a keyboard using the arrow keys. However, this type of input turned out to be very awkward on a touch screen. Swiping and then holding felt pretty unnatural, and caused your finger to cover important parts of the screen for an extended period of time.

To solve this, I ended up using a swipe input to start the stretch, and then simply end the stretch after a few moments by returning to the default ball shape. This felt great and also made stretch controls consistent with movement controls (in that they both used a simple swipe). As a result, the final product will have a simple four-directional control scheme that gives you a surprising number of options while playing.

In the next few posts I'll be describing how the rest of the game's mechanics support the core stretch mechanic.

Thanks for reading!

How Stretchy Dash Came To Be

Over the past few years, I've become a huge fan of the Ludum Dare game jam. For those of you not familiar, Ludum Dare is a casual competition where thousands of game devs come together over a single weekend to make the best games they can. You base your game off of a theme that is revealed when the jam begins. I've always competed in the solo category, but there's also a three-day team category.

By the end of the weekend, providing you manage scope properly, you have created a small prototype. Over the next few weeks, your work is judged by other competitors, your peers. It's a great learning experience in a lot of ways. What happens to your prototype after the jam is over is up to you.

In Ludum Dare 35, the theme was announced to be "Shapeshifting". My first thought was to keep it small, since I've been burned by feature creep in the past (one weekend is a shockingly short amount of time for creative work). I decided to make a variation on the runner genre. The basic concept of a runner couldn't be more simple - avoid obstacles and gather pickups. The best part is the openness of it. What do the obstacles look like? What do the pickups do? How do you move? The variations are staggering, so I just went with it.

My original prototype from the compo was titled "Stretch Runner". The obstacles and pickups were nothing special; they did their jobs by threatening the player and providing a score. The real innovation originated from the theme itself. What if you could change your shape to avoid obstacles? I decided to simplify the controls to conform to the arrow keys. Left and right changed lanes, up and down changed shape. I wanted the functions of the controls to feel "right", so the up arrow became stretch forward (lengthwise), and the down arrow became stretch backwards (squish down). I designed obstacles that required the player to stretch "skinny" to avoid them. This felt great to play, but the player could just hold down the up arrow and be skinny forever, avoiding all obstacles with no effort. So, I added a limited pool of energy to prevent infinite stretching, which solved that problem.

Next I tackled squished/horizontal stretching. I found that there was no reason to do so, since it only made you more vulnerable to hitting obstacles. So, I decided to create groups of point pickups that would require the player to increase their surface area to gather them all. This worked okay, but it wasn't really necessary to do since you could just wait for more pickups to spawn later on. This problem wasn't really solved in the prototype.

Stretch Runner judged pretty well, even with it's simplicity. I was at a point in my self-taught indie career where I had never finished a single game, but I had gathered a ton of knowledge and skill. I made the decision to finally finish a game. I just had to pick one idea and go with it, and no matter what it would get done. I needed something small and simple that wouldn't take long to go through the entire process of development and publishing. Stretch Runner was perfect!

I went back and forth with myself over what platform to release it on. While I have always seen myself as a PC developer, Stretch Runner seemed like a perfect candidate for a mobile game. The arrow key controls could easily be translated into swipe controls, and publishing to Android was far easier than any other platform. Since the prototype was already made in Unity, it was relatively simple to build for mobile. So that was it, I would polish up Stretch Runner and release it on Google Play.

To any developer that decides to go ahead and turn their prototype into a full release, I give you this advice - don't start with your prototypes code base. Just start over. It only took a couple days to make the prototype anyway. The code you came up over a rushed weekend is not a good starting point. It's guaranteed to be messy and difficult to scale. Just start over!

There were many changes I made to Stretch Runner to turn it into Stretchy Dash, but I'll get into that in another post. Overall, the most important decision I had to make with this entire process was to dedicate myself to one project. I knew it wasn't going to be perfect, but I just had to step back, do the best I could, and not give up. That is really all that is required to finish something. Be consistent and don't give up. Know that if you keep working on it, piece by piece, it will get done eventually.

I can't wait to tell you more about how Stretchy Dash works and how I'm getting it out into the world, but that will have to wait until next time. For now, just keep making games.

An Introduction to Departure

This blog will be my place to share ideas and news with the Departure community. It will likely contain topics from a variety of disciplines, so I'll try to label posts as best I can to make it easier for you to find the content you're interested in. This first post will be a general look at what I'm trying to accomplish with Departure Games. Future posts will likely be more focused on a single project and topic.

My name is Richard Stack. I'm a software engineer and independent game developer. I started the Departure Games project a couple years back as a way to learn more about game development and to share my work with other gamers and developers. The most effective tool for self-teaching is actually doing, so I've used the Ludum Dare weekend game jam as a motivation to create prototypes and learn a variety of tools. If you're interested, you can see and play those prototypes on the Departure website.

More recently, I've been working on releasing my first full game to mobile. Along with this, I've been revamping the website and creating promotional materials for the first time. I'll likely write future posts about my approach to marketing this game, especially as the project begins to wrap up.

Departure is an avenue for expressing what I love about games. One could call me a perfectionist, but I'm also a one man army, so my expectations follow suit. I enjoy pushing my limits and being surprised by what I create. I'll continue to learn and push the envelope as far as possible, and I hope you'll join me on that adventure.