Chapter Four: for (unsigned int i(4); i < 5; ++ i)
--------------
The title of this chapter was chosen on the basis of my incredibly simple sense of humour, when it comes to puns. Any other programmer should be able to understand what it's all about, and probably disapprove greatly of my so called humour, and for the rest of you, it is simply quite a clear indication that this chapter will be about the most important part of making a game; the programming. Sure, it doesn't make the game any better, because everything else is just as important when it comes to the quality of the result, but without the programming, none of that will matter, as there would be no game at all. The programming is what assembles everything else, and makes it all come together in the end, and obviously during the process of development as well.
Background
My personal history of programming goes back quite a long way now, even though I'm not very old. I'm close to nineteen years old now, and my interest first began with the creation of websites when I was about eleven. About a year later, I was creating small games using a piece of software called Game Maker. Around that time, the program was at version 6.0, and could be obtained from a website with an obscure address, which I had actually memorised at the time. It then went on to get a domain name reflecting its name, and eventually was moved to http://www.yoyogames.com/, where it is still to be found today, at version 8.1. At that time, Game Maker and RPG Maker were pretty much the only programs of this kind heard of by the greater audience, but today, lots of other projects, such as Construct and Unity 3D.
Game Maker had two interfaces to programming. One was by simply dragging and dropping different types of 'actions' to execute into 'events' that would be invoked at certain times during the game. I quickly came to appreciate the increase in both control and speed that I was able to gain through the other method of programming, which was actually using the built-in scripting language called GML, which was simply short for 'Game Maker Language'. I kept using this for two or perhaps even three years, and got increasingly good at it. At the same time, I was also quite good at another field of programming; using a language called PHP, which is used in a lot of large sites today, I also mastered the art of creating websites at a professional level at an early age. Since then, I have spent less and less time on it, and I probably wouldn't be able to keep up with the latest innovations of today unless I read up a bit on it and learn some new things, but, boy; at the time, I was nothing but awesome.
Because of the latter series of events, there was a time when I strayed further and further from the ambitions of becoming a video game developer, and was more into the idea of entering the field of website development in the future to come, and a few years later, I even fell back into the much older ambitions of directing movies, or editing them, or both. There would come a time where my wills were split up between this dream, and, once again, the dream of developing games, which eventually merged into the latter one, and here I am today.
I didn't settle on this recently, though. This was several years ago, and I have already been traveling the road of overambition that is so typically seen, and quite stereotypical, among young teens first getting onto the road of indie game development. I will, embarrassingly, admit that I, at the age of around fourteen of fifteen, initiated a serious attempt to create an amazing 3D RPG. We can all guess what happened to that poor, immature will, lacking all sense of self-awareness. Since then, I have learned to let things take their time, and have myself taken the time to become aware of my own capabilities, and, more importantly, limitations. It will have to take a long time of experience and learning before I feel that the ambitions of my younger self can finally be realised.
Eventually, I came to start learning the programming language C++, about two years and a half ago, or so, which is a powerful language commonly used in the industry of software; not only for games, as it was created for any purpose, and not tailored for, say, games, unlike something like the GML language of Game Maker. The language is used by many large companies today, and is the core of many programs you probably use on a daily basis, both for work and in your spare time.
Starting work on 'Bottoms Up!'
In the last chapter written by me, I told you about the birth of the game. The first thing to be made, was the bottle, contained in a "room" no bigger than the window within which it was being rendered, as was made clear by one of the screenshots that you could see in that chapter:
I also said that the graphics for the bottle was the first thing created at all, but that was not all I did that day; I actually started writing the first lines of code, too. The first thing I did, was to begin work on some preemptive code to make it easier to set up physical bodies, such as that of the bottle, so that I could start trying out the physics of Box2D (the physics framework that was mentioned in chapter two) as soon as possible.
For this, I created a 'class'. For those of you not aware of the concepts of object-oriented programming, or programming at all, I will try to give you a brief explanation. Essentially, programming is just a way of speaking to the computer, by telling it just what to do, be it single actions such as opening the CD tray or turning itself off, or series of actions, as with pretty much any type of software. When you get into more advanced types of applications, with a lot more to keep track of, things can eventually get untidy and hard to grasp if they were not considered thoroughly enough, and as this is obviously something that programmers and their colleagues and employers would like to avoid, there have been many takes on creating the best way of programming. Object-oriented programming (will be shortened to 'OOP' in the rest of the chapter) is one of these.
The idea is to bring the layout of one's applications as close to reality as possible; just like the real world can be divided into entities, some of which share common traits, or are more or less identical, the desire with OOP is to be able to do the same for applications, which are to be considered as little worlds in their own right. A 'class' would be a template for such an entity of the world. A class defines what an object looks like, and how it works, but doesn't give birth to an actual instance of it, as the class is then supposed to be used in order to create many objects of the same type, as defined in the class. If I'm creating a game that's supposed to contain crates, such as 'Bottoms Up!', I might create a class called 'Crate', and tell it to draw itself using the proper graphics for a crate. I also want my create to react to collisions with other physical bodies, and this is a behaviour already defined in a previously created class, perhaps called 'Body'. As I would like to copy this behaviour into my crate class without copying the actual code for it, I can use something called inheritance, which is just what it sounds like; by defining the physical body class as the 'parent' of the crate class, it can inherit the properties of that parent class, just like I have inherited traits from the DNA of my parents.
So this is what was done for this game. I created a class called 'Body', which inherited the class 'b2Body', provided to me by the Box2D library. I took the functionality of the parent, and baked it into the more comprehensive and simple interface of the child class. I then proceeded to some basic work, such as setting up a window to draw everything into, and then I finally created a class called 'Character', which was to be the template for the bottle and its eventual rider, Charles, which was a child of the Body class. I defined the correct shape of this physical body in order for Box2D to calculate proper physics for it, and then used four rectangular bodies to put walls around the area seen in the above screenshot. In order to try everything out, I allowed the keyboard keys to be used to boost the bottle off into some direction, and soon I would see that bottle of mine bounce off of the walls in quite a realistic fashion.
Tools and frameworks
The aforementioned events were all executed using my MacBook Pro, but I do have another computer running a different operative system called Ubuntu, and I really prefer none of them over the other when it comes to doing work. They're both nice machines, and I'm equally productive using any of them. The main difference in the workflow is that the Mac is exclusively used to create the copies of the game that should run in it's operative system, OS X, while the other computer is used to do this for Linux and Windows. Other than that, I'm quite happy working on any of them.
The Linux computer does contain my favourite program for writing code, though, which is called Code::Blocks (http://www.codeblocks.org/). It contains a lot of nice, intelligent features to speed up the writing right out of the box, and in addition to that, I've added lots and lots of custom commands tailored to my own habits, in order to make everything as fast as possible for myself. Code::Blocks does exist for the Mac as well, but it has one major bug that renders it pretty much useless to me, and so I've had to find other solutions. Xcode, developed by Apple themselves, is a nice environment from which I do all of my compiling, but it doesn't really conform to the ways that I write my code, so for the Mac, I've settled on writing most code in a program called Eclipse (http://www.eclipse.org/), which contains less features than Code::Blocks, but is better than anything else I've been able to find so far. This is only for the computer version, though; for the iOS version I use Xcode exclusively, not only because its Apple's very own, devoted piece of software for the purpose, and so makes it all very easy, but also because I know of no other text editor that's designed for the weird mix of C++ and Apple's main programming language, Objective-C, that I'm using to write the code for this version (commonly called Objective-C++).
Box2D is one of the frameworks that I have mentioned before. It's a library created to perform fairly accurate physics simulations and calculations, which is used for this purpose in 'Bottoms Up!'. Another type of framework that the game depends upon, is a graphics framework to facilitate the task of drawing images to the screen. For the computer version, I'm using a framework called SFML (http://sfml-dev.org/), which is built upon OpenGL (http://www.opengl.org/), which might be a more familiar name to the ears and eyes of those who have no programming experience, as this is the core of the graphics frameworks of many blockbuster games today. SFML is also what handles the playback of the game's music and all of the sounds, and can pull off even more tasks solely devoted to game development. For the iOS version, I'm using another framework, called Cocos2D (http://www.cocos2d-iphone.org/), which is nice in that it takes a lot of weight off of my shoulders when it comes to drawing to the screen, but it is lacking in some features that I need for this game, and the execution is quite slow, which has caused me to hack it a bit in order to optimise and increase speeds; something which has involved pure OpenGL code, as Cocos2D is also based upon this library, or, more specifically, OpenGL ES, which is a subset of OpenGL, primarily intended for portable devices with less power than normal computers.
My final outside dependency is the excellent light-weight library TinyXML (http://www.grinninglizard.com/tinyxml/), which I'm using to load and parse XML files. XML is a file format commonly used to store data, pretty much identical in layout to some languages used for website development, which is thus very familiar and likable to me. This library works perfectly both on computers and iOS, just like Box2D, so the parts related to graphics are pretty much the only ones that I've had to rewrite entirely, while the physics and graphics code has remained mostly intact from the computer version.
Learning
Creating 'Bottoms Up!' has so far been a great experience for me, even though the game still has quite a way to go before it's finished. While the development has been a fairly smooth process, a few hardships have been encountered along the way, but I've eventually managed to solve the issues that have come up, and even though this game might not look extremely advanced to the world, a lot of time and code has been spent on assembling it all, and I feel that I have developed greatly as a programmer during these months, and I have learned a lot of important lessons.
For instance, I used to be extremely pedantic when it came to the layout of my code. As I stated in the last chapter that I wrote, I rewrote the engine of my platformer game three times, slowing progress down over and over, and never really got anywhere. A lot of nice code was written, but still there's almost nothing to show to the world. When it came to 'Bottoms Up!', which wasn't even supposed to be a full game in the first place, I didn't worry as much about layout, and made everything in more of a quick and dirty fashion, without much planning ahead, and this has, on the one hand, increased my productivity and has taken the progress of development quite far in quite a short time, but on the other hand, much of the code is just a mess, that I am in no way proud of, and at times, it has been hard to work with when revisiting or adding to certain sections. It is also quite a tedious process to add new content to the game; something which would have been a lot easier and faster to do if I had just sat down to plan out a good system for it, and had written more code initially, to prepare for future additions.
The moral of the story is that I need to somehow combine this workflow with my old one to create the perfect one for future projects. I'm sure I won't succeed the first time, but I will probably do better than this time, and I'm sure I will learn something new along the way, and this also brings me to another very important lesson learned during this project; it doesn't matter if the code isn't the most beautiful beast that eyes have ever been laid upon, if it's still working out perfectly well. Finish the project anyway. You will learn so much along the way if you dare to face new problems like that, and you will be able to make every new project in the future even better than the last one, and that's just regarding the code; it doesn't mean that the result itself - the actual game, which is what people will take part of in the end, after all - won't be good. Something clearly shown by the fact that I am actually very content and happy with what Erik and I have been able to come up with. I enjoy playing the game myself, and I believe that's quite an essential key element to success. There needs to be joy and pride forged into the sword for it to shine.
