I decided to take a break from physics stuff, and try to finish my first something!

So I've got this little arcade game here... It'd be real cool if I could get some information from people who wouldn't try to sugar-coat things.

I'd be much obliged if you'd submit one or more of the following, if the mood so moves you:

1. FPS [hold F1 (capped at 100)] and system specs. (CPU speed and RAM's all I really need to worry about, being that there's no hardware acceleration, and no external files to access, right?)

2. Any bugs you've experienced?

3. Any other...general comments or advice.

WASD and mouse.

Thanks in advance.

{"name":"594929","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/6\/76a7697f7884dcd3c954d3efd4804ad6.jpg","w":800,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/6\/76a7697f7884dcd3c954d3efd4804ad6"}

[edit] Attached screenshot.
[edit2] Extended window size to 800x800, tweaked difficulty and used alternate method to show player health...it's much better. Attached new version.
[edit3] Updated attached exe: if some dimension of your desktop is less than 800, the game plays fullscreen at desktop resolution.
[edit4] Attached source code.
[edit5] Attached new version 1.0.1 and source!

Post screen-shots!

Some comments:

1. My frame-rate ranged from 47-54 depending on the amount of on-screen action. My CPU is AMD Athlon 64 X2 3800+, 3 GB RAM. Amusingly, the CPU usage was low throughout...

2. Didn't seem to see any bugs.

3. A couple of issues:

-The playing field felt a little cramped... Even my best runs failed to go more than a minute or two before I was overwhelmed. It wasn't because it was difficult in the sense that I couldn't kill the enemies fast enough, but in the sense that there wasn't any place to dodge towards the end.

-The player health indicator could benefit from being more visible. The enemies' health ranges from white to red, while the player's ranges from black to white... I feel like I could tell the enemies' health with much greater ease.

-Once you get to it, you may want to get a bigger font for the in-game text

-And some general stuff I am sure you are aware of, like the lack of a top score table, lack of a restart button.

-On a positive note, I feel that the shaking works really well. I also enjoyed the lighting effects.

1. That's real weird... I'm running with an AMD Athlon 64 3200+ at ~2 GHz with just 1 GB RAM, and I can't do much to get it to flicker under 100fps... ...?

2. Cool!

3. a. The playing field is most definitely cramped... But I wanted the main difficulty here to be keeping your head on straight as long as possible, with things going crazy everywhere. I'm trying to find a balance between easy beginning / frantic ending (or...frantic 'after your gun is more powerful, when enemies are killed by a single bullet'-time...).

b. Agreed... I'm trying to find ways to have as little information directly presented to the player as possible...trying to have things be intuitive... I was happy with how the enemy health thing turned out, but I don't think it works as well with the player, seeing as how the health is reduced much more gradually, over a longer period of time.

c. I'm actually aiming for as little text/HUD as possible... one of the main things I was hoping to learn by asking here is whether or not it would be okay to remove the gun level and kill-o-meter from the bottom of the screen.

d. Yeah, it really would be nice to have a restart button, but I don't think I want a top score table... I like the idea of having a single executable that doesn't require anything else to run, or leave anything behind when it's done... So unless there'd be some magical way to record it into the exe...?

e. Glad you liked the shaking and lighting!
[edit] And I think of the 'lighting' as more of a...proto-retro-RGB disco floor going on under the action... Or something...

1) I got a constant 100 fps on an Intel Core Duo E6550 (2.33Ghz) with 3Gb of RAM.

2) No bugs.

3) Definitely too cramped. Half of the enemies hit me before I even realized they were on the screen (though I admit I have terrible reaction times).

The effects were nice, and the game was nice to play. Just too difficult for me.

I only looked at them after the game was over, so it wouldn't have bothered me if they hadn't been there.

I tested it under Vista, which may or may not have affected the frame rate.

Can you post the source please?

Nice game, but crashes when too small resolution is set. I have 1280x800 resolution on my laptop, so obviously the 800x800 window can't be set. So you should at least let the user know, that he/she should change the desktop resolution or something.

I needed to run this game on secondary monitor.

It doesn't work here, appears and disappears very quickly, I have no idea what's wrong

Specs: P4 2400MHz, FX5700LE, WinXP.

Same problem for me too

Opens window, then disapears to task bar, then crashes.

Specs are Pentium 4 3200MHz, 2 Gig RAM, nVidia 6800GT.

So then I have to ask Paul and ri99ers, is your resolution 800 or lower in some dimension?

