Games

Asteroidz saw life as last minute a joke. Before leaving Kamstrup I was asked by the PO to create some kind of easter egg in MCom. So I created a basic Asteroid clone at home and named it Asteroidz since we all know a Z at the end makez thingz much cooler. If you know where to click in the MCom Client, you can play Asteroidz at work… Or take the easy route and just download it here 🙂

Power Racing was meant to be the next title from PowerChallange and was meant to bring the action packed 3D gameplay from our MMO football (soccer) game to the racing circuit. Unfortunately the financial crisis of 2008 hit before the game was ready affecting the game that never saw the light of day.

I worked mostly on backend code and frontend for the web portion for this game since it shared a lot of functionality with out other action based games such as Power Soccer and others that were under development.

ManagerZone is a MMO soccer manager game that has been played by millions around the world. There have even been ManagerZone World Cups where the best managers get to be managers over their countrys official teams to face of for the virtual World Cup trophy.

I worked on all kinds of things for this game. Backend and frontend work for the web client, payment processing, match simulators, launchers and on and on.

ManagerZone also came in a hockey variant. It shares a lot of DNA… and code. But has specific code, simulators etc to handle the game of hockey.

Before FIFA Online there was Power Soccer and from what I heard back in the day EA had their eyes on it. Power Soccer was a 3D MMO action oriented football (soccer for those who call football running with the ball in your hand) game. I worked on back end and front end parts of the game. The game itself shared a lot of DNA with our other football game, the MMO football management simulator ManagerZone.

End of Road was a prototype developed for the Swedish game company UDS during a period of five weeks and was pretty basic. It involved a time trail mode, a city map done in Maya and exported to our engine via a MEL-script we wrote. The car was handled as real hovering cars using rigid body physics and the car could be handled by both keyboard and joystick (wheel and pedals). Like most of our projects we started pretty much from scratch and wrote everything we needed and it was built using SDL and OpenGL to be able to compile and run on multiple operating systems. The response from UDS was very positive and they had a hard time believing that we created this in just five weeks, from scratch, which was a great boost to us.

As with most of our projects we also included a level editor were you could place objects and lights in the world. The world map was divided by the engine into a bsp tree and we implemented frustum culling etc to keep performance up. Stencil shadows were used on the car but since it didn’t feel grounded I, in the last minute, added a direct drop shadow under the car. Using another stencil shadow, of the original car model… with all the polygons 🙂

Most of our ideas made it into the game in the few weeks we had, for instance jumping from a roof at one part in the map. Doing this when actually simulating the rigid body physics of a hovering car was something we weren’t sure how well it would work, but it turned out to work perfectly. A boost was something we didn’t have time to implement and if you play the game today that is probably a good thing, since computers today are so much faster than what we had to work with. So the car today manages to get a bit further out from the camera than was intended.

If the old installation package I made back in the day still works you are free to give the prototype a try.

Another five week project while studying game development. The game made use of an automated level generator, computer player RTS style AI and a thread based A* algorithm to handle the units movements. The player could build oil pumps for resources and use trucks to collect coal from mines. Then the player could build an armory and from that build tanks and jeeps.

As with most of our projects we also included a level editor were you could place objects, lights etc in the world.

Xaviour was the first “big” development project we got to do during my studies in game development. It was also a sign of what was to come for me and my fellow student Magnus that I ended up working a lot with on projects like this. We got five weeks to plan, design and develop something. Since we had not taken any course in C++ or object oriented development yet and had done very little that drew even a single pixel on screen the idea was probably to keep it simple. But we soon found out that me and Magnus, especially when pushing each other, didn’t know what simple was.

So, without having started the first course in C++ yet, no knowledge of 3D programing, OpenGL etc we set ourselves our goal.

-“How about a 3D shoot-em’up prototype, written in object oriented C++, OpenGL utilizing this new SDL library we just found?”

-“Yea, with powerups, a level editor, the ability to create complex objects by linking objects together, at least one complete level… and a boss fight!”

-“And a particle system for smoke, explosions etc. And animated textures…”

Looking back at it I can see that we set ourselves quite ambitious goals. But, perhaps partly due to us not reflecting about that at the time, we ended up delivering all that we had set out to do during those five weeks. Granted we did spend some late nights coding, 3D modeling, creating music and sound effects etc… hehe.

The initial idea, which was probably why we went with 3D instead of 2D, was to allow the perspective to change. This is evident from the old design document where we wanted the first level to be over head and the second to be from the side. We even talked about changing the perspective half way through levels etc. Due to time constraints we only made the first level though.

Although we though we delivered we felt that our editor was pretty basic etc. but we got a big boost in confidence when we showed the finished project to someone from UDS who applauded our tools and said that “this is more than we get to help us in most of our development”. Perhaps he lied a bit to be nice, but it made our day.

Dolly was a simple mouse driven game where you were meant to avoid the wolves and make your way through the level and get safe back home. The engine that we used was originally a software based tile rendering engine that I had created early on in our studies. For Dolly we re-wrote the renderer in OpenGL and were able to use hardware acceleration. This allowed us to not only achieve better performance but also enabled us to implement some nice effects. One being a particle system that supported several emitter types and could handle both 2D sprites and 3D objects. Something we later used in other games for exploding objects etc. The engine clearly needed a name and was thereafter called the Dolly Engine.

The game was meant as an experimental game used to test out the A* pathfinding algorithm. As with most of our projects we went over board for the time we had and created a level editor that allowed for creation of levels in which Dolly could move around.