This was a joint project for C++ Programming and Real Time Graphics, which I did in the first semester at Hull. This was the first time I'd ever programmed in C++, and what with my previous experience being mainly in Flash, I have to say I don't really mind C++. A lot of people seem to hate it, but if you throw const's around like no tomorrow, a lot of the errors disappear. The rest are the really vague errors that Visual Studio helpfully makes vaguer, but everyone else knows them so it's cool.

No doubt I wrecked a few heads with constant noob questions, but then, nobody really remembers what it's like to be a noob. So a large thanks goes out to a lot of my class. A bigger one goes to Alexis, the french guy I'm currently living with, whose frequent conversations lead to a lot of things being easier. And for explaining the intricacies of bounding box collisions for me.

The Brief

There is a back story to this project, roughly along the lines of developing an "asset retrieval simulation" to train grunts for a futuristic multi-national quantum processing technology developer. But, it kind of sucks a bit, so I won't really repeat it here. What we had to actually make was:

As you can see, a piece of cake! On to what I actually did.

The Finished Version

What I actually got done differed a bit from what was needed to do. In true gaming fashion I improved parts that would make a better game, and in true student fashion I dropped bits that I didn't have time to do.

Despite the fact that repeatedly through the semester our lecturers emphasized the fact that you didn't really need collision detection, I soon found this to be a rather blatant lie. I don't know of many games that don't involve collision detection, and for this there was: running around the level, shooting stuff, and something else to fill out this list and make my point. For collision detection around the level, I used bounding boxes, which turned out to be a very easy, fast way of collisioning. On the downside, I didn't have a whole pile of time to spend developing the system, so there was the restriction that all the objects were essentially cuboid in shape, and had to be axis-aligned. However, in a rare inspirational flash into the future, I had already designed the level like this. Which meant disco. You can see this in action in the picture and video sections.

For shooting stuff, there was the same bounding box algorithms, except this time it was line-plane. I used line-cylinder for the pipes, which works pretty well, except for the fact that it only works on infinite cylinders. Not a problem, just make all pipes span the length of the level, and as long as nobody thinks to shoot out the window where an infinite steam-carrying pipe would be if it had a physical representation in the world, nobody's the wiser.

I was also pretty pleased about the security camera systems that I had set up. It basically captures the scene, messes with it a bit depending on the level of interference on the camera, and saves it to a texture. Coupled with the TextureManager class I developed, it meant that I could display a live level feed on the side of any object I wanted.

In the end I didn't add a lot of the cosmetic elements to the game, such as the GUI, briefcase, or indeed any game logic in itself. That doesn't mean that you can't play it as a game though. On the contrary, I challenge you to finish it without hitting the quit key. Or to stop having so much fun playing it. Anyway, I've uploaded some pictures and movies of the game in action, but you can also download the release version (3.15Mb). I've also uploaded the project report (1.48Mb) in super Word format, which includes amongst such delights as hand drawn sketches of the level. If there's enough interest I'll even put the originals up for auction. Probably in some sort of snazzy frame that automatically breaks any ice in any room.

Edit (01/Jun/07): I've decided to upload the source code of the warehouse project (3.26Mb). While I'm pretty pleased with it, it's not going to win any coding awards. Before judging harshly, please remember this was my first time doing anything in 3D, my first time doing anything in C++, and my first time using OpenGL. But hey, everyone has to start somewhere, right?



Wow, this is impressive. I've always wanted to make my own FPS. Is there any resource you recommend if I want to write something like this? I am fairly new to C++ and would love to get started on a project like this.

Damian Connolly

Hi Robert,
Thank you! It's been a while since I've done anything this low-level, but I'll try and answer your question. The first thing you need to be clear about it is whether or not you want to make a game or an engine.

What I've done here is more akin to making your own engine - it was part of our coursework at college, and so designed to test our knowledge.

If you want to go down this route, then you can of course download the source.

One thing that we made a lot of use of are the excellent NeHe tutorials on OpenGL.

If you want to follow along with a dev building a game from scratch, then check out Handmade Hero - it's going to go more into detail that I ever could.

A good friend of mine and fellow alumni also runs the site How to Make an RPG, which uses both C++ and Lua, but goes into a lot of depth.

If you want to make a game, then you don't really need to get into as much detail; let some very smart people make your engine while you concentrate on the game itself. To that any, any of the commercial engines out there are very indie-friendly. Unity (which we use at work), Unreal Engine (which I've never used, but is the engine behind a huge amount of games), the Source engine (which powers Valve's games), or any of the others will all suffice.

It's not an FPS, but if you want to go 2D with a view to the mobile/web, then check out Haxe, or Phaser; both will have you in good stead.

Submit a comment

* indicates required