(I'm gunna fix that real quick.) Fixed! ...I hope...

Eeeeeeeeeehhhhhhhhhhhhh I'm a tad embarrassed. Not that the code I write is particularly ugly, but I pulled this thing out of my ass over a couple days (except for what SiegeLord helped me with), and so things may not make sense, or may have been done stupidly...to some extraordinary extent.

Oooooo... Yeah, XP Pro here... I wonder why it's slowed on Vista...

It's very important to move around! Enemies are spawned off-screen at some random distance from the player. Each tick they find a new 'desired_rot' by targeting the player, and if they're not facing the target, they adjust their 'rot' by their 'rot_speed'... Anyways, each tick that they have to spend turning, their speed is decreased, to a minimum of 1. But each turn that they're on target, their speed increases. Sooo... If you don't move around at least a little, enemies have a chance of getting up some high speed before they're on-screen.

Or I should just decrease 'max_speed' for the enemies? I thought it was much more manageable this time around.

I don't ask because I plan to read it, it's just that I can't run Windows binaries.
But if you don't want to release the source that's your decision.

Attached source code to original post.

Because it's Vista.

Vista is resource hungry... MS thinks that if you have all this power in your PC than they should be using to make there OS look better. I could care less about the shiny and transparent windows. Just make the damn thing work M$, and let my applications use the system resources.

Nice game.

This actually made things worse for me, as it meant I had to focus on the keyboard as well, which further lessened my chances of seeing enemies coming.

This won't affect most people, since most people can use up to four keys without gettng cvonfused. There are some people like me however who are totally uncoordinated, so if you want the game to appeal to a wider audience, you might want to make it start slow and easy and then get harder.

I've never had a single performance problem with Vista.

Maybe more driver related ?

Yeeeah I don't really know if WASD + mouse is the best control scheme for this, but I generally seem to assume that it's the best way to control anything, just because I spend so much time playing first-person-shooters, and I'm so comfortable with it.

Speaking of first-person-shooters, a friend of mine switched from XP Pro SP2 to Vista, and his FPS in Quake III: Arena dropped from a steady 333 down to ~170. If I remember right, his FPS in UT2k4 also dropped about 20%.

Would drivers be an issue with software rendering like this?

I tried the game from the source posted at the top. I don't get how to play, but probably something is missing from the game. In the game I could move the small circle with the mouse and the big blue blob with WASD, and left-clicking made the blue blob spit out white bullets but thats about all I could do. One time I saw the blue blob shoot out a green thing like in the screenshot above but I couldn't figure out how to do it again.

Anyway I got 32fps.

1) 19-27fps. P3 600Mhz, 392Mb RAM but I would get the same speed with 128. The bottleneck here is the speed at which the image can be sent to the video card, and the AGP 1.0 (2x) port of my motherboard sets the limit.

2) no bugs

3) Basic game. I like the precise player control.

I get 25fps, and I have the blue blob.
WSAD make it move. Mouse makes it randomly shoot shrapnel.
Occasionally the blue blob grows.
I have no idea how to get enemies.

EDIT:
Also, there is a number at the top, padded with 0's at the left, which appears to represent the shrapnel count.
Occasionally, shrapnel appears from the sides of the window.

EDIT2:
A green thing just appeared. It seems that holding the mouse button for long enough produces random green things.

The things you guys are describing are really weird... Are you building in Linux too, kazzmir? All the source files are definitely there, maybe some platform issues?

The number at the top of the screen is the player's score. 'Shrapnel' is created every time something is destroyed. For bullets, this is when they collide with an enemy or a wall (edge of the screen), and for enemies and the player, it's only when they run out of health. The 'pixelated' (and colored) background turns blue when near the player, red when near an enemy, and green when near a bullet. After a bit, I decided to comment out the bullet-drawing function, and so you should be left with just 'greens things' whenever you shoot.

Would bullets be the green things?
They seemed to come out randomly. Most of the time the grey shrapnel stuff came out in random directions, but occasionally some green things came out.

EDIT:
I just loaded it up again and the green bullets don't appear at all now.
Are there any special switches I need to pass to the compiler?
I compiled with:
g++ -o yeah *.cpp `allegro-config --libs`

Yeah because allegro sometimes (when possible in fact) use hardware accelerated thing like blit, clear, ....

If your drivers are in a total mess, ...

