Wrestle Wrun – Starting a New Project

I have been meaning to get back into writing since my Multi-Threaded Programming series got derailed due to AltDevBlogADay going down (and just being busy with work and life in general). I also took a bit too long of a hiatus with the Super Mario Cuckoo project so I have been avoiding going back to it due to the ramp-up needed to remember how I was doing everything (plus I would love to possibly convert it to use Vulkan, even though it would be overkill). However, I have recently picked up a side project which has been holding my attention quite well and wanted to talk about some of the interesting decisions and challenges that I have been facing there.

One thing that makes this project unique is that I am not the sole person responsible for handling everything. This makes it much harder for me to just put it on the back-burner and move on with life. It is also not a project that I intend to write everything from scratch on. Starting with a blank slate is very good for initial learning purposes, but after you’ve written basic texture handling and drawing code for the “upteenth” time, it can be a little hard to keep up the motivation.

 

So with that little introduction out of the way, let me introduce you to WrestleWrun!

Overview

The main goal of this series is to discuss the technical decisions that are going on with WrestleWrun, a wrestling themed runner for mobile platforms. I will be writing this series alongside development, so there may be additions or alterations to previous content if I have to revisit something further down the road. I also hope to help give readers some insight in to my development process. Hopefully it will help teach people what can go on with the development of a game as well as why I chose to go with the solutions that I did. In addition to that, this might also help spread some awareness of the project, so then it will have a bit more of an audience upon its release!

 

The Starting Story

I’ve always been a big fan of River City Ransom (RCR) on the NES. I never owned the original game, but I would rent it often. I remember that I used graph paper to draw the pixelated characters back in school (probably using Nintendo Power or something as reference, the internet wasn’t much of a thing back then). In college, I worked for a little bit on a copycat game called Purdue University Payoff starring myself and my friends that I never finished. I frequently downloaded RCR to play around with it using emulation just for fun, and purchased it on the Virtual Console on the Wii as soon as it was released there. I certainly have logged many, many hours playing in that digital city.

So when I heard that there was a kickstarter to fund the sequel, I jumped at the chance to help get it off the ground. I checked out the forums every now and then and was always interested in the artist updates that showed the sprites being created (also the engine updates, but those weren’t nearly as frequent). On one particular forum topic, it was asked if anyone in the forums had any involvement in the video game industry, since some of the posts that people were making seemed well-informed about the going-on process of making a game. I offered up that I was a professional programmer for ten years now and had a hand in many big-name games. Shortly after doing so, I was messaged privately by the artist that he was looking for a programmer to help with a side project he had. It was going to be a mobile project and he already had a lot of the art for it so he just needed someone to add all the engineering bits to make it a game.

I haven’t worked on a mobile game yet, and I enjoy games with pixelated graphics with an old school feel. So I agreed to devote a good chunk of my limited free time to helping him out. I thought it would be a valuable learning experience since I have always wanted to mess around with programming for a phone. Plus this way I wouldn’t have to deal with the art and design stuff much since I find that I lose a decent amount of motivation when I have to tackle those areas in excess. Additionally, having another person whom is depending on me is always a plus since it means I just can’t idly put everything off on a whim.

 

Choosing An Engine

With any new project comes the decision on how to choose an engine. Typically, for personal stuff I decide to write my own. However, seeing as I have little experience with mobile and I’d really like to get to the game making part as quickly as possible, I made the decision to go with another engine instead.

I wanted an engine that would work on iOS, Android, and Windows. The first two are obvious since those are the platforms that we want the game to actually be on. Windows is so that I could easily work with it there and add debug modes and other such things that I wouldn’t want on the phone version. I also didn’t have any phones that I really wanted to develop with on just starting out, so being able to run the game on the development computer was a necessary requirement.

It would also be a big plus if it was open source. Part of this is to help with learning and debugging, so that I can see exactly what is going on and how they do things. I don’t generally like big black boxes that claim to do everything you need to do. This mistrust partially comes from my day job, where I am spending most of my time fixing existing engines. There is also the case that I don’t want to feel constrained by what the engine can do. If there are features that I want to add, or areas that I want to modify, then I want the capability to do so. Having the source also assists with debugging as I can see what exactly is happening.

Naturally, it being easy to use and having content tools available for it (or that could work with it) is also a big requirement. I don’t want to have to spend all my time writing the tools as that can get tedious. I’m here to make a game, not another process.

So with all those requirements, I settled on Cocos2D-X. The only part here that was lacking was some of the tool support. This is still being very much actively developed, so there are some parts that aren’t quite at the level I would like. But the biggest tool is the level editor, and I am able to make use of Tiled for this. For animation I am getting the timings and frame information from GIF files, and putting that info in JSON files in a custom format. Since we are just using simple sprite flipbook animation, this is working out well. Same goes for UI. So I am not using any of the provided Cocos2D-X tools currently nor plan to.

 

Next Time

For the next blog post, I am going to focus on the collision system that I am implementing. I haven’t messed around with collision much before and it has been an interesting time figuring it out as I go along. See you next time!