I have decided to rewrite TankWar, and I’ll be writing a bunch of blog posts about the process. If you ever wanted to know how to write a scorched earth/worms-like game using just JavaScript, now is your chance to learn ;)
This is the first one: Assessing the damage. In other words, take a look at the old code and see what can be salvaged. I’ll also list some issues with the current implementation, and how I plan on solving them in the new version.
Issues in the current implementation
I wrote the most of the code in the current version of TankWar somewhere in 2006. Let’s be frank: The codebase sucks.
It’s a mess.
I’m surprised some of it ever worked. At all.
My coworker Artem tells me recognizing your old code is crap is a good sign: It means you have improved – and I agree with him.
In addition to being pretty poor code, the current version does have some bugs too:
- If your bullet moves very fast, it can go through the ground.
- The graphics system is poorly implemented which can be seen especially when using the bomber weapon – it can get pretty glitchy
- The bullet trajectories deviate wildly depending on the computer’s speed
While some of these issues could be patched into the current code, it would just make the code even more fragile.
Damage control
In most cases there’s some useful code even if most of the code is messy.
In the case of TankWar, the main implementation of the game engine, menus, etc. will be thrown away. They make most of the code, but they are also the worst parts of it.
The good parts of TankWar include the terrain generator, some vector math classes and some utility classes.
It seems we can apply the statistic that simpler code contain less problems here too.
Solutions to the current problems
First and foremost, the codebase will need to be organized better. Now it’s just a jumble of code and HTML, CSS and whatnot mixed together like magic hobo gravy.
The game engine itself will need to be more robust and be able to handle fast moving bullets properly, and the trajectories need to be correct.
Bullet collision solution
The solution to fast moving bullets going through stuff is improving the collision detection mechanism. Currently the implementation is quite simple: It simply moves the bullet each cycle and checks if the bullet intersects the ground or other objects. This is very easy to implement, as the canvas element has a function for it, but it’s not very accurate with fast moving objects.
A better approach with fast moving objects is using ray intersection detection. Put simply, this means we will check all the points in the trajectory, including the points between the positions the bullet actually is in. In the old implementation, depending on the speed, there could be tens of pixels of space which was never checked for hits.
Glitchy graphics
The solution to the issues with the graphics system is to make it separate from the other stuff. The current graphics engine was just quickly slapped on top of the physics engine to make it display pretty pictures. This is more of an architectural problem than an algorithmic issue as the collision detection.
Additionally, the graphics system may be a little problematic in general. While it works with the current simplistic graphics, I’m not sure whether it would function very well if I wanted to include more complex graphics.
Bullet trajectory problems
For the third problem – framerate dependent trajectories – the solution may be more problematic. The current version already attempts to fix this by using time-based movement. However, it does not quite work, meaning I’ve either implemented it wrong or the timer is not accurate enough.
If the timer turns out to be inaccurate, the solution may be to precalculate the trajectory using a predefined framerate. This means we would have to first calculate the trajectory, and only after it’s been calculated, we could render what happened. This might be difficult, because calculating the trajectory may take so long that the user would notice a significant delay between “shooting” and the game actually performing the shot.
Then again, the frame rate calculator was (as far as I can remember) also slapped on top of the existing stuff and never really properly planned. The timer itself works quite similar to the timer in my JavaScript bitmap sprite animations post.
In closing
The rewrite will probably take a while, depending on how much time I’ll have to work on it. I will probably put together some more posts on the topic as I have some progress. Let me know if there’s anything specific about it you’d like to hear.
Naturally the new version will generally be more awesome than the old version – it would be rather pointless to just rewrite it and add nothing else than better code.
Further reading:
Rendering graphics in JavaScript games