Glider

Q:How big is your team and how much did it take you to develop Glider? What was the most time-consuming task?

A: The REVOgames GbR is a group of five participators: 1) André Weinhold, managing director, 2) Dennis Kühn, product director, 3) Markus Pfeiffer, technical director, 4) Jürgen Rabe, creative director, 5) Dirk Rosenlöcher, freelancer.

The team primarily focuses on the completion of our first project Glider - collect'n kill, which is meant to be the foundation stone for ideas and tasks coming up. Glider has been released in Germany since the 10th of October 2005 and it has got great reviews. All in all the development of Glider took a long time, but that was necessary for concluding our first game with major success.

The most time-consuming task is translation, because we aren't working in an office or something like that. Furthermore Glider - collect'n kill was only developed in our free time, that is in weekends and after school. We are very proud of finishing the game and the team has become more experienced, allowing us to be better prepared next time.

Q: I understand that you are looking for a publisher; how well was Glider received by the media?

A: Well, in the beginning nobody believed us, and of course nobody knew anything about Glider or REVOgames. But after the Games Convention 2004 everything has changed; some of the German top publishers keep an eye on REVOgames, although Glider - collect'n kill is a casual (and no full-price) game. At the Quo Vadis 2005 our project's value was finally recognized and from then on everything was smooth. We've got a TV interview at RTL II and many publications have included articles and reviews about REVOgames and its recipe for success.

Q: What is the approximate size of the code for a game like Glider?

A: Currently we've got over 11 MB of code for all tools and in-game mechanics. A part of the code consists of *.wdl files and the rest is our game dll which includes some parts of the level manager and the entire A.I. system.

Q: Please describe for us one of the biggest problems you've encountered and how did you manage to solve it.

A: One of the biggest problems was the lack of some features, who were only available in the beta versions of the engine. We had to write code or to create

direct game content a few times with different solutions and "dirty-hacks". It's much better to use an official engine version for developing a game than to use a beta for that. That's one reason for the 6 years of development we needed for glider.

The bot concept in Glider went through some changes over time. First we went through a lot of brainstorming, and we all being new to game programming thought of the game AI problems a little too loosely. We wanted bots that were a challenge, that were realistic and that worked even on low end hardware. What does a nice and intelligent bot have to do? It has to navigate the game world, it has to percept its situation, including enemy movements and own status, and it has to decide what to do. To make the bots' movements as realistic as possible the bots use the same steering mechanism as the human player, that is they signal mouse movements and shooting/weapon change commands to the game module.

The first problem we decided to address was navigation. As any game designer can imagine, free realtime movement in a 3D space is quite a challenge. So in 2003 we thought up a few ideas which involved using quadtrees and true free 3D movement. It took us nearly one year to accept that this concept would not work for us. It was too slow and there were too many problems to address. During this time we developed quite a few algorithms that were working for the first levels but would horribly fail for the bigger ones, because the possibilities of our node compiler were limited by the Acknex engine.

We finally went with a node based approach, letting the level designers position nodes and then connected the nodes automatically. The search algorithm used then was, as always, a custom version of the A* algorithm. We now had notably less nodes in our levels and additionally had every item covered by nodes, so that searching for items was easier.

We were at first going for some fancy self-built file format for the level data, including the nodes for AI, items etc. This was done using standard Unix parser tools fle x and yacc. A short time later I learned more about XML, and we wanted to go with XML for everything. But, as life goes this wasn't going to happen, because there was no time to implement the complete resource management anew.

Q: Are you using any techniques that can keep even the owners of a modest PC happy? If the answer is affirmative, please share some of them with us.

A: Glider can run with high frame rates even on "old" machines. To achieve such a result we had to deal with a huge option set, for example switching particle

effects on and off. Besides the straight graphics programming there are also many internal management tricks. For example every ship in glider traces only one time per frame and share its results with every other ship in the game. Also we're not using "c_move" only; we have created an own movement checker which chooses between the old / faster movement command and the new one, so we can use poly-accurate collision detection at maximum speed. We have also used this system for our own network prediction to make the player's game feeling much more "smooth". We have also used LOD; this way you can get a really small script-execution time even on "slow" computers.

Q: What is the typical latency in a regular (over a local area network) multiplayer game?

A: For LAN games a latency of 10-15ms is a quite normal value.

Q: Please give us a few tips for the beginners.

A: Develop your games with modules and bring them together after you tested them alone!

Thank you a lot, Andre.

www.glider-game.com