Super Mario Cuckoo: Initial Framework

For a quick recap, you can read the introduction to this series here: Making a Game for My Kids

Initial Framework

In all the projects that I have started before, I typically begin with a blank slate. This is likely due to my love of engine code and understanding the low level of how everything works and fits together. However, this does mean that I have to implement everything myself, and since I start pretty much each project with nothing, that means I spend a lot of time rewriting the same things. In addition, since each time I am generally trying some new technology or methodology, this means that I am often not able to reuse code that I have written before. Though since I am typically doing the project to learn and not necessarily to produce something, this usually isn’t too much of an issue. However, this time I actually aim to complete a game (or at least a full level or two). So I am finally looking at a couple of third party libraries to help with some of the development for the parts of this that I really don’t want to bother with anymore. I will detail these in addition to the selection of technologies that I am using, though they are more to facilitate development than actual learning tools. However, it is good experience to work with what other people have produced (and that are being used by several others) to get a good idea of other ways to design systems and APIs.

I plan on developing this for Windows, though my selection of technologies isn’t specific to this platform, so if things get far enough along I might port it elsewhere. After a recent computer upgrade, I have enough leftover parts to get another computer going, so creating something for Linux is a distinct possibility. Especially with the coming of SteamOS at some point, it might be a worthwhile exercise in the future. I will be using Microsoft Visual Studio 2013 Express since it is free and should be good enough for my needs (though they still don’t have a breakpoint window, which I find an odd omission). Since I am only planning on making simple 2D based games, I likely won’t need the tools for heavy threading work 🙂

For my general code architecture, I will be using a light object oriented approach. This is still early enough in development that I might switch it up and there is a good chance that I won’t really follow any one specific methodology other than KISS. Since I will be using a scripting language for heavy development for the first time, I am not quite sure the best way to approach things for gameplay, but that is part of the learning process.

I plan on keeping notes and details on my wiki here. Though I also plan on blogging about the development process along the way as well, so keep an eye on this space as well!

C++11

I chose to go with C++ over C# (or another language) because of my familiarity with it and the relevance it has with my job. In addition, the recent C++11 spec adds a lot of new stuff to it that I want to try out in some capacity. While a lot of this deals with threading stuff that I would love to try out, unfortunately that falls outside the scope of my current project. So most of the C++11 stuff that I am using mainly consists of a few niceties like nullptr and static_assert, but I can use a few core changes like their new pointer types: shared_ptr and unique_ptr.

Overall these are a good addition to the language and should hopefully make programming in C++ a little easier for newcomers, though I admit that I am struggling a little bit to change my mindset over to using them. Determining the best way to use them took a little bit of experimentation, as I initially sought to replace all pointers in my code with them. This quickly devolved into madness for me however, as I just couldn’t bring myself to change everything over since I knew a lot of it was just wasted effort on the computer’s part keeping track of all the bookkeeping. While realistically this likely wouldn’t have any noticeable performance impact due to the simplicity of my game, as an optimization-centric programmer by trade, it just didn’t sit well with me. I wanted to be able to get the benefits of the tracking without unnecessary cost. Fortunately this was easily solved by just making owning pointers be a type of smart pointer, and anything that I was just passing in a function to be used could remain a normal, dumb pointer.

The C++11 spec is pretty extensive in the amount of changes, so I am still going through it and deciding what might be useful to learn about and use (such as the move semantics). I will add them and update code as I see fit throughout the process.

OpenGL 4

I originally started with DirectX when I was learning graphics as a teenager (after failed attempts in DOS and while I got GDI working, it wasn’t exactly fast) and it is what I primarily use now. I used OpenGL primarily in college for my courses (universities love them some Unix), but haven’t really touched it much since. I messed around a little with WebGL when it was first coming on to the scene, but working with Javascript turned me off (that and the fact that IE wasn’t originally going to support it made me think it was unlikely to gain traction, though they have reversed their stance). So there is definitely a possibility that I might try to get the game on the web at some point, though it is just one of the many things I would love to do. First, though, I need to get something finished before I start considering what I would like to do next.

Back to the topic at hand, I decided to go with OpenGL since it has been making some strong strides as of late. With it having a strong grasp on mobile as well as a lot of smaller projects embracing it so they can more easily go multi-platform, OpenGL has been quickly becoming more relevant as a graphics platform. I must admit that I was actually a bit surprised given OpenGL’s sordid history. But with OpenGL 4 it seems they have gotten their stuff together on the PC front as well (and Valve saying that it is faster even on Windows never hurts). So I have decided to check out how things fair in their area nowadays.

Since OpenGL is only a graphics library, I need to get help in other areas to match some of the missing features in DirectX and XNA that I have gotten used to. This is part of where I really don’t want to reinvent the wheel and am opting for third party assistance. First I am starting with GLEW to handle the window initialization and all important extension loading to actually utilize the OpenGL 4 features. To actually load in my images for textures, I chose SOIL due to its simplicity and the fact that I was planning on using PNG files for the game. Finally, since I don’t want to have to write a math library, I selected glm to handle that part. As you may be able to tell, I am choosing simple libraries that only serve my specific need. I figure this will make them easier to use and integrate into my game. These also appear to be pretty stable and are recommended by the OpenGL wiki, so I assume they are good quality as well.

Lua

I had always wanted to increase my repertoire my learning a scripting language. They are very useful and serve a good tool for quick iteration. My goal is to force it so that I need to code using script in order to complete the game. This should make learning easier as it will give me a project. I have a book on Lua that I have read before, but without actually programming anything to make use of that knowledge, it has been mostly forgotten.

The reason for choosing Lua is that it integrates easily with C/C++ and is a small, simple language. It is popular in game development for this purpose as well. It was being used in a project that I was working on at the time when I first wanted to learn it, but being in graphics I never really interacted with it much. It was used primarily for gameplay and those related systems. Designers would use this to be able to tweak behaviors and actions that were typically set up by programmers. This allowed them to change and update the game without always needing assistance. Of course, giving access to the game like this to designers also introduced bugs, and I did help fix a few of these later into development. But going into a script and fixing a few things is typically easier than learning a new language (especially since I had some guidance as to what to look for that might have been causing the issue).

However, this model where basic, and sometimes even advanced, gameplay logic is contained in scripts is a good idea overall (assuming you have designers that are somewhat competent when it comes to programming, though always expect bugs when programming is involved). I am planning on doing something similar so that I can hopefully introduce my children to programming. And since scripts are interpreted immediately, it gives the kids instantaneous feedback when they see the changes in the game right away. I hope that it will be much easier for their patience and attention level that way.

 

Next Steps

So that is the initial steps that I am planning on doing when I approach making this game. So far I have only rudimentary progress where I have a single 2D image up on the screen and can move the camera around to view it, but it is a start. I have the Lua library integrated, but do not quite have it doing anything yet. Hopefully with the upcoming holiday break, I can spend a little more time building out the next parts of the game. I need to get a basic game tile rendering system going, so that I can display the backgrounds. It would be good to get a character that can jump around in those levels too. And of course, I need to start writing some Lua scripts to control various things. All in all, I am excited about the project and hope that I have time and motivation to stick with it in the coming months.