Guns, Action, Mayhem, Etc.

[Gerix]

Hey there. I know it's a glorious day/wonderful evening, but if you find yourself with some spare time, I would appreciate it if you would check out my game. Before I begin, I want to point out there is not a Pandora port yet. I still need to convert the OpenGL code to OpenGL ES. Anyway, I wanted to make a game that took advantage of the Pandora's gaming controls. The original idea for this version of the game was to have two fully configurable turrets, but then I thought it might be too hard to balance all the choices, so I thought maybe having an autocannon on the left side of the controller and rockets on the right side of the controller. But I thought it might be too much for the player. The current idea is to have the left side of the controller be responsible for direct fires and the right side be indirect, but the right side isn't programmed yet. I bumped my old topic on gp32x, but I figured some people don't check there.





Edit: I'm sorry. Controls: Pretty simple at the moment. If a joystick is detected, the first two axes will be used for the aiming angle and button 5 will be used for firing. It may take a little bit of experimentation to discover which button is mapped at index 4. If no joystick is detected, the mouse is used. Point and click. In my rush to get this out there, I haven't tested use of mouse in the turret class too much, so there's a good chance it's buggy.

 

[vadsamoht]

What are the controls? I can only seem to shoot in one direction.


From what limited amount I've seen, the game looks good, though the main menu could use a little work (resizing the grey boxes that appear behind the menu items).

 

[Gerix]

Yes, I'm sorry. Those are things I forgot to mention. If the game detects a gamepad, then the first and second axes form the look control. The angle you tilt is the angle the player aims. Currently, I just have it set up to fire on index 4 of the first gamepad detected. On mine, that's L1, but it might be different depending on your layout. I need to set up something in the menu to allow the controls to be customizable. If no gamepad is detected, the game defaults to mouse, but I just added it last night and haven't really tested it. Just mouse over to the enemy and left click (assuming it works ok).


Agreed on the menu. It's on my to do list.


By the way, thank you for the feedback.

 

[vadsamoht]

I'm playing with a mouse, as I have no (useable) gamepad. I'm not getting a pointer/cursor, however.

 

[Gerix]

Ok, I'm getting that too. I'm working on it right now.

 

[vadsamoht]

Also, what kind of comments are you looking for? Just general bugs, etc., or do you want suggestions on the game design?

 

[Gerix]

Ok, I think I solved the mouse problem. It had something to do with the joystick and mouse code not playing nice. I'll upload a new version as soon as possible.


And I would be interested in any comments. Pointing out bugs, suggestions on game design, even programming tips.


Edit: New version uploaded. Sorry about that.

 

[vadsamoht]

OK, played the new version, mouse appears fine. I'm having a problem where I defeat a certain number of enemies, and then it just doesn't send any more at me. Is it supposed to be advancing to a new level at this point, or is this just a proof of concept?


Also, what are you planning to use as the controls on the Pandora? You'll need to disable touch-screen input, or it will just become a test of how quickly you can click on different things. I had an idea for a design rewrite that implements the screen instead of the nubs, but it would be vastly different and I think the current version could work fine as-is. You'll want to tweak the nub sensitivity to get the difficulty right, though.

 

[vadsamoht]

Also, I've found that when you run out of ammo, you can just click the mouse button again and it reloads completely. My suggestion would be to either have a limited amount of ammo per level (thereby increasing the difficulty) or having the ammo gauge deplete a lot faster, forcing the player to time his reloads against the waves of enemies (and in this case being able to reload partway through the gauge would be good too).

 

[Gerix]

There is a finite number of enemies at the moment. If you open the file games/DoM/map/testmap/spn in a text editor, you'll see a list of numbers. 1 stands for grunts, 2 stands for tanks, 3 stands for jeeps, and -1 prematurely ends the wave. Don't put zero, as that's the player and won't do anything constructive. I haven't programmed any levels yet, but would like to in the future.


I haven't given a lot of thought to how to best implement the controls on the Pandora recently. The original plan was to have the left nub control one turret, the right nub control a second turret, and the touchscreen calling in artillery fire and airstrikes, or maybe operating the store in "panic mode." However, I'm thinking that would be too much activity for the average gamer, so I don't know.


I don't know why I haven't implemented a manual reload for the turret yet. It's in a class for a different incarnation of the game. I'll just have to migrate the logic over to the new class.

Spoiler

If you're not averse to compiling the code, you could change line ~54 in source/GameStates/PlayState/PlayState.cpp from

