Mutt & Run: A Crash Course Into Getting Things Done

I wanted to get better at personal deadlines. At your job, where the incentive to get things done is "do it or you're fired," it’s easy to meet deadlines. You miss one at home with your side project, and you think “ah that’s fine. I’ll just push it to next week. It’s not like anyone is depending on this arbitrary timeline I made up for myself.” And the cycle goes on until you realize you’ve pushed the project back one or two months. Next thing you know, you have another unfinished title sitting in a graveyard of folders on your desktop. 

That was my mindset for a while—almost 10 years—and thankfully I finally got tired of it. So I started this challenge to get one game out every month for a year. This way the deadlines were clear and meaningful. This way I couldn’t let feature creep get the best of me since my time was so limited. This way I actually make a game. I figured I would pick an easy game to kick this project off, and yet somehow I ended up picking one that will probably be the hardest game I make out of this entire series.

What Went Right

1. The Theme

The theme came to me at an instant. Mutt & Run is a 2D top-down endless runner that I came up with while walking across a Natural Grocers parking lot to a Cheba Hut to get a quick sandwich fix with my girlfriend and a friend. You tend to see a lot of dog walkers around the neighborhood I live in and the thought came to mind of how a dog just goes around sniffing everything in its path, and you as a dog walker have to sometimes heel the dog from getting into things they shouldn’t be getting into. I thought it’d be interesting to use that concept in a mechanic, where the dog freely moved side to side on its own volition, and all you could do is slow down or pull back on the dog’s forward movement.

This made for a challenging experience in terms of user input. I found lots of people playtesting the game inherently trying to influence the dog’s horizontal direction, dragging their finger off to the side of the screen in hopes that the dog would obey, ultimately ending with the dog smacking itself against a tree and losing the game. And that’s what I wanted. You get the same feeling of, “dog, please, come this way” but the dog has its own agenda.

2. The Engine

I decided to use Defold as the game engine I would build Mutt & Run on. Defold is owned and developed by King, of Candy Crush fame. Defold caters to independent developers as it is free and focuses on 2D mobile platforms—though it is capable of 3D rendering and physics and can be bundled as PC and Mac games as well. I had worked on the engine once before during a game jam about a year prior. Though it had been a while since picking it up, it was almost like riding a bike. And because of their in depth and welcoming community forums, finding answers to questions I had with the engine are as easy as having a developer of Defold right next to me answering questions I would come up with on the fly.

I’m not an animator nor an audio engineer whatsoever, but Defold makes including animation spritesheets and integrating sound to your game so easy that I was able to get both final animation and audio/music done for the game in the last 2 days of my deadline. Also, the engine uses Lua as its scripting language, which I was not familiar with going in, but picked up quickly. And if you’re coming from the Corona engine, then you should have little problem getting comfy with Defold. I would recommend this engine to anyone just starting out making games if they’re looking to make a 2D centric title.

3. The Audio

Since the conception of the title, I knew I was going to do it all on my own. I figured if I wanted to work on deadlines, I should just go all in, make every aspect of the game myself and really get myself in the mindset that if I slack/procrastinate on one aspect, then I’m not going to have time for a different aspect of the game. That being said, I knew I was going have a hard time with audio as it is the side of video games I’ve spent the least amount of time on.

I decided to buy a small 32-key Midi keyboard to help facilitate the audio development. I spent a couple days messing with it from time to time using a web based DAW I found online called BandLab. Nothing really felt right with the theme and I was getting frustrated with how terrible I am with music. One day I was like, you know, I don’t even know what a scale is for crying out loud. So I googled it, and wow, I had no idea how easy it was to understand scales. Mastering playing the scales fluidly is a different story, but understanding them helped a ton. I came up with a little jingle I was happy with and you can hear it in the background of the game now. I also used the same equipment to make the sound fx of the treat collection and ball bounces.

listen to the song here

Now this isn’t top notch quality stuff, but honestly none of it is. This was never a “make a polished pristine title you can sell right out the gate and roll in all the dough” project. This was purely a “get something done you can be proud of within the time you’ve allotted for yourself” labor of love. And I can easily say I’m proud of how the audio, along with the rest of the game, turned out.

What Went Not So Right

1. The Genre

I don’t want to categorize this portion as “What Went Wrong” because I honestly don’t think anything went wrong. Just maybe, not as expected. The biggest surprise was how difficult it is to make an endless runner.

Sitting at a table in Cheba Hut I was spit-balling with the company I was with on the idea I just conceived in the parking lot minutes earlier. Everything sounded like it was just falling into place. I had already come up with a scoring system, the main—and only—mechanic, and the genre. I said something along the lines of, “Oh yeah, I can just have a hazard appear from the top of the screen that would drop at a random x position and time interval and you would just pull back on the dog and time it right with its side-to-side movements to avoid the obstacle, and just have it gradually get faster and cap its speed at a certain point.”

