Crazy Arena 3D
by Nate "Nateholio" Watson · in Game Design and Creative Issues · 01/06/2005 (7:23 pm) · 6 replies
Over the past two months or so Ive been toying with the idea of making a simple arena combat style game. Basically a player can choose from a range of vehicles - wheeled, tracked, hovercraft, etc - and use them in an arena to fight other players. Nothing new here you may say. But the following will show several new/resurrected things in this game.
The most noticeable difference are the graphics - no textures or lights, just a wireframe rendering system. Frames are rendered using colored lines on a black background. Arenas are fairly open, with walls and a few scattered "buildings" for cover. The "ground" consists of a retro style grid pattern that appears as if it glows. This wireframe idea is a resurrection of older game styles Ive played before.
During gameplay, players will be able to use various things such as ramps, accelerators, bumper walls, vertical launchers, etc. to gain a better shot at an enemy or to dodge incoming fire. Players will also have to use caution near arena obstacles such as pendulum hammers, turrets, revolving spike balls, etc. Arena obstacles can also be used to kill a player who is tailing you, if you time it right of course.
What happens when you ram another player? You bounce right off of course! Think of two bouncy balls hitting each other. Play can be fairly fast paced, or slow if you are the sit and wait type.
Modes of play will be capture the flag, flag scramble, max kills, and timed versions of each. Flag scramble is a mode where there are x number of "flags" in the arena that are up for the taking. Whoever finishes with the most flags is the winner.
The game will be programmed in a homebrew VB application, as I believe Torque is way overkill for this. So before anybody tries to tell me I need to use Torque, realize that IM NOT GOING TO, so dont mention it or youll be wasting your keystrokes. Why VB you ask? Everyone here at GG is saying that your first project needs to be something you CAN accomplish, so thats why Im going to use VB instead of C++. I'll also be using DirectX.
Any suggestions, gripes, etc?
The most noticeable difference are the graphics - no textures or lights, just a wireframe rendering system. Frames are rendered using colored lines on a black background. Arenas are fairly open, with walls and a few scattered "buildings" for cover. The "ground" consists of a retro style grid pattern that appears as if it glows. This wireframe idea is a resurrection of older game styles Ive played before.
During gameplay, players will be able to use various things such as ramps, accelerators, bumper walls, vertical launchers, etc. to gain a better shot at an enemy or to dodge incoming fire. Players will also have to use caution near arena obstacles such as pendulum hammers, turrets, revolving spike balls, etc. Arena obstacles can also be used to kill a player who is tailing you, if you time it right of course.
What happens when you ram another player? You bounce right off of course! Think of two bouncy balls hitting each other. Play can be fairly fast paced, or slow if you are the sit and wait type.
Modes of play will be capture the flag, flag scramble, max kills, and timed versions of each. Flag scramble is a mode where there are x number of "flags" in the arena that are up for the taking. Whoever finishes with the most flags is the winner.
The game will be programmed in a homebrew VB application, as I believe Torque is way overkill for this. So before anybody tries to tell me I need to use Torque, realize that IM NOT GOING TO, so dont mention it or youll be wasting your keystrokes. Why VB you ask? Everyone here at GG is saying that your first project needs to be something you CAN accomplish, so thats why Im going to use VB instead of C++. I'll also be using DirectX.
Any suggestions, gripes, etc?
#2
Is the game 2D or 3D?
I appreciate your approach (do something you can accomplish)
but you might be shooting yourself in the foot.
VB6 + DirectX 3D is simply not a good idea.
I am an expert VB6 GDI API programmer
and a decent C# developer.
Here's what I know:
VB6 - this info comes from me doing it
1. VB6 + built-in drawing functions = easy, but too slow
2. VB6 + GDI API = still easy, but still slow
Depending on the number of lines you need to draw for the wireframes,
the GDI Line / Rectangle API may do the trick.
You should be able to do 800 x 600, 30fps, draw1000 lines a frame
3. VB6 + DirectX DirectDraw (v7) = hard to do, somewhat undocumented
faster than option 2 but slow compared to C / VB.Net DirectDraw
VB6 can't handle some DirectDraw stuff since not exposed via COM interface
VB6 COM interface very inefficient hence DirectDraw is slowed down
Many, many more DirectDraw examples available in C
probably easier to learn C than intricacies of VB and DirectDraw
4. VB6 + DirectX Direct3D = extremely hard to do, very undocumented
faster than option 2 but slow compared to C / VB.Net Direct3D
VB6 can't handle some Direct3D stuff since not exposed via COM interface
VB6 COM interface very inefficient hence Direct3D is slowed down
Many, many more Direct3D examples available in C.
probably easier to learn C than intricacies of VB and Direct3D
VB.NET - this info comes mostly from reading
While VB.NET is very different from VB6,
any VB6 programmer should have no problem learning it.
If you're using DirectX, learning VB.Net is much
easier than learning VB6 + DirectX.
1. VB.NET + built-in drawing functions (GDI Plus) = easy,
but too slow, even slower than VB6 + built in drawing
2. VB.NET + GDI API = still easy, but still slow
I belive this is exactly the same as VB6 + GDI API
3. VB.NET+ DirectX DirectDraw (v7) (Managed DirectX) =
easier than VB + DirectDraw, much better performance
Managed DirectX is much better / efficient
than the DirectX com interface for VB6.
Apparently, has 95% the performance / functionality of C DirectDraw
As good as C# + DirectX DirectDraw
but lacking in examples and books
4. VB.NET+ DirectX Direct3D (Managed DirectX) =
easier than VB + Direct3D, much better performance
Managed DirectX is much better / efficient
than the DirectX com interface for VB6.
Apparently, has 95% the performance / functionality of C Direct3D
As good as C# + DirectX Direct3D
but lacking in examples and books
Should switch to Torque at this point :)
SUMMARY
1. If you're using VB6, use VB6 + GDI API to keep it feasible.
2. If you're using VB6 + DirectDraw, DON'T.
Immediatly switch to VB.NET + Managed DirectX.
DirectX SDK has examples.
If you can handle it, switch to C# + Managed DirectX
since there are many more examples and books available.
Tom Miller is your hero.
01/07/2005 (9:39 am)
Are you planning on using VB.Net or VB6?Is the game 2D or 3D?
I appreciate your approach (do something you can accomplish)
but you might be shooting yourself in the foot.
VB6 + DirectX 3D is simply not a good idea.
I am an expert VB6 GDI API programmer
and a decent C# developer.
Here's what I know:
VB6 - this info comes from me doing it
1. VB6 + built-in drawing functions = easy, but too slow
2. VB6 + GDI API = still easy, but still slow
Depending on the number of lines you need to draw for the wireframes,
the GDI Line / Rectangle API may do the trick.
You should be able to do 800 x 600, 30fps, draw1000 lines a frame
3. VB6 + DirectX DirectDraw (v7) = hard to do, somewhat undocumented
faster than option 2 but slow compared to C / VB.Net DirectDraw
VB6 can't handle some DirectDraw stuff since not exposed via COM interface
VB6 COM interface very inefficient hence DirectDraw is slowed down
Many, many more DirectDraw examples available in C
probably easier to learn C than intricacies of VB and DirectDraw
4. VB6 + DirectX Direct3D = extremely hard to do, very undocumented
faster than option 2 but slow compared to C / VB.Net Direct3D
VB6 can't handle some Direct3D stuff since not exposed via COM interface
VB6 COM interface very inefficient hence Direct3D is slowed down
Many, many more Direct3D examples available in C.
probably easier to learn C than intricacies of VB and Direct3D
VB.NET - this info comes mostly from reading
While VB.NET is very different from VB6,
any VB6 programmer should have no problem learning it.
If you're using DirectX, learning VB.Net is much
easier than learning VB6 + DirectX.
1. VB.NET + built-in drawing functions (GDI Plus) = easy,
but too slow, even slower than VB6 + built in drawing
2. VB.NET + GDI API = still easy, but still slow
I belive this is exactly the same as VB6 + GDI API
3. VB.NET+ DirectX DirectDraw (v7) (Managed DirectX) =
easier than VB + DirectDraw, much better performance
Managed DirectX is much better / efficient
than the DirectX com interface for VB6.
Apparently, has 95% the performance / functionality of C DirectDraw
As good as C# + DirectX DirectDraw
but lacking in examples and books
4. VB.NET+ DirectX Direct3D (Managed DirectX) =
easier than VB + Direct3D, much better performance
Managed DirectX is much better / efficient
than the DirectX com interface for VB6.
Apparently, has 95% the performance / functionality of C Direct3D
As good as C# + DirectX Direct3D
but lacking in examples and books
Should switch to Torque at this point :)
SUMMARY
1. If you're using VB6, use VB6 + GDI API to keep it feasible.
2. If you're using VB6 + DirectDraw, DON'T.
Immediatly switch to VB.NET + Managed DirectX.
DirectX SDK has examples.
If you can handle it, switch to C# + Managed DirectX
since there are many more examples and books available.
Tom Miller is your hero.
#3
VB6 is a good programming language but not for games.
I have done few games in VB6 and they sucks (too slow).
Maybe if you are after 2D arena then you will have more luck then me but even 2D games (shooter) created with Game maker was better than same 2D shooter created with VB6.
Also I've had problems with correctly registering dll's and ocx with win98, no problem with XP.
Basicly what I want to say is this:
Don't waste time on creating Fast shooter in VB6.
Rather use C or C++
Even better use an existing engine....hint ;)
Anyway if you decide to work with VB after all, then check out www.pscode.com. They have few VB games(source code) that will get you going. And inform us (me) on your progress.... ;)
P.S. I did however created a terrible tetris clone that works perfectly in VB.
01/07/2005 (10:17 am)
There is some VB.NET games example at www.pscode.com VB6 is a good programming language but not for games.
I have done few games in VB6 and they sucks (too slow).
Maybe if you are after 2D arena then you will have more luck then me but even 2D games (shooter) created with Game maker was better than same 2D shooter created with VB6.
Also I've had problems with correctly registering dll's and ocx with win98, no problem with XP.
Basicly what I want to say is this:
Don't waste time on creating Fast shooter in VB6.
Rather use C or C++
Even better use an existing engine....hint ;)
Anyway if you decide to work with VB after all, then check out www.pscode.com. They have few VB games(source code) that will get you going. And inform us (me) on your progress.... ;)
P.S. I did however created a terrible tetris clone that works perfectly in VB.
#4
not so sure on your choice of VB though.. :O
01/08/2005 (5:12 am)
I vote wireframe gfx as being cool. its got nothing to do with using the technology just because its there. too many games look alike and not enough effort goes into people actually making something look unique. I say go for it, not everything should look realistic. ;)not so sure on your choice of VB though.. :O
#5
01/08/2005 (6:57 am)
Basically what I'm saying is I think it would be better to have polygons with faces. The look can still be unique or retro if you leave them untextured and make them rather low polly. Kinda like the 1st Virtua Fighter. I always thought of bare black backgrounds with colored lines for objects to be distracting and even a little confusing at times. Just my opinion.
#6
The rest of the idea sounds promising. You're after simple game mechanics that can be combined for varied strategies, fun and interesting gameplay. Good stuff.
01/10/2005 (3:05 am)
Solid, polished low poly semi cartoony graphics look good, run fast, are relatively easy to model and give a good feel to a game. Wireframe just makes things difficult and will turn most players away instantly. The rest of the idea sounds promising. You're after simple game mechanics that can be combined for varied strategies, fun and interesting gameplay. Good stuff.
Ajari Wilson
-Ajari-