Hmmmm... The bullets are indeed green things, but the fact that random shrapnel shoots out of the player when you fire (assuming I'm understanding the situation) tells me that the bullets are running their destruction function as soon as they're created... Not even just some vector glitch, with accidental deletions, they have to actually be running, deciding they should be destroyed, creating an 'explosion' of shrapnel and then deleting themselves from the vector.

Normally, this'd only happen when their 'destroy' bool is set to true, but that should only happen when they either leave the screen, or collide with an enemy...

Unless assuming bools as false on declaration is bad...?

If that's the case, you might want to try actually opening up my radioactive code, and adding 'destroy = false;' to the constructors of cBullet and cEnemy. It's the first function in each of their .cpp files, if I remember right...

When you declare something, never assume it to have a value.
Some kernels waste time zeroing data, some kernels let you have whatever was in the memory last. I'll take a look at the code now.

EDIT:
That worked!
I'm going to play it for a bit before posting my thoughts.

EDIT2:
- I think there is a bug in the enemy highlighting code. A lot of the time they didn't have red 'pixels' behind them, and sometimes a triangle in the bottom right was filled red.
- The game is almost impossible to play. Either the player and enemies should be slower, the playing space should be larger, or the player and enemies should be smaller, in my opinion. It's not that I like playing easy games, it's just that there is no way you can play the game like it is. I know you're trying to make it that you have to keep your head when it's all madness, but there's no time for keeping your head because by the time you see the enemies they're on you.
- It just froze when I died. A message saying 'GAME OVER. Press ESC to quit' would be a bit nicer.

On the other hand, I thought it was a very interesting concept. If it was a bit easier to play it could be a great game.
Another thing I'd suggest, if you plan to spend some time on it, is to get graphics (programmer graphics aren't good - if you can't draw, leave them how they are). Also, different types of enemy would be nice. The game could choose enemies based on how many points you've got. Congratulations on the game, though. I think it's pretty good.

EDIT3:
After playing it a bit more, it gets easier. A larger playing area would be nice, but by no means necessary, having played it a bit more.
Power ups would also be nice. For example, when the player gets low on health, it is obvious that he is going to die soon. It'd be nice if there was the possibility of a restore health power up. Also, temporary gun improvement power ups could work.
Every time I play your game, my opinion of it improves.

I'll just throw in a small comment.

Global variables are guaranteed to be 0. Everything else( locals, class variables, etc ) are not.

Glad you got it to work!

Oooooooh yeah. The player 'lighting' thing was no problem, but with the bullets and the enemies, it was rough... Each of the background's 'pixels'(not really) has to find its red/green value based its the average distance to every enemy/bullet(respectively)... I never really got it to work quite right, but it's tolerable most of the time.

Yeah...I really do need to get around to putting in a restart button... Soon!

Actually, I like it the way it is... I wasn't driven to these graphics by lack of artistic skill (though believe me, I'm plenty lacking), I just like the semi-retro look, with the basic squares and circles, pixelated explosions and the RGB-dancefloor thing... (plus the circular enemies and player made collision detection a breeze)

If I was going to add more 'graphics'(enemies, power-ups, whatever...) I would probably make a blank bitmap in-code, draw primitives to it with some function for drawing each thing, and display that as...whatever it was. But I'm kinda avoiding that until I can figure out the whole polygon-on-polygon collision thing (for checking rotated bounding-boxes). It'd be great if someone could help me out with that.

Yeah, the health thing is a good idea, but I think the gun powerup would require a more...'intrusive' way of displaying the gun power to the player. And the only reason I haven't added that health power-up is because I was thinking of this as the sorta game you sit and play over and over, trying to beat your old score. (I'm pretty sure I'm going to replace the score at the top with a timer...make it into a 'survive as long as possible' thing. Any tips on displaying properly formatted time, as accurately as possible? )

I actually like the game very much. I find myself coming to this thread every time I am on the forum and playing it.

Its a really good concept, there are some flaws, like the others mentioned, so I will not write them here. Just fix those things and this game will be even more enjoyable.

Just to let you know that you have a great game/idea here. Just keep working on it.

New version! I've made enough changes now that I'm bumping this project from version 1.0.beta to 1.0.1!

New version has a classy 'You died. Restart?' screen, and uses a timer rather than a point system. It also keeps track of the best time. Yeah!

Added new w1nd0z3 binary and the new source.

I see the latest version hasn't got the bullet/enemy bug fixed.

Yeah...but just cause it's not so much of a 'bug' as it is... 'something I don't know how to do better', so I just hacked something together that works most of the time. I'm thinking it might be worse in Linux than in Windows, because it doesn't really visibly glitch very often for me...maybe once (for a half-second or so) every two or three dozen times I play.