playerOne->SetInstructions(&AI_Turret);

to

playerOne->SetInstructions(&AI_PlayerOne);

then run make (but be sure the right CXXFLAGS variable is uncommented)(also, the compile scripts are included, but I haven't used them in a while. They almost certainly don't work). Anyway, I think the instruction set is the only thing between games that is different as far as the code is concerned. So changing that one line changes the game from a turret shooter to a standard shooter (but again, I haven't used that class in a while, so code elsewhere may have broken it, so this entire suggestion is purely for entertainment value). If people are interested in this, I could add the "Zombies" pack back to the release (Actually, I should find a way to have all this stuff be changed in config files. I wish I had more time for these things).


Controls when using AI_PlayerOne:


WASD: Movement


R: Reload


Mouse: Aiming

I was having trouble finding time to mention this (I've been busy working on stuff tonight), but most of the configuration files in games/DoM/ are configurable. The excessive ammo was left over from me trying a loadout that featured a high rate-of-fire gun with weak projectiles. If you would like to try the game by tweaking the settings, you are more than welcome to. If you go into the guns directory, TestGun.txt holds the information for the player's gun and TestProjectile.txt controls the properties of the projectiles it fires.


Gun Markup

Spoiler

<gun> tells the game you want to use the vanilla gun class. This can be replaced with <shotgun> to get a shotgun. If you're using a shotgun, follow the shotgun tag with <pellets>x</pellets> where x is the desired number of pellets.


<auto /> tells the game you want an automatic weapon.


<magazine> gives the magazine size


<accuracy> gives the accuracy variance. I can't remember offhand what the units are (some fraction of degrees, I think), but an accuracy of zero is perfect.


<reload> is the time necessary to reload, in game ticks, I believe


<cooldown> is the number of game ticks before the gun is available to shoot again.


I'm pretty sure <speed> is the speed transferred to finite-speed projectiles. It would be best not to mess with this element.


<sound> is the sound index from the index.txt in the sounds folder.


<projectile> points to a projectile in the guns folder, and provides additional information (I think I implemented it this way thinking forward, like someday FMJ vs. Hollow Points, or different types of grenades/rockets).

Projectile Markup

Spoiler

<projectile> tells the game we want a finite-speed projectile. This can be replaced with <instantprojectile> for a projectile that runs its entire path in the first game tick (I prefer it for bullets).


<time> gives the amount of clicks a finite-speed projectile has to find its target before self-destructing. It gives the tracer life of an instantaneous projectile.


<damage> gives the projectile's damage.

There's also markup for the players and map, but I have to work tomorrow and it's almost 2 o'clock. I'll have to post them some other time. I haven't really played too much with those files, apart from getting them working. But everything should be laid out pretty well. With the proper setup could the turret be found guarding the thermal exhaust port of a planet-destroying space station? I certainly hope so.


Thanks for the input. It makes me go "why couldn't I think of that?" But hopefully, I can put some serious work into this game and add some new features. I want to make an enemy that hangs back and shells the city instead of occupying. I should probably make some art that suggests the player is actually guarding a base/city/whatever.

 

[vadsamoht]

OK, I've had a bit of a play with the settings, and I've found the following pretty balanced:

TestGun.txt


<gun>

	<auto />

	<magazine>25</magazine>

	<accuracy>5</accuracy>

	<reload>30</reload>

	<cooldown>3</cooldown>

	<speed>30</speed>

	<sound>0</sound>

	<projectile>TestProjectile.txt</projectile>

</gun>

This makes jeeps very difficult to destroy, and you will often have have to reload while firing at another tank, so if you want it to be a little easier then change magazine to ~30.


I've also noticed that if you die, the game over you are presented with screen does nothing. Worse, if you press enter you get an error in the program that makes windows insist on closing it.


I've also thought about the controls a little more. If you use say the left nub to control the turret, then perhaps you could use the shoulder buttons to use your specials on the location where you have your cursor at that time (e.g. one for an air-strike which is AI targeted to enemies, and the other for an artillery strike that hits exaclty the area you select). The reason I think that this will work is that we can assume that the players would only call in these strikes when they are in trouble, and this gives the player the choice of either continuing their attack or taking a penalty (the time penalty of relocating their cursor) in order to call in the specials.


Finally, and this is a bit more of a long-term thing: In thinking about how this game will function as a finished product, I don't think that merely advancing from one level to the next is enough of a reward for the player (though this will certainly be necessary), but perhaps including a scoring system could remedy this. I had in mind something along the lines of X points for each infantry, Y for tanks and Z for jeeps, ~1/2 normal points for units killed using specials, and -1 point for each shot that does not hit anything. Though this will almost certainly have to change to balance things later, but you see what I'm getting at.


Also, I just want to say that this game is better than anything I could do at the moment. If it ever sounds like I'm being overly critical it's because I want to help you make this game as good as possible.

 

[Gerix]

Sorry about the game over screen. It used to work. Enter was supposed to reload the game and Escape was supposed to exit. I'm guessing something is getting loaded twice when it shouldn't. I'll check it out.


Actually, I was thinking the airstrike would be a wall of napalm and artillery would be a short duration shelling of a specified area, but I like the idea of specifically targeting enemies.


Also, a scoring system would be nice. I guess I haven't even considered it, as the text class is relatively new. But it's definitely something that could be added.


And I appreciate the feedback. It's very constructive.

 

[Gerix]

Bump: New version (0.1.1) available. The big change is the addition of a (primitive) scoreboard. Right now, it only tracks damage dealt/received and score (only from kills right now, but I think I left it open to work with other game modes, if they ever get programmed). No penalties for missing or using specials (the latter for obvious reasons). Also, the board is only configured to show the player's score, not damage dealt/received (also, I didn't even bother registering the other units with the scoreboard).


Also, I changed some of the initialization in the SpawnEngine. Before we were talking about bringing the number of bullets down to fit with the enemies on screen. But really, I think the way I want to go is bring the enemies on screen up to fit with the number of bullets.


I tried to recreate the error with the game crashing on the game over screen, but I couldn't do it. Although at one point while I was working this week, I did have a problem where the code was breaking where it shouldn't. I removed all the object files and ran make from scratch. That seemed to fix it. I'm hoping that's what was wrong with the game over screen. If the problem is still there, I'd appreciate knowing about it.

 

[vadsamoht]

OK, tried the new version - nat having any problems with the Game Over screen, probably something at my end.


I'm finding that with the new system, there are too many enemies to combat effectively, even with a stylus (I have a graphics tablet on my PC)


Also, you might want to reduce the HP of the jeeps, because it's difficult to destroy one as it is, and the increased number of enemies makes it nearly impossible.

 

[Gerix]

Well, I changed the settings in the SpawnEngine to give more flexibility. I think it would be ok if the 15 units in the wave were mostly infantry. Anyway, the wave can always be cut short in the spawn file. I agree that Jeeps have too many hit points. Their strength should be in their reduced profile and speed, not their toughness. Using the current settings, tanks don't seem all that powerful compared to them.

 

[vadsamoht]

I think the current ratio of tanks:infantry:jeeps is fine, but I'm certainly not getting them in waves of 15. Maybe the waves aren't far apart enough to be distinguishable?


Also, if you want to beef up the tanks, you could achieve that by leaving the current tanks as they are, and having a 'strong tank' that is either much slower but has many more hit points, or else moves erratically and fires at the player (e.g. moves around the edges of the screen in an unpredictable manner, and fires every 10 seconds or so).

 

[Gerix]

Yeah, with 15, it becomes hard to distinguish between waves, especially the last two. It probably shouldn't get that heated until the very end of a level. I was thinking about making a boss that moves around and fires, but I haven't worked up the instruction sets yet. Here are some other unit ideas:


-Helicopter: Flies in, hovers, fires some rockets, fly to a different spot, etc.


-Howitzer: reaches a certain distance from the player, fires a shell, gets recoiled back, returns to proper distance, fires...


-Motorcycle Infantry: Just a faster version of the infantry, with a higher score.


-Bombers, jet fighters, etc.

 

[vadsamoht]

All sounds good, though you might want to be careful how you implement having enemies in the sky and on the ground simultaneously. You don't want to have your helicopters hiding an incoming tank or jeep, etc.


Also, Howitzers would need to be slooooow when moving back to their position, otherwise their rate of fire would be too high, and utterly decimate the player.

 

[Gerix]

I'm actually worried about the Howitzer ending up hitting enemies in front of it. That would be embarrassing. But yeah, those are problems I'll need to watch out for.

 

[Gerix]

Bump. I released a new version of the game here. Be sure to check it out if you have some spare time. I'm afraid I've been pretty busy with other things, so there isn't a ton of progress, but I thought I should show what I have worked on, nonetheless. Check out the readme for a quick rundown of the game.


Thanks!