Wolf 5K
It’s been a very long time since I first began picking it apart and translating it. Looking at the directory dates for the various lessons, it looks like I started it last year in July. Which actually sounds about right. Summer is the time when I can find the time to work on pet projects. Going through the code more for The Most Rediculous Game Ever I’m finding out more about why certain bugs exist. In the original version, enemies will occasionally get stuck in walls. This happens because the sprite gets too close to the wall and the player is positioned in such a way that the rotation of the player puts the sprite entirely behind the wall. And since the AI dictates that if you can’t see it, it doens’t move, it gets stuck.
The way I fixed that with The Most Rediculous Game Ever is by adding a line of sight algorithm. Rather than just checking the next step to see if it’s valid, I check the entire motion. Since TMRGE uses time based motion, it checks to see if, going in the same direction for one second will result in a collision with the wall, the object changes direction. This seems to be a sufficient solution. Proper collision detection couldn’t be done in Wolf5K due to size constraints. It would also slow down the game quite a bit. With C++, the hit to performance is negligable.
Another problem that existed with the original shows up when you die. Rather than checking if the current y position of the pixel for the sprite is on the screen and only drawing it if it is, the starting y is set to 0 if it’s less than 0. The result is that the monsters fall into the floor with you rather than the sprite being clipped like it should be. A hidden problem is the background. When you fall into the floor the background isn’t adjusted for the height difference. This isn’t an issue with the original since the background is pure black, but TMRGE uses a multi-colored background and at some point it needs to be fixed so that the background is redrawn from the new perspective when the player dies.
Another possibility is increasing the complexity of the background. Rather than using a fixed background (which is very fast), it would be possible to implement something like the original DooM uses. However, that would require drawing the background every frame pixel by pixel rather than doing a simple memory copy. It would look a lot better though and the background would then be able to rotate when the player rotates.
But, part of what makes this game rediculous is implementing advanced graphics techniques into a primitive rendering method that was first used in a commercial game in 1992. Wolf3D pushed the limits of modern hardware back then. Now the goal is to see how far modern hardware can go in 2005. Some of the things I want to do are lighting, bump-mapping and shadows.
Leave a comment
You must be logged in to post a comment.