In theory this works and is easy to accomplish. In practice this is indeed quite easy to accomplish, however, it’s terribly boring and not practical. Since the position and time of the obstacle are randomly generated, there’s no way to know that, at one random occasion, the user will hit a certain layout of hazards that is legitimately impossible to pass. And if/when this occurs, the game is broken. That instance might never actually show up on anyone’s gaming experience, and even if it does, they might not have noticed that it was in fact impossible to get past and not give it a second thought. But knowing that there is a chance that it could happen was enough for me to totally rethink how I lay the game out.

I did a few searches on reddit to see how others made their endless runners and found a couple sources who stated that the levels of most endless runners are not randomly generated, rather they have pre-built chunks of levels that are randomly instantiated. These chunks can be tested repeatedly and are vetted on not only their ability to run through, but also on their fun level. Having a randomly generated endless runner map makes it near, if not completely, impossible to make truly fun. If you lose on a purely random map, there’s no way to get back to that exact scenario with a better understanding of the game to conquer it. With pre-built obstacles, a user will lose on certain chunks, but can recognize their mistakes for the next play-through and attempt to do better. This creates a replay incentive that all successful endless runners promote.

All this research ultimately helped shape my game to a game I have fun playing on my own time, but made my job 10x harder. Having to make about 6 level chunks in 3 different difficulties and then testing each one to make sure every chunk I created was actually possibly to get past, and having these map chunks instantiate in the game at certain times without overlapping other obstacles added tons more work to my plate than I had expected to have when I first came up with the idea.

2. The art/animation

My first iteration of the dog was fine. It was my first foray into Adobe After Effects so I did my best with what I could learn in such a short amount of time. The dog ended up looking like a golden retriever and had a cute animation of him bouncing up and down. It worked with the rest of the art I made for the game, until I realized how subtle the animations looked when actually implemented in-game. The dog practically looked static just kind of stiffly ricocheting back and forth off the sides of the phone.

It also didn’t help that I had to make the dog a lot smaller than I had planned once I switched from a fully randomized level generation to a pseudo random level generation. At this point he didn’t even look like a dog, as much as he looked like the head of a penis zig zagging all over the screen of my phone. This phallic similarity was also not lost on others who were following along in my development, letting me know in comments on my Instagram video posts. “Yeah yeah, I know, I see it too. Planning on re-working the art/animation for the dog soon.” The final art for the dog looks great, and much less inappropriate than its predecessor. It just added an additional day I wasn’t planning on working in a piece of software I don’t know much about.

3. Defold and Google Play Services

I was hoping to get this game out with ads to supplement further development for this project. I didn’t look into it much through most of the development and when time came to do a little R&D on that front, I quickly realized how difficult it is to implement as of right now. Defold is still a bit in its early stages and native extensions aren’t of abundance quite yet.

I did find a good resource for advice in a blog post by A Game a Month discussing their experience with implementing ads to their Defold project. I’m going to use this when I end up adding ads to Mutt & Run, but it wasn’t going to fit within the scope of the game for month cycle, so I had to scrap the idea for now. Instead, as was always the plan in the first place, I’m just relying on the donations from generous downloaders on itch (which is helping out a lot so thank you all, you’re great and I’ll keep each of you in mind when I start making some giveaway stuff!)

Final Thoughts

The games industry suffers from what we all know as “crunch time.” It’s a serious problem within the industry that can be solved with better task management. I worked in a tech company for a few years and something I saw within that company that I’ve not quite seen, or at least seen done well in the past game companies I’ve worked for, was task management. Daily stand-ups sound excessive, but when done correctly, they work. When everyone on the team is transparent with their tasks and timelines, the company as a whole is better for it.

My advice is to research SCRUM and AGILE, which are frameworks to help facilitate time management and task breakdown. Creating unrealistic deadlines for yourself will greatly impact your motivation to continue working on a project, regardless of how much you love the project.

This framework helped me with breaking down tasks to their simplest forms, seeing the development at both a macro and micro level, and staving off feature creep to deploy with a playable and enjoyable game. We could sit and continue to iterate on a game and never release it due to things we think of or want to tweak during development. Recognizing what is needed and what is just icing is important to your development process, and SCRUM/AGILE can help with that. I want to see a future of the games industry where our fellow game developers’ time and livelihoods aren’t taken advantage of by game companies with copious amounts unpaid overtime and 80+ hour weeks. Crunch time just means bad planning, it’s simple as that. 

Mutt & Run was a labor of love, and people usually attribute labors of love with grueling hours and all-nighters just to see it through, but honestly, I only had a month to make this game, and I really didn't push myself too hard to do so. I truly believe task management is an aspect of game design that people often neglect to put time towards, whether it's due to the zeal of a new project that they want to just jump right into, or they don't see the importance and effectiveness that it brings to projects. Let this game, and hopefully my future games, be a testament to how significant it really is.  

Mutt & Run is available for download now which you can find below!