April 5th, 2008 by admin | Posted in Programming | 3 Comments »
This is really the main purpose of this blog, for me to document the development of my game project.
I have always wanted to be a games programmer, since I was about 11 and first played Prince of Persia (which, incidentally, is a fantastic use of the PSP DosBox port). It’s why I became a Software Engineer in the first place. But it turns out that just attending Uni and doing OK in your classes doesn’t make you a great programmer, and it certainly doesn’t (on its own) give you the ability to be a games programmer. Sadly I didn’t learn this until after graduating, applying for a bunch of programming positions and failing their tests hardcore.
I really don’t like doing programming tests. Not necessarily because of the people setting them or the tests that they set (I’ve had some negative experiences but they’ve generally been rare), but a written test is just not a particularly realistic scenario in which to test the ability of a candidate. I get really tense during tests and seem to forget everything. I did one a little while ago that I think I may have answered 70% of the questions in. I had great difficulty writing the code in a word processor. The next day, when I was more relaxed, I re-did a few of the questions that were giving me trouble. It took me 5 minutes, they compiled first time and worked correctly after one minor change. Sadly the answer I submitted was incomplete (but completely broken).
I realise that companies have to select their candidates somehow, it just annoys me that I seem completely inept at the chosen method. I guess I’ll get there in the end, after much practice. At least I’m building up a collection of tests that I can use for study.
Anyway. On to my project.
It started as an entry into the Gamedev Four Elements competition. But that was really just a motivator. I want to learn as much as I can about games programming, and the best way to do that is with a project.
Very early on I decided that I wanted to write as much of the code on my own as I possibly could, even if I was essentially just re-typing it from a tutorial or textbook. I guess the theory is “I hear and I forget. I see and I remember. I do and I understand.” This is not an efficient way to get a program written, but I decided that since it was about learning I wasn’t going to care about how much time it took, or how much more complete it would be if I used someone else’s code.
Right now I have a skeletal framework done. It uses a bunch of interfaces, in particular it uses a:
- Platform interface
- This abstracts the platform-specific tasks like creating a timer and creating threads. I currently have a Windows interface only.
- Graphics interface
- This abstracts the calls to a graphics API. Theoretically, I should be able to exchange the OpenGL interface I’m currently working on with another (e.g. a DirectX interface), recompile and it will all just work (I tried this in the early stages, and it worked well).
- Input interface
- This abstracts the input system. Eventually, I plan that you will do something like “if (input_.Fire())” and it will completely abstract which key/button is being pressed, so you’ll be able to use the one interface for joystick, keyboard, game pad, etc.
- I currently have a DirectInput interface.
- Audio interface
- This abstracts the audio system and is responsible for the loading and playing of audio files. I don’t currently have an audio interface, but I’ve used DirectX’s audio system in the past, so I’m thinking of using OpenAl so that I can get some different experience.
- Render surface
- This is a bit of an odd one. I didn’t want it to be part of the Graphics Interface, because I wanted it to be more flexible than just rendering to a standard Window (or whatever display the platform used). It should also be possible to have multiple different Render Surfaces active at one time. Sadly, at the moment it is very much just a wrapper around the standard Win32 window functionality. Hopefully in the future I’ll abstract it a bit more.
I’m also considering a Physics interface, so that I can plug in ODE, Havok, Newton, Bullet, whatever. At the moment, however, I’m writing my own physics. I know, it’s a long, hard process and my results probably won’t be as good as if I just used someone else’s engine, but ever since I started playing with ODE I’ve wanted to know how it’s all done. If this were a project that needed to be done on a schedule, I’d plug in a 3rd party engine and just run with it (probably Bullet, I like it the most of the free engines I’ve used… I haven’t tried Havok, but I’m excited that it’s now being offered for free… have to see what that’s like in May…). Since I’m doing this to learn, I really just wanted to have a go.
I have to say, it’s been a lot of fun so far. At the moment things fall. That’s it. No collision yet. Oh, I also have springs. Which is kind of nifty. I started with the book “Physics for Game Programmers“, but I didn’t find that it was that much use in a general sense. It covers a lot of specific equations, but it doesn’t help you if you’re trying to work out how to write a general physics simulation environment. Once I have the basics in place I’ll go back to it. I did use it to implement a Runge-Kutta integrator, and use that to implement some basic springs, but I’m not using that code at the moment.
I moved on to reading online articles, in particular Chris Hecker’s articles from the Game Developer Magazine. These are great articles, and I learnt a lot, but they didn’t go into as much detail as I wanted. I’m still a fairly fresh software engineer, and I didn’t do all that well at maths or physics during my schooling, so I needed something a little more in-depth before I could really write a decent system.
So I moved onto the book “Game Physics Engine Development” by Ian Millington. The Amazon reviews for this book were pretty good, but the opinion of it on Gamedev was very low. Having read through about half of it, I don’t know why it got such a bashing. I think that the people at Gamedev were just beyond its content and hoping for something else.
As a beginner I personally love it. It’s well written, it contains exactly the content I was hoping and it walks you through creating a basic Physics Engine that you can then update and modify yourself later. I highly recommend it.
When it comes to the code, I don’t agree with all of the author’s choices but he always explains his reasons and he points out alternatives and sources of further information. I do feel that he perhaps skims over some of the maths and simplifies it a little too much, but that information is well covered on the Internet and in any other games programming text book, so it’s not of major concern.
And that’s pretty much what I’m up to so far. I’m about halfway through the book (I’ve read further ahead than I’ve implemented) and I’m enjoying it immensely. I’m focussing on the physics implementation at the moment. Once that’s at a basic but working stage, I’ll move on to other areas and making a simple game. I’m not sure if I’ll keep going with my 4E6 idea, which was a kind of management-strategy game. I think I’ll probably do a simple action game first.
Well, that’s a pretty long post. I hope I’ll be able to make more frequent updates from now on. I need a new way to keep motivated, and this could well be it.
- Punch
