Here is the blog post link if you want to see pretty pictures, nice formatting, and a bunch of links:
http://chadpalsulich.blogspot.de/2015/07/what-i-learned-making-mobile-game-staq.html Here are the app links:
iOS -
http://itunes.apple.com/us/app/staq/id980241257?ls=1&mt;=8 Android -
http://play.google.com/store/apps/details?id=com.cereal.stackking.android Background and Game Description In the past nine months or so, I’ve worked on a mobile game for iOS and Android called Staq. In Staq, a player must stack all kinds of shapes in a coordinated structure to reach a winning height. I quit my job working as a web developer last September. I sold all my belongings (sans clothes and computers) and moved to Germany at the end of the month. My girlfriend got the job of her dreams and I decided to go with her. When I flew to Germany, I checked my desktop computer. I bought a massive bag from a military surplus store and stuffed the machine in the center surrounded by a buffer of clothes. Here is a picture of my set up (Macbook Pro 13', PC, 15' HP with Arch Linux).
Having the game idea was essentially the reason I finalized my decision to move. I would have a set project that would last roughly the length of my time there (one year). The last thing I wanted was to spend a year where my professional skills stagnated.
This game was my first significant independent undertaking and I was a bit unprepared. I didn’t fully realize that there is truly no other person to rely on. There were so many different roles that I had no understanding of. For example, I had no experience creating game art and had never really used a graphics editing program. And yet I had to become proficient in game asset production. There was also business and promotion and music to worry about. In short, I quickly learned I couldn’t just put my head down and write code.
5 Things I Learned as a New Game Developer - Schedule and Plan the Work I meandered through the first four or five months of development. There was no structure and no plan. I had no idea what was next or what was recently completed. There was no accountability and my work suffered. There was progress, but it was hampered by the fact that I had no direction. Working in an environment like that is simply not conducive to efficient output. It was also a lot less satisfying knowing I wasn’t producing what was possible. In the final half of development, I took control. I made a list of every single feature that I wanted in the game. I noted the gaps between the list just created and what was already completed. After that, I estimated the time required to complete each of the features in the list, and broke tasks down when required. I found a site called www.asana.com and entered in every task just created. Once that was done, I assigned a due date for each task assuming I could work about 30 hours a week (I haven’t worked full time on this because I’m also in school 20 hours a week learning German). Having all work required fully documented and visible was a huge relief and weight off my shoulders. No longer did I need to think about what should be done. Finding the next task was simply a matter of looking at the schedule. Because of this, game progress dramatically quickened. Having a schedule and a plan kept everything targeted on the finish, and allowed me to focus solely on the fun part: making a game.
- Fully Define the Feature Set Then Pare Down This is a continuation of the first point. When I first started working, there was going to be the ability to share scores on Facebook or Google+, plus several achievements, plus a multiplayer mode where users could challenge random others or friends; None of those are in the current game. I unfortunately had to cut them out to focus on core gameplay and presentation. In my game, the core components were to have 50 exciting, challenging, and unique levels, a progressively more difficult continuous mode, acceptable assets, and minimal bugs. All of the other features will eventually make it in, however, they took a back seat to fun, usability, and attractiveness. Obviously having everything would be wonderful, but I chose a slim, fun game over a bloated, rushed one. Here is a screenshot of tasks still to be completed in Asana (a lot).
- Just do it There were a few instances where I had no idea how to proceed with the current task. I’d spend time Googling and reading Stack Overflow questions to determine the perfect route. In the end, what’s perfect is less significant than what works and what is actually done. I found that just starting, literally writing code, even if I wasn’t sure, was more productive than just reading. I’m not condoning a total disregards for research and homework, but the final goal is to put out a product in a reasonable time frame. If the solution works and all criteria are met, then it IS perfect. As a side note, I don’t actually own anything made by Nike.
- Use What’s Available While it’s nice to say everything displayed was written by you, using what’s already freely available will free up time for items that would have been otherwise neglected. One other benefit of using something already completed, is debugging is already done. To write the game, I used a cross-platform framework called libGDX. Using this framework allowed the vast majority of code to be written only once. When platform specific code was required, e.g Facebook login, bindings were already written for iOS. I simply needed to integrate them into my project and I was off and running. To simulate 2D physics, Box2D worked quite well.
- Inspiration Can Come From Anywhere Level design and creation was a continuous struggle for me. I would draw out one or two then sit staring at the page. I would get caught up in what was already done and couldn’t break free from those thoughts. After about 20 levels, I was stuck. I wasn’t even halfway through and didn’t know how to continue. For a while, I tried to find something that already existed in the real world that had similar flows or pathways. I was on a train to Zurich and inspiration slapped me in the face. I discovered that I could model many of Staq’s levels after letters in the alphabet. Objects I saw everyday were exactly what could be used to continue making levels. It was a perfect fit. Some letters were more complex than others and all were easy to visualize and represent in the game. In the end, 20 or so levels were based on alphabet letters. Once I came up with that idea, level creation almost felt like cheating. It was dramatically easier than before. After the alphabet epiphany, I was able to draw from more everyday objects for creativity, but nothing was as dramatic. That epiphany truly solidified the idea that inspiration can come from anywhere. Here are some levels where the letters are quite obvious.
Game Reflection What Went Well I am insanely happy I chose to use an entity component system in my game. Each piece of functionality is so wonderfully isolated. If you didn’t read the article linked above, here is a brief rundown. In ECS’s, there are entities, components, and systems (Crazy, right?). An entity is merely a “placeholder” for components with an ID. A component stores a specific piece of data or an object. A system acts on entities that have the specific set of components they’re looking for. So what all this adds up to is a way of writing software that dramatically reduces dependencies and expansion overhead. Adding or removing features is a breeze. When working on my game, having an ECS was wonderful because there was never any repeat code or work. It was simply a matter of creating the necessary components and systems and adding components to the relevant entities. After that, things just work. The most difficult part when working with an ECS was changing my thought process. I was forced to think of how things would work in a novel way when adding new functionality. There is an excellent write-up by Richard Lord describing ECS for more detail.
One other thing I’m very satisfied with is how game data is saved. To build levels in game, a 30000 line JSON file is read. It has all information about the types of shapes/obstacles, their position, and other general level information. Originally when syncing data, I was sending and receiving the entire file each time. After seeing how slow the process was, I realized that only a couple of lines for each level ever changed and only those lines were really relevant for saving. After separating the static content from the dynamic, the file saved was less than 300 lines and syncing was almost instantaneous. So, when saving any data, it is extremely beneficial to analyze what is absolutely necessary. Anything extra is a total waste.
What Went Okay Setting up a remote server that synced game data was hard. There were many facets of the process that I definitely wasn’t prepared for and didn’t foresee. Setting up HTTPS, for example was a big pain. If I wasn’t a complete noob, things probably would have moved much faster. Let me start by saying my server is running Arch Linux on a Linode virtual private server (VPS). What is wonderful about that is absolutely everything with the system is under my control - permissions, directory structure, processes running, all of it. It’s incredibly liberating, but is also a lot to manage at times. To get HTTPS, I started by going through the process to get a free SSL certificate at
http://www.startssl.com. To verify that the person registering is the actual site owner or administrator, StartSSL sends an email to
[email protected]. It was then I discovered I’d have to set up an email server. Setting up an email server basically requires installing a bunch of stuff and configuring it all to work together. Though that sounds simple, I needed extreme attention to detail, and for whatever reason this took FOREVER. Unforeseen projects like this exposed themselves throughout the entire process. Some took longer than others, but all of them delayed my game's release.
What Went Badly I should have created a level editor. All the game level data is stored in a big JSON file. When I added a level, it required me to edit the file by hand. Here’s how the process would go: I made a simple drawing of the level layout on whatever piece of paper I could find. I’d then guess the general position/size of the obstacles and edit the JSON file. When everything was roughly in, I’d launch the game, select the relevant level, and see how I did. It wasn’t efficient. To make a level it would require several passes of writing JSON then checking in game. If I made a way to edit levels visually, level creation would have been much simpler and more enjoyable. I think I fell into the trap of, “oh my levels are pretty simple, it shouldn’t be too much trouble to just create them by hand.” Obviously when creating any game one has to weigh the pros and cons of each method, but as complexity and sheer volume of work increases the scales tip in the favor of automation. Maybe I’ll attribute this to a first time slip up. As you can see, level design was not a fancy process.
How I Learned to Make Game Art I followed about three or four tutorials on YouTube for GIMP (link and link) then just followed my own path. I did all the art (haha… art) for the game. Initially I used placeholder art by Kenney. Everything he has available is wonderful and the assets I had in the beginning stages of the game gave it some semblance of professionalism. After those tutorials, I simply created what I needed with the capability I had. It wasn’t pretty, but it served. As time passed and the mood struck, those assets created in the past were steadily replaced by improved versions. It also doesn’t hurt that the game only requires the creation of polygons. Here's an early screenshot of a level with the Kenney assets.
Evaluation of Tools LibGDX - When I was researching what framework to use, it was between Cocos-2dx and libGDX. Both were cross-platform and both had successful games. LibGDX however had vastly better documentation and was written in Java which I was much more comfortable with. I haven’t really used Unreal or Unity so I unfortunately can’t compare, but I would definitely recommend libGDX to anyone. The API is extremely approachable and easy to use, yet also powerful. The documentation and support are also top notch. My one gripe with the framework is the discrepancy of binary size between android and iOS. The Android APK is just under 30MB whereas the iOS binary is just over 80MB. This isn't actually an issue with libGDX per se (it has to do with the additional libraries required to support iOS in RoboVM), but it's certainly something to take in to account. If you decide to use libGDX, I would highly recommend also using Ashley, an entity component system library.
Asana - When I first tried to organize, I created a board on Trello. I found Trello boards to be too informal and slightly unorganized. There wasn’t a way to coordinate the information in a way that I could easily understand and access. With Asana, you create tasks that you can then assign to a specific project and give due dates for. Tasks can have subtasks if necessary. After all my tasks were entered, I could immediately see what was upcoming. Completing a task is as simple as checking a box. One other thing I really liked is that Asana will send an email when tasks are getting close to their due date or when they’ve passed their due date (sadly I’m not perfect). In short, I would definitely recommend using this tool and I plan on using the site for any large project I do in the future.
If you liked this post, you can follow me on Twitter. I plan on doing at least one more post on libGDX related topics. Thanks for reading.
