During the course of my MSc at Birkbeck, I will happen upon a programming concept that flips a switch in my head, and gives me an idea for a game. This page shows the results of that thought process - a list of games that I wrote to help me learn about programming!
(started Nov-09, finished 03-Dec-09)
This is a version of snake which runs in the terminal. I made it after we had a C++ lesson on vectors, which instantly made my think of a set of co-ordinates for a game. I went home an coded this in about 4 hours, although the most time was spent figuring out how the curses library worked. It's not a great game, but it's works as a proof of concept.
Download: curses-snake-1.0.zip (windows, ubuntu)
Well, this is a boring game. It's not difficult to play, there's no speed up, and in general it's not very fun. But it is definitely snake, and it definitely helped me learn something interesting about C++, which is the point in the end. Certainly it has laid the groundwork for a better version to be made, which can include bells and whistles if it needs to.
The code itself, however, is a total mess, and I can't say I'm too proud of it. I stuffed the whole thing full of global variables (of all things) and made no use of classes, accessor functions, or anything actually good. We hadn't gone through classes in the module at that point, so I figured i'd code something functional rather than beautiful, and since the code is only ~250 lines long, and contained within one source file, I don't see much of a problem with it.
This was the first time I had encountered c-strings too. The ncurses library is written in C, for C, and so can't make sense of the infinitely more useful C++ string library. Before C++ I had thought that a string was a primitive data type, thanks to my roots in basic programming, but C condenses it down further into an array of char, using implicit type conversion to calculate it's size at compile time. Bizarre. Thankfully, the string.c_str() function came to my rescue.
If there's one key think I will remember about this project, it's the hassle I had to go through to find a cross-platform library that simulated ncurses for windows (so I remember it in future, it's called pdcurses and is currently available here). In future, I won't start a project using an external library without making sure it is cross compatable with all 3 major operating systems. It would probably also be worth compiling the project periodically on windows, just to make sure I haven't used something platform dependant, which I did on one or two occasions in this project.
Well, that's my first evaluation of a university side-project, hopefully there will be more to come!
(Started Dec-09, Finished late Dec)
This is a version of snake rewritten in OpenGL. My classmate Ian found some good OpenGL tutorials online, and realising that the libraries were free, open source and cross compatible, I decided to implement my previous project in sort-of-3d in OpenGL. This project also contains my first foray into games programming using classes.
Download: glsnake-1.0.zip (windows, ubuntu)
There's very little to write about this game - it's snake, just like before, but it uses classes and goes on forever instead of having a score limit. The game speeds up every time you hit 5 'apples' in a row. It's definitely more robust than the previous version of snake, but I can hardly say it utilises the full features of OpenGL, considering every graphics sprite is a coloured square of some kind.
Something else that's neat about my code is how blatantly it disregards the principles of encapsulation. Lots of critical pieces, like the main Snake object and the Map object, are global, which means there are some rather open access rules. Not only that, but both the map class and the Snake class access each others methods. So, that's some quite undesirable coupling there. However, in a game I think such things might be unavoidable - the logic of each actor is necessarily linked to the graphics when drawn on the screen, because it's desirable for both to be kept in the same object, but both elements of each object must be called from different 'levels' of code.
What's more, the actors will necessarily need to know where 'map' objects are, which in an ideal world would be their container class. So, in order to observe the principals of encapsulation properly we need a method that allows us to access the super-class, which doesn't exist to my knowledge in C++. Alternatively, we could go through convoluted method whereby we pass either a copy of all critical information, or a (possibly const) reference to that information in the superclass, directly to the subclass in the parameters, in which case we might as well have used a limited access global instead.
In conclusion this was fun to write, but brings up some interesting points when it comes to OODP practices in code. It will be interesting to write 'The Three Musketeers' game, where pieces are 'contained' inside a board, which provides the exact same issue.
By Doug Inman.doug.b.inman@googlemail.com
Last modified Tuesday, 06th April, 2010 @ 02:05pm