I'm certainly open to suggestions here.

[edit] Oh wait...did you mean the bug with colors, or the bools? (bools fixed now...ehehe...)

I meant the bools thing.

I am using linux on a p3 863mhz, 128meg ram, GeForce FX 5700LE, just before running it 43meg is free, and 90% of the cpu is idle. (to give an idea of resources available, will check in a moment without firefox running, if there is much difference in game performance I will edit my post)

I get 3fps, then 0fps, well nothing happens for a few seconds when there are lots of shrapnel on the screen, basically every time an enemy dies.

Specifying the GFX_FBCON driver, I got 16fps out of the game and no pauses, I could actually play it, I like the game, I have no idea what the driver it defaults to though.

Huh...what distro are you running?

(And it would be awesome if someone running the same distro could let me know if this happens to them too.)

I use a debian base install, then used aptitude for xorg and fluxbox, then various other programs as I needed them (http://www.go2linux.org/installing-a-light-linux-operating-system-debian-fluxbox I sort of followed this, but went with my favorite programs, rather than their suggestions.)

Well...if I was going to take a stab in the dark, I'd say fluxbox might be a problem? But only because I don't know many people who use it... I really don't have much useful to say... Glad you knew how to fix it!

Its a window manager as opposed as a desktop, I can run the program without any windows manager.

Just to see, I replaced the contents of .xinitrc with "~/yeah/yeah" and started x. I got exactly the same fps and everything.

As for how many people use it, I don't have a clue, but at a guess I would say quite a few.

http://popcon.debian.org/main/x11/by_inst here is the current results for debians popularity contest of x11 packages.

It came in at 170, there is a couple windows managers that are above it, from my understanding 3349 have installed it on debian in the last month and 1205 use it regularly. I don't know how many people have the popularity contest stuff turned on, I don't, its just another thing that would slow this poor machine down and its mainly used on low end machines (IMHO or people that want a desktop to slow their "super" computers down), so lots of people might have thought the same way and skewed the results.

Huh... I always thought Fluxbox was a desktop environment, like KDE or GNOME... Dunno what to say then!

Game run fines

needs:

Fonts

as i mover faster it becomes harder to see the mouse pointer. i guess that is some thing that can be trained but, you could give small breaks so you can get your self back focused for earlier levels.

you need text to say press 'R' to reset.

also i like to use arrows keys to move for this type of game because it is already programed in my brain how the arrow keys work and where that are.

It is not to cramped because the trick is timing.
Notice there are time points of homeing and actcelaration for the bad dots.

they home what then enter 1 and the home on attack 2 once you get the timing its easy to doge them but, its a good thing the don't bounce off the walls or you would be in deep dodo then.

EDIT: you could make a radar for those that think it to much for them

...nah...thanks though.

I just think it'd be a little awkward to have 'breaks' in a game that reaches its peak difficulty after a minute and forty seconds.

...huh? Such text does, indeed, exist.

WASD works just like the arrows, but is on the other side of the keyboard. I find it awkward to use the arrows and mouse at the same time, having both arms skewed to the right across the keyboard while facing the monitor. Even so, it can't hurt.

When that was posted the screen size was 600 by 600, and looking at it now, it was way cramped...

You are assuming things instead of being sure of them. Don't assume, give them all a value at init !

Don't forget left handed people. They have to skew to use WASD.

I'm left handed and I don't skew to use WASD.
Then again, I use the mouse with my right hand

One thing: while dead the time counter do not stop to grow.

It means that I can shit my score the following way:

Dead the quickest I can
Wait 2 minute
Press the restart key.

My last best time won't be me lifetime, but my whole playtime.

I was dubious too (hence my "huh?" smiley) but since then I've searched for the info, and the C99 standard specifies that all uninitialized static data is zeroed at program startup:
http://c0x.coding-guidelines.com/6.7.8.html
section 1653 onwards

I'm actually left-handed.
It's certainly no problem for me.

Yeah...I fixed that in the version I'm going to put on my Depot project page. (if it ever gets approved)

I wasn't going to put this thing up in the Depot, but I looked at some other stuff in there, and I think this'll fit just fine...

The reason is that globals are stored in the .bss section of the executable which the OS will zero out when it loads the program. Globals that are initialized with a value are stored in the .data section.

Heh, when programming on Windows, never trust a standard is rule #2 ;-p (It's a joke/sarcasm/whatever, for those lazy geeks who think I am mad)