Prototyp1

Post Mortem

The first prototype is complete so it is time to write a post mortem. We set out to complete it in one month, it took only a week longer. So that goal was accomplished. It was the first video game for both of us.

The idea

In the last post Malte described the idea we had at the beginning. In short, we wanted to do a isometric real-time strategy game in a digital pre big bang world. The story stuff was getting to complex, so we cut it awayand concentrated on the gameplay itself. And even this changed a lot along the way.

The process was pretty iterative, our professor Dennis Paul even called it bottom up game development. I bet he didn’t know that this term already exists, I just discovered it right now. (As it turned out, he did know it. And this term is much older then game development. Sorry for that.)

We started with a world where you could build several buildings. We changed the behavior of the buildings constantly till we found something that was working. In the end only the land itself and one building was left.

So what is the game now? I don’t know if there is a good term for it, but maybe it’s a “expand and conquer multiplayer game”. That sounds somewhat right. The game itself has a more detailed description on what you do.

The technical stuff

Being web guys, it was pretty clear that this game has to run in the browser. But we had to choose between vanilla HTML, canvas or webgl. Like the previous post stated, we settled with vanilla HTML. The node.js part was new for both of us, so choosing a new technology in the graphical part sounded after to much work. And this was a good decision, we ran almost into no problem on this side.

Combined Server & Client Code

That was a thought that sounded pretty good in my head. We use javascript in the client and the server so why not combine the code base and use the same files for both. This turned out to be completely wrong. At least for two unexperienced javascript programmers like us who didn’t have a solid framework to build on.

Network Performance

To much network traffic makes the browser to melt down. We thought, hey, this is an event based environment, so respond to this events. There were to much of them so we had to collect them in the end and send them in a packet. The game isn’t that smooth now, but works better in the later game.

Over the internet the response time isn’t that great, there are lags here and there. But it is playable. Over the local network it works really good.

Gif Performance

Yeah, never thought I would care about this. But somehow displaying more than 10 gifs, even small ones, is hardcore for the browser. Malte did something smart and put a translate 3d css property on the gifs. Just rotate the gif around 0 degree. That way the gif will be rendered in a separated process. Combined with the massive html we rendered and complex css3 matrix transforms, this still wasn’t enough. So we scraped the gifs and used plain pngs instead.

Conclusion

It was fun. And hard. We started with a lot of ideas, got technical problems in the middle, which frustrated both of us a lot, we lost sight of where we are going and found a good solution in the end. I think the game is fun, even if I loose all the time against Malte.