View Full Version : looking for feedback

05-15-2001, 11:25 AM
hello. i'm working on a simple 3d game and have gotten to the point where I'm interested in trying it out on various systems for speed/compatibility tests.

it's only a couple megs and is located at: http://home.earthlink.net/~mvignol/barrel_patrol_3d.zip

please post system config (cpu + gfx card), FPS and whether it was fullscreen or windowed.

any other feedback is also welcomed.


-miles vignol

05-15-2001, 11:47 AM
Very nice. Stay away from my barrels damnit!

Windowed - 39fps avg
Full Screen - 59fps avg (though it got choppy every once in a while).

Athlon Classic 550 / Asus A7M
384meg Ram
Windows 2000/SP1
Primary GFX - NVidia GeForce256 SDR AGP

I like the scenery. Very pretty. http://www.opengl.org/discussion_boards/ubb/smile.gif


05-15-2001, 01:21 PM
This is a very good game indeed.

Test machine:
p2 233mhz RivaTNT2 196 133mhz RAM win2k

Running Fullscreen:

Peak 14 FPS
Average 12 FPS
Bottom 8 FPS
(It is NOT the GL stuff that drags down performance)

Must do's:
1. Add mouse controls the tankturret and let it aim, while keyboard does the normal chassie movement.

2. Change of scenery! More important than new weapons or powerups.


Increase missile speed abit.

Let the player battle through several waves of incoming tanks, each time they are stronger and faster.
Let the player advance to a new level after 10 waves and also change scenery at that time.
Dont let us get the homing missile to easilly, it is to powerful. Rather make it depletable.

Add more powerups, but be sparse, only one new powerup per level.
Add a scoreboard.
Add new types of enemies. (And weapons to defeat them with).


Dont improve more on the graphics, it rocks enough already.

If you just do the 'Must-do's' you will have an INSTANT HIT http://www.opengl.org/discussion_boards/ubb/smile.gif
I would play this against my brother day and night for a long long time.

I am already waiting for Barrel Patrol II http://www.opengl.org/discussion_boards/ubb/cool.gif
I think this is the ultimate way to develope a game.
Make a very simple game to start with, let people play it and give small suggestions.
Enhance the game from there, adding more and more of the desired features as you go along.

This way you will ALWAYS get a game people would WANT to play forever.

[This message has been edited by Hull (edited 05-15-2001).]

[This message has been edited by Hull (edited 05-15-2001).]

[This message has been edited by Hull (edited 05-15-2001).]

05-15-2001, 02:04 PM
If it's NOT the GL that's dragging down performance, then what is it? I'm hoping to keep Frame Rates near 50 or 60 FPS.

Thanks for the other input as well, right now the enemy tanks slowly get faster and faster. I'm looking at adding stages to the game to give a sense of completion. Also I'd love to have different enemies (movement rates, ammo types, AI are all flexible at the moment, but I haven't gotten around to any scripting or additional models.)

The guts of the game are also semi-networkable, but not entirely. Originally, the game was supposed to be like the old vector game 'Rip Off' which was a 2 player cooperative game. But I don't really know of a good approach to network game play...

05-15-2001, 02:17 PM
I was getting some 30+ FPS windowed on my P3-700 with GeForce SDR. I was too busy with the game to note the numbers http://www.opengl.org/discussion_boards/ubb/wink.gif

It's quite an addictive game. Here are my comments:

I hate it when I a tank shoots me and I die, and then before I can rotate and get at him I get shot again. This can happen several time in succession. Old arcade games used to deal with this by giving the player's tank a few second of invulnerability.

I was disappointed that shooting didn't harm the barrels in any way. I could shoot right through them.

I disagree with hull about missile speed. It was fine for me.

I agree with him about the waves. I would be nicer if there was some sense of accomplishment mid-way. You could also look into having different configurations of barells for different levels, and different goals. For example, having barells at the two ends of the compound, and having to keep them both for a couple of minutes.

In general, I felt that the game was a little too easy. Perhaps it's just too many barrels at the beginning. Makes it take a whole of a lot of time to start feeling a threat to them.

05-15-2001, 04:08 PM
Maybe the missile speeds are fps dependant?

Are they?

Hey! You didnt tell us about the 2D version!!!

I liked this one more actually, because it ran faster.

[This message has been edited by Hull (edited 05-15-2001).]

05-15-2001, 07:42 PM

Wow, neat game! I think there should be more simple, addictively fun games like that around. That said, let's get on to the nitpicking http://www.opengl.org/discussion_boards/ubb/wink.gif

You should definitely make the playing speed frame-rate independent. I was getting about 140-170 fps and my tank rotated too quickly to aim accurately...one press of the arrow key seemed to turn me about 1/8 to 1/4 of a circle. My system is a PIII-450 with GF3 on W2k. As fast as this game went on my machine, it's strange that the others aren't doing closer to this...do you use any extensions?

Like ET3D said, it's very frustrating when you just get shot, then get shot again before you're oriented. Go with a 1-2 second invincibility.

To answer Hull's question, I'm guessing that the missiles are frame rate dependent...they were quite fast on mine.

Let us know if you come out with a newer version.

-- Zeno

05-16-2001, 04:36 AM
Works on my reference NVIDIA Quadro on Windows 98.

Driver build is

Bios Version
Get's about 80 fps.

05-16-2001, 04:52 AM
Oops, I had sync to vertical retrace on by default, this waits on monitor retrace before swapping buffers to avoid tearing. I actually get 110 to 180 fps with this off.

As others have said, you need to use a high resolution timer to multiply all the velocities by the time between frames to give a consistent game dynamic. The game varies a LOT depending on frame rate.

So compute delta time, and say x += vx * dtime. Instead of x += vx.

Here's some windows code I wrote to compute delta time, it looks for a high res timer and tries to use it if it's there. It's been a while since I looked at this. The high res timer is probably always there these days. It also optionally low passes the results to try and smooth things out.


// option to low pas high res timer

// Compute elapsed time since last call (call once per frame)
float DeltaTime()
static int first = 1;
static int count;
static BOOL HighRes;
static DWORD this_time, old_time, oelapsed, elapsed[20];
static float this_timef, old_timef, oelapsedf, elapsedf[3], resolutionf;

first = 0;
// test for high res timer and get resolution in milliseconds
HighRes = QueryPerformanceFrequency(&pcount);
resolutionf = pcount.LowPart/1000.0f;

// init low pass array to 60 Hz assumption
for(count = 0; count < 3; count++)
oelapsedf = elapsedf[count] = 16.667f;

old_timef = (float) pcount.LowPart;
old_timef /= resolutionf;
// init low pass array to 60 Hz assumption
for(count = 0; count < 20; count++)
oelapsed = elapsed[count] = 16;
// init time to current value
old_time = GetTickCount();

count = 0;
return 16.667f;
// Use High Res Timer to compute elapsed time in ms
// low pas to eliminate any jitter is optional
this_timef = (float) pcount.LowPart;
this_timef /= resolutionf;
// stick with old elapsed if loopback detected
if(!(this_timef < old_timef))
oelapsedf = elapsedf[count] = this_timef - old_timef;
elapsedf[count] = oelapsedf;

old_timef = this_timef;
#ifdef LOW_PASS_HIGH_RES // option to low pas high res timer
count ++;
if(count == 3)
count = 0;

return (elapsedf[0] + elapsedf[1] + elapsedf[2]) *.3333333f;
return (elapsedf[0]);
// Use Low res timer to compute elapsed returns ms
// Must low pass over several frames since timer
// res may be much < 1 ms
this_time = GetTickCount();

// stick with old elapsed if loopback detected
if(!(this_time < old_time))
oelapsed = elapsed[count] = this_time - old_time;
elapsed[count] = oelapsed;
count ++;
if(count == 20)
count = 0;
old_time = this_time;
return (elapsed[0] + elapsed[1] + elapsed[2] + elapsed[3] + elapsed[4] +
elapsed[5] + elapsed[6] + elapsed[7] + elapsed[8] + elapsed[9] +
elapsed[10] + elapsed[11] + elapsed[12] + elapsed[13] + elapsed[14] +
elapsed[15] + elapsed[16] + elapsed[17] + elapsed[18] + elapsed[19]) *.05f;

05-16-2001, 06:40 AM
Hey, very nice! I also like the 2D version better, simply because I *do* remember the game Ripoff, and loved it!

Anyway, in 3D mode, I get:
70-80 fps on a P2 450, GeForce2 MX, fullscreen
40 fps windowed


05-16-2001, 09:19 AM
Thanks for all the feedback! My original idea for getting a constant game speed was to find a FPS value that seemed to work and then either sleep if the game was faster or skip draw if it was slower, but maybe I'll go ahead with the other method of a variable time-frame.

Why do people like the 2D version better? Is it because it's top-down or smoother or what?

And no, I'm not using any extensions, but I am developing on a GF2 MX, so it's not too surprising that the nVidia cards seem to fair a little better.

[This message has been edited by mv (edited 05-16-2001).]

05-16-2001, 09:37 AM
This is the result of a great misconception of the gaming industry today, that better and more flashy graphics makes games more desireable to the consumers.

Sure it looks great on the outside, and it will probably sell well because of that wrapping, but its the inside that counts in the long run.

Its not the graphics we like, ITS THE GAME ITSELF.
I think thats why we like the 2D version better, because then the focus is more on the game itself, not on the visuals.

This is an important lesson the be learned:

Better games != better graphics.

I still think about some C64 games as 'superior' to many of todays blockbusters, because the games where more fun to play.

A good game could be like reading a very good book.
It leaves some visualization to the players instead of trying to force someones conceptions upon them. Let the players focus more on actual gameplay.

[This message has been edited by Hull (edited 05-16-2001).]

05-16-2001, 10:54 AM
It's my intention to add a top-view camera option a'la the 2D version, so maybe that'll affect things. Also a radar display for orientation purposes.

Honestly, tho, this has really been an exercise for my own purposes. I'm just learning windows progamming and openGL, so I figured I'd try to incorporate as many things as possible...

05-16-2001, 11:04 AM
Edit: mv, while I was writing my message, you posted exactly the suggestions I made. Nice. I'll keep the following here anyway.

I think you hit the nail right on the head. I, too, like the 2D game better, and it's because it's overhead and faster. The reason is, it gives me more control. I can see the threats and I can avoid them, which makes the game more intense and less frustrating.

The best example is with the tanks that shoot at you. In the 3D game, you have to keep looking out for them. In the 2D game, you see them immediately. In the 2D game, it's easy to avoid the shots, by moving at 90 degrees to them. In the 3D game you can't, because then you don't see them. In the 2D game, when you die and reappear, you immediately know where you are, and know what threats there are in the area, and how long it will be before they become real threats (such as tanks that are rotating towards you). In the 3D game it takes time to orient yourself.

These things, and others, make the 2D game more engrossing and less frustrating. It's not any easier - in fact, I think it's more difficult - but it allows you to use a little more tactical thinking, since you can see everything that's happening, and that's more fun.

I disagree with hull about the flash. The game would have been better in 2D even if you gave flash there a lot more attention. In fact, I'd have loved to see a better looking 2D version - something like the 3D version with an overhead view (not exactly overhead, probably).

The problem isn't flash vs. content, since the content is the same, it's just that a game that works in overhead view doesn't necessarily work the same in first person view. This could probably be rectified to a large extent by overlaying a "radar" of the entire scene over the 3D visuals, although I'd still think that a flashier 2D version is the way to go. Kind of like what Hasbro did to Pong - I loved that.

[This message has been edited by ET3D (edited 05-16-2001).]

05-16-2001, 11:19 AM
The problem with the overview of the battlefield in 3D could be fixed by implementing one of the must do's of my previous post:
Let the turret (Camera view) be controlled by the mouse, and let movement be controlled by the chassi.

This way you will be able to swiftly look around without actually changing movedirection. The turret rotation could be 'instant' to avoid frustration.
A small radar could also be implemented, but that is not a must.

Damn, I got myself addicted to it now http://www.opengl.org/discussion_boards/ubb/smile.gif

05-16-2001, 02:27 PM
I'm glad you enjoy it. Honestly, the game as it stand is more a tech test. That's why I let it free run rather than lock to a particular FPS. I've decided that the elapsed time modifying the update 'amount' is the better way to go, so I'm going to start implementing that.

Thanks, everybody, for the feedback. I hope to have a 'real' version soon.

05-30-2001, 11:27 AM
Anything new? Just wondering...

05-30-2001, 11:49 AM
Funny you should ask. I'm just now finishing up a new release.

I'm debating whether or not to add the notion of levels/stages at this time or to release it as is and add them later.

05-30-2001, 05:05 PM
What a great game, I think the radar would
help the game, and possibly a button for percise movement. The worst problem is that the game is frame rate dependant making it impossible to control sometimes. Maybe doing some work for AI difficulty and increasing it based on time would be wise. Otherwise Good job and good luck.

05-30-2001, 05:08 PM
oh ya,

I run a GeForce 3 and TBird 800 win2k.

05-30-2001, 08:06 PM
Nice one!

PIII 933
192mb SDR(pc133)
GeForce2 MX (Det 12.22)
Win2K pro.
~74 FPS @ 800x600x16 (windowed)

[This message has been edited by richardve (edited 05-30-2001).]