Procedural Gemoetry - or something like that anyway.
by Tom Bampton · 04/29/2006 (10:00 pm) · 5 comments
Last GID I decided to make a 3D BomberMan clone. After the GID, it looked like this:
The level was built automatically from a text file, the contents of this look like:
The script code just plonked the walls down as .dts shapes I'd quickly hacked together in Milkshape 3D. Brian Richardson's BreakableObject code was used to populate the game area with breakable crates and a quick hacked bomb rounded it off. Shortly after posting the .plan, we had a reasonable sized play test in the GID IRC channel. I think there was somewhere between 7 and 10 players. It turned out to be really fun just blowing up blocks, and of course each other.
So, this weekend I decided to remove the stench of nasty GID code and replace it with more durable code to turn it into a full game. First on the list was to rewrite the level code. Since I have never played with collision in TGE before and I am the first to admit that I'm crap at rendering code, I expected this to take a week. I was about 6 days out on that estimate.
Last week I threw together a basic SceneObject to render out the level data as a bunch of quads. This was mainly just to give me a starting point for today when I had time to work on it properly. It looked like this at that point:
Red squares are walls, blue is floor. One of the things Nauris complained about during the GID was the lack of floor textures, so I figured I'd make him happy by giving him a floor to play with.
It didn't take long to get to what I call Fairfax Cubes going. What are Fairfax Cubes ? Well, Matt always uses random(ish) colors for the first pass at any 3D rendering code so that it's easier to see the surfaces without having to worry about lighting.
After a while I got it textured. The shot below is possibly before I fixed mip mapping. The texture is basically a two frame "image map", the first frame for the walls and the second for the floor. This was mainly done so I didnt have to bother switching the texture in the rendering code. Yes, I'm really lazy, but wise man say minimize state changes in rendering code.
Collision took by far the longest to implement, and produced a lot of boring screenshots. In the end, player collisions and ray casts both work. I didn't bother with vehicle collisions due to the simple fact that there are no vehicles in the game.
After some more hacking to create a breakable box and get the gameplay code hooked into the new level code, and some art from Nauris, we ended up with the game being playable again:
This is also all fully networked. The only thing the client needs are the textures (although possibly they will auto download anyway), the level data is all sent over the network.
We still have a reasonable way to go before its a real game, but its getting there fairly quickly despite only having weekends to work on it. There's only been roughly 24 hours total time spent on it so far.
The level was built automatically from a text file, the contents of this look like:
################### #P. .P# #.# ### # ### #.# # # # # # ## ## # # # # # # # # .#. # # # # .P. # # # # .#. # # # # # # # # ## ## # # # # # #.# ### # ### #.# #P. .P# ###################
The script code just plonked the walls down as .dts shapes I'd quickly hacked together in Milkshape 3D. Brian Richardson's BreakableObject code was used to populate the game area with breakable crates and a quick hacked bomb rounded it off. Shortly after posting the .plan, we had a reasonable sized play test in the GID IRC channel. I think there was somewhere between 7 and 10 players. It turned out to be really fun just blowing up blocks, and of course each other.
So, this weekend I decided to remove the stench of nasty GID code and replace it with more durable code to turn it into a full game. First on the list was to rewrite the level code. Since I have never played with collision in TGE before and I am the first to admit that I'm crap at rendering code, I expected this to take a week. I was about 6 days out on that estimate.
Last week I threw together a basic SceneObject to render out the level data as a bunch of quads. This was mainly just to give me a starting point for today when I had time to work on it properly. It looked like this at that point:
Red squares are walls, blue is floor. One of the things Nauris complained about during the GID was the lack of floor textures, so I figured I'd make him happy by giving him a floor to play with.
It didn't take long to get to what I call Fairfax Cubes going. What are Fairfax Cubes ? Well, Matt always uses random(ish) colors for the first pass at any 3D rendering code so that it's easier to see the surfaces without having to worry about lighting.
After a while I got it textured. The shot below is possibly before I fixed mip mapping. The texture is basically a two frame "image map", the first frame for the walls and the second for the floor. This was mainly done so I didnt have to bother switching the texture in the rendering code. Yes, I'm really lazy, but wise man say minimize state changes in rendering code.
Collision took by far the longest to implement, and produced a lot of boring screenshots. In the end, player collisions and ray casts both work. I didn't bother with vehicle collisions due to the simple fact that there are no vehicles in the game.
After some more hacking to create a breakable box and get the gameplay code hooked into the new level code, and some art from Nauris, we ended up with the game being playable again:
This is also all fully networked. The only thing the client needs are the textures (although possibly they will auto download anyway), the level data is all sent over the network.
We still have a reasonable way to go before its a real game, but its getting there fairly quickly despite only having weekends to work on it. There's only been roughly 24 hours total time spent on it so far.
About the author
#2
Also, Power ups are already implemented. They were done during the GID.
T.
04/29/2006 (11:31 pm)
There are a number of reasons it is the way it is. Most of them revolve around level editing that's so simple a chimp could do it and total size of a level file being small enough that you could share them on a 2400bps modem and not have it take hours. Of course, im not actually targeting a 2400bps modem, just using it to give an example of how small the level files will be ;-)Also, Power ups are already implemented. They were done during the GID.
T.
#3
04/30/2006 (1:09 am)
The fact that you can make the entire map on a text editor is fracking awesome. Nice job Tom!
#4
And it's not THAT hard to do. A lot easier than trying to optimize a bunch of general purpose objects and subsystems. ;)
Nice work Tom!
04/30/2006 (10:00 pm)
I'd like to note that if I was going to implement a commercial bomberman game in Torque, this is exactly how I'd do it. It's streamlined, reliable, flexible - everything you won't get by abusing existing game objects for things they aren't intended for.And it's not THAT hard to do. A lot easier than trying to optimize a bunch of general purpose objects and subsystems. ;)
Nice work Tom!
#5
05/01/2006 (9:13 pm)
Very nice work Tom, it is definately impressive all that you got done in one day. Bomberman is a classic fav. of mine, so I am definately excited to see where this goes.
Torque Owner Paul /*Wedge*/ DElia
I'm not really sure why you went and wrote a custom render object for it, I'd think using stabdard mesh objects would give you a lot more variance in the style of level you can make (i.e. non-cube objects still using cube collision), though I guess this is probably a lot more efficient for collision and networking.