HackAddict

It wan't to keep the big big Tank-You-Community (irony) up to date on what is going on behind the scenes. At the moment MentalFS and I are working on the generell gamelogic and the networking. In detail we are working on the object serialisation format. Besides MentalFS tries to port our level editor to java2d for better integration in our intended Swing main menu.

It's now 13 days after the techdemo release. We had 164 downloads so far, which is a good start i think. Some users had trouble with Slick or LGWL and we have no idea why at the moment. My first guess was win7, but by now we have feedback of serveral win7 users were it worked fine. My second guess was an odd slick/lgwl-bug which appears if desktop colordepth and game colordepth differ and the game is started windowed, but this can be ruled out too. Now i think it's a problem with the ogl drivers of the affected users, but i can't really proof it and i jet don't have any ideas how to avoid this in the final release. In general we unfortunatly got not as much feedback as i hoped, especially compared to the high download count, but the few responses we got (beside the error reports) were pleasant positiv.

Now that we finally have a tank you project blog i think we should start with a little retrospect in the history of this project. Allthough it seems unbelievable and is quite embarassing this project (resp. it's ancestor) was founded in 1997 under the name "Martes Zibellinae" (latin for sable). The plan was to build a simple clone of worms with little sables instead of worms. We loved worms very much, but thought that quality got lower with every sequel. Since we were still attending school we had a lot of spare time to invest, so we startet without much experience in game development and only basic coding experience.

The first attempt was developed in C++ and used plain Direct X. We got suprisingly far with this attempt and had some demo with destructable terrain, mines und so called "rubber ducks", but without movable sables. "ruber ducks" where supposed to be a special kind of mine which detonates if a sable leaves once he stepped on it. Due to our missing expierience the code quality war aweful and the hole project was hardly maintainable or extandable. There was a bug in the "rubber duck"-ignition logic which we were not able to find no matter how hard we tried it. Finally we declared the first attempt dead and started new right on from the scratch. I would love to show the old demo with it's pixel-graphics to you but unfortunatly it got lost druing a hdd crash (we had less experience in backups and version control too ;) )

In the second attempt we tried to construct a fundament on which we can build a game, so we tried to make a little sprite-engine as abstraction from Direct X. The thing was calles HASE (german for bunny) which is a backronym for (HackAddict Sprite Engine). It could handle animations and had a cool algorithm for the automatic distribution of the sprite graphics on resolution sized offscreen surfaces. I can't remember why the second attempt went wrong, but it did. I guess it was when we left school and had to server our military duty of ten month in the german army (resp. air force). We haven't much spare time and in the little spare time we were busy to waste our payment on drinking ;)

In the third attempt we switched from Direct X to SDL in first instance to make the game plattform independent, but it turned out to be an improvement in nearly every way. SDL is really a nice engine, but that don't kept the project from falling asleep over time.

In the meanwhile we become professional software developers and at work we are developing java applications. Although java hasn't the best reputation for game developement we decided to give it a try and started the forth attempt. We looked into slick but decided to switch to technical 3D and jMonkeyEngine. It worked quiete fine but we had a lot of trouble in terraingeneration and again a lack of experience this time in 3D development.

After this java excursion we went back on C++ and SDL. We builded an engine which i am still very proud of. It handles extendable XML-described game content and was very flexible and performant.This attempt died when we found out that hardware accelerated rotation would be really usefull. SDL support only very slow software rotation and the OGL integration requires much OGL knowledge which we didn't had.

After failing again we decided to change the game concept radically from sables to tanks and the actual design. Sixt time is a charme. As you can see we're back on java with Slick and realtime physics in (j)box2d. We are old and experienced enough and know what we are doing, the only problem is still the lack of spare time which can be invested in TankYou.

Now we're very hot on finishing this project.

As you might know, Tank You started as a completely different game, which was mainly supposed to be yet another clone of Worms. There are still a couple of similarities, but since we switched from animals to tanks a lot has changed, making Tank You more unique (at least in our eyes).

When we started our Tank You ancestor, land was supposed to behave like known in Worms. That means, an explosion should cut out a circle of the land, creating a hole. We didn't exactly know how it was done in the original, but the best guess is that the whole level is a graphic with one color being left out to mark the free space. Actually we can be pretty sure, seeing that this is exactly the format Worms 1 used for custom levels on the Amiga.

So around a decade long, we always used this method of representing land/the level. Of course we had to cut the level to several smaller images. Back then, most graphic cards didn't allow images greater than the screen size. Later it was done just to increase performance. And after switching to Slick, we had to respect the texture sizes from OpenGL and used alpha values instead of a color key.

I would say this was one of the few structures from our code that remained the same all the time and determined how the game looked and felt. Well, it was, until we decided to try a physics engine.

Using a physics engine provided us many benefits: The whole logic of how a bullet flies, when an object has to stop moving after hitting the ground, collision detection and in what angle a tank has to be where it stands is taken over by the engine. But it also has its downsides. Basically everything has to be represented in a way the engine understands. That means, regarding the level: we can't just use an image. The engines we tested want their objects to be polygons.

Translating an image into polygons would either be inaccurate or just madness. We didn't even try that because it would take up more memory than the images themselves. Instead, we threw away our understanding of how land works in the game. Land is now divided into little polygons. This changes a lot: Explosions now can't just cut a hole in the ground. But wouldn't it be boring if the level was undestroyable?

We certainly think so. We decided to add Hitpoints to chunks of land. Land is now maybe not immediately destroyed, but if hit several times, or hard enough, it will be gone. It still looked a bit wrong because we were used to pixel accurate explosions, so it was a sacrifice.

But a little addition makes the new way land is handled brilliant: We can make the chunks movable. When the hitpoints are reduced below a certain treshold, a chunk of land will become loose and fly around. This brings a whole new kind of dynamicity to the game.

They can fall down, they can block the way of your tank. But they can also help you moving over a pit. Maybe some day they will crush you when they hit you, but that's not implemented yet. Until then you can shoot or try to push them out of your way.