This article is about my journey in indie game development and how by changing the way I think about game development I successfully producing a simple working game.
I spent MANY years trying to make games in my spare time. I would get really into development then I would get discouraged at the sheer scale of things to learn and I would give up since it was so hard. There are so many skills to learn about as an indie game developer it is easy to get daunted.
Finding a Game Engine
The biggest hurdle was the availability of a quality and easy to use game engine. Unity changed that for me. Unity is a high quality 3D game engine that most can get started using for free. http://unity3d.com . I plan to use the free engine until I need the paid version and actually start making money from this hobby. It seems the resources for the engine are everywhere. The communities are a great source of answer. Google almost always finds what I need. Tutorials are all over you tube. It’s easy to get distracted. I need that rich community to learn unity and troubleshoot problems.
After finding a game engine with so many resources available I tried again. I would start and fail. Then I would watch some tutorials. Start again get stuck and frustrated and fail again. My ambition and goals were lofty as I continued to seek fame and fortune. I didn’t even know how all the pieces and parts worked together much less how to create a quality game. I was gradually coming to the opinion that needed to simplify, simplify, simplify as Henry David Thoreau puts it. I needed to start smaller. Yes as I did testing even simple tasks were difficult.
Finally, I realized I needed the absolute smallest possible game goal I could muster just to get something accomplished. Even the most simple 1 screen game has many things to make a game dev learn. Think about it for a minute. How do you create a splash screen with a background and a logo? How to do transition from that splash screen to a level. How do you accept button click events and make something happen? How do you draw the graphics for a button and splash screen? What size do they need to be? How do you optimize them? How do you work with an atlas? How do I add sounds? We haven’t even gotten to a real game level yet where you have to make the world pieces and parts all interact into a cohesive system!
These are not trivial tasks for me. I am not one of those programmers who everything just comes to intuitively. I am a hard worker who is willing to try things again and again, change tactics, or even set it for a future and hopefully more experienced time. I have to figure out which pieces they can handle myself and find other ways of managing the ones I can’t.
Learning to wear many hats
That is the quest of this indie game developer. To learn enough about how to wear many hats to make a game that fits the goal. In this case by simplifying the goal I also limit the amount of skills to learn all at once. By tackling those areas in very small manageable chunks I should gain in ability to find a happy middle-way between the dream and the reality of being able to finish an actual game. This might mean letting go of some hard to do items to be able to deliver on a product.
Confirmation of the Path of Simplicity
Just after I realized I needed to simplify, I came across this post: http://forum.unity3d.com/threads/the-answer-to-every-can-it-be-done-and-ive-lost-my-way-post.184797/ .This really solidified it for me and gave me an idea for a framework to work from a time based limit. Then shortly after I came across 1GAM http://www.onegameamonth.com/ also a time based limit. Which I think is an excellent way of getting started. I liked the suggestions that it’s a personal goal only. I liked the discussion of a theme being not a restriction but a way to focus. So after a few more months I finally started this past month, July 2014, on 1GAM. I only committed to 1 month to reduce the fears that go along with thinking about “all year long”. By “committing” I mean I told myself was I was going to work on it in my spare time and see how much I could do but I would give it an honest attempt.
I loosely followed the tips on the 1GAM, as I’ll call it: 1GAM Survival Guide Tips . I started off with the idea of using the physics engine from one of the unity tutorials. The concept was simple, an object to fall from gravity, bounce off barriers, and collisions for “pick ups” to create a score. I initially guessed the pick-ups would be ballons, and you would pop them hence the name. I decided just to use a drop of a ball to avoid having to create a slingshot or something you see in other games. So the ball would drop bounce off a bumper and pick ok (pop) the balloon and adding to the score. Physics is a relatively easy way to create interactions and it’s fairly well documented with tutorials. The trick is learning how to set it up in the first place. By understanding rigid-body 2d and collliders in various physics 2D tutorials reminded me of the essentials. My first attempts were using unity built in primitive types for player and objects: a sprite of a circle, a quad, a cube, a sphere. Then I would switch them out later if I got the basics working. Another tip I tried to follow was the idea behind save points. Working in stages to give myself a rollback point in case I don’t complete the next stage I still have a working copy with less features.
I was surprised by how many simple things led to aha moments. Even working with primitives and how to render a simple 2D sprite on it was not as straight forward as I thought. It seems so easy in the tutorials. When working on my own I find that I don’t know where to get started or how the details work. For example, different primitives have different default components. So in my brain, “Unity is so simple”. In reality, I am trying to figure out why I couldn’t just create a cube and drag a sprite onto it. Oh its a mesh with a mesh renderer and have to read how to attach a material or switch to a quad or sprite type. Another aha moment, or perhaps better called an “oh duhh” moment, was when I realized I could attach a sprite (visual representation) as a child object of an empty game object rather than directly attach everything to the same object. I thought it might be easier to change the visual (sprite, mesh, whatever) for that object later with a few tweaks of the collider and such. Though, this led to other “opportunities for learning” as I will explain in a bit.
I ran into many obstacles that should have just been simple tasks. Something as simple as changing the text in a label, figuring out why you aren’t receiving events, or even a sleep timer often took up entire nights of debugging or reading. In most programming languages you say something like sleep(5) to sleep for 5 seconds. In unity you have to understand how time is variable and dependent upon frame rate. So there is no sleep function. You have to either calculate elapsed time yourself or use something called a co-routine which still confuses me after a few tries but I got it working.
This is exactly why I want to keep it simple. What I don’t know will waste a significant portion of my time. So if I keep what I don’t know to a minimum and build my game on what I do know I minimize risk. As long as I continue to learn something new along the way I am still growing.
Sprites gone wild
There was one point were I got stuck trying to figure out why everything was “acting crazy”. Something unexpected was happening in mid-air with no other objects around and the player would go flying off and spinning strangely. I couldn’t quite fathom what had happened. I thought some kind of Voodoo magic was going on until I figured it out. From reading the docs and watching tutorials, I remembered that collisions drive interactions so it had to be a collision detection in mid-air. This meant the that the colliders must be in that empty space in mid-air where the object was changing its path. From that it was not too long to realize the sprite was what was in the wrong place. But since my brain likes visual clues, the intuitive thought is that the sprite is fine and the other stuff is acting funny. So I reset the sprite child transform to 0,0,0 to be centered on the parent and all worked well again. You can see in the example below the box collider in green is separated from the candy sprite.
Learning from my mistakes
So why had this happened? I had wanted to move a game object but when I clicked in the Scene View I was unknowingly selecting the sprite (child) and not the main (parent) object. So, when I moved what I thought was the main object, I was actually moving the sprite (child) away from it’s collider location on the parent. The events were firing when the player hit the collider in empty space and no events were firing when the player hit the sprite. That is why I read the docs and watch the tutorials. Understanding the how and why things work helped me to troubleshoot this.
Things to consider in future development
One quandary I have for example is how to use the same script for an object, say the score, in all levels yet have the state be different. Say I want to have a total score across all levels, a high score of all time, or allow someone to retry a level for a higher score. I am guessing that’s where the game controller can be utilized to initialize each level and carry state across levels and to store the high score for each level. Though I will probably have to implement something like PlayerPrefs to store and retrieve this info. Before this exercise and getting all the pieces and parts together I never had to even consider these things. By completing more then 1 level since my scope was small my eyes were opened up considerably to the overall process of completion which I had never attempted before. So, I will need to find more details about how to GROK in unity as I grow.
Silencing the inner critic
I started about a week late in the month and I only got to work on it a few nights a week. I tried not to worry about the “proper” way on this one. I just tried to accomplish “any” way. That meant I had to change things as I found things that didn’t work. I now see why it would make sense to design out my screens ahead of time. I would have seen my original idea of transitions did not work. Though, I am not sure I even knew how the transitions could possibly work before this so I probably learned more by having to fix it. I also learned that I need to find a better way to centralize the overall logic into some kind of “Game Controller” or manager to maintain state or fire events across various levels. Once I added a second level I realized how nothing from the first level was there anymore. Part of this process was learning to not pay attention to my inner critic telling me how bad it is or that something has to be a particular way. Just plodding forward and taking the next step on the journey towards to the goal no matter how I had to change things. I am not allowed to criticize myself, I am only allowed to find solutions.
Delivering a game
As of today 7/31/2014 I have delivered a game that I feel is a great accomplishment for myself. All told I probably worked about 30 hours or more on this. The game itself is very rough around the edges and the basic flow doesn’t work well. Heck it’s not even all that much fun. Though, underneath all those criticisms where I tell myself how bad it is, I was actually able to get all the essential basic pieces and parts of a game completed for the first time ever! I completed the goal. I know a lot more today then I did when I started which I can carry over to the future. All by giving myself a real deadline, keeping it simple, and working in stages to give myself “save points”.
It may not seem like much of a game but I accomplished a personal goal and got a simple game developed. It feels a whole lot better then all those failures. Its inspiring rather then deflating. So I’ll try to let myself enjoy this for a moment and try again in the future.
If you want to see the actual game, see this post: Play My First Indie Game – PopEm