Programming Question: Projectile Effect

[guest509]

  In a shooter game (real time) one wants to have several different types of projectiles the enemy robots and player can fire.

  An easy way to do this is to just have several different set types of guns that fire several different set types of projectiles with the correct velocity, damage, blast radius and other special effects. No problem doing that. Player or enemy wants to fire, just check the direction they are facing and create the projectile that corresponds to the gun they are wielding. Then when the projectile hits, go ahead and apply the correct effects (hp loss, knockback, etc...)

  It gets more difficult when you don't have projectile types. When you want the player to be able to customize their gun in between levels. To mod their gun as they see fit. Add silencer, more velocity, higher rate of fire, etc...and I also want to create various weapons for the robots on a procedural basis. Think Long Range Exploding Pulse Stun Cannon w/Silencer.

  When the shooter fires, I can easily pass the correct data with a standard function FIRE (facing, velocity, damage, specialFX1, specialFX2...). No problem.

  The issue is getting that data transferred to the target upon colliding with the projectile. I can check every cycle for a collision, then check for the exact instance of the projectile object, and then transfer that data over, but that seems overly complex and processor intensive.

  Then there is the secondary question about weather or not having procedurally created weapons on the enemy robots can in any way lead to interesting game play. Will it just seem haphazard and confusing? It will likely lead to weapons that don't make sense, though careful management of the RNG can alleviate that somewhat. I don't know of a game that does it well. I was planning to go the Random Realms route and describe the new enemy robot in between levels, so the player has a heads up.

  Any thoughts on either the programming of this or the design choice?

[kraflab]

Unless we're talking about an absolute shitload of projectiles you shouldn't need to worry about things being too processor intensive.  I would have each instance of a projectile created upon firing, and every cycle call projectile.motion() which will update it's position based on whatever parameters and check for collisions with every entity.

In terms of randomness of enemies, I think that as long as the look of an enemy and the type of projectile are unique pairs within one playthru I think that's fine.  If every single instance of an enemy had different weaponry that might get annoying.  The player needs to be able to plan movement and react and for that they need some idea of what they are up against.

It's hard to really speculate on this type of thing.  It isn't hard to implement once you have the actual game mechanics set up, so you'll have to test it out and see how it feels.

[guest509]

  Yeah. I'll test the heck out of preset weapons vs procedurally generated ones. I want the player to be able to tweek their gun. It fits with the theme. Gunfist. Your fist has been replaced with a gun, so of course you can tweek it all you want. Right? Lol.

  Following the roguelike model, you sorta want the enemies to be able to do what the player does. I want them to be the same parent object. So we'll see.

-JO

[Kyzrati]

Most of the data defining the particle should be static, so there really isn't a huge amount of it to be passing around--just a pointer to the static data for that particle type.

You can also start with a large pool of particle objects prepared in advance, so you don't have to continually be doing one of the most time-consuming part of the process: creating and destroying particles. When any given particle dies, just return it to the pool and recycle it (reactivate it and give it a new position and direction) later when you need another particle. This will cut down on the processing time significantly.

[guest509]

  I should point out I'm using Gamemaker 8.0. It handles particles pretty well, but I'm not trying to get into all of that. I'll be creating an instance of the Projectile Object. That instance will have stats based on the Shooter (player or robot) that creates it.

  There is some difficulty when dealing with specific instances, it's much easier to assume all instances of an object have the same characteristics and behavior.
 
  I had to do some digging but it looks like it's going to be easy to discover the instance ID of both parties whenever a Projectile collides with something. Once those ID's are known I can then work with them directly.

  This is nontrivial to do in Gamemaker, unless you are kind of advanced. So in the end, without knowing it, I may have been asking a GM8.0 specific question.

EDIT: It is trivial, in GM8.0, to make separate Objects for each type of gun/projectile (cannon, shot gun, etc...) and then work that way, assuming all instances have the same characteristics of the object except for position.

[Kyzrati]

Ah, thought it was just a general programming question from the thread title. Using GM is somewhat different since you don't have the same flexibility, but it sounds like you'll be able to do what you want, in any case.

[guest509]

  I thought it was a general programming question as well, then realized how easy it would be if I were doing it in C++.

  The design question is still food for thought, but the answer will only come through tons of testing and feedback. If I even ever get that far.

[Alex E]

I don't have anything to add to the projectile processing question. I've never used GM so I probably can't help with how you're doing the bullets that hasn't been stated yet.

For the random guns on robots question...Will there be multiple types of robots in the game (Weak, Strong, Fast)? If so, then I would probably have each Weak Robot have the same type of gun, as with Strong, Fast, and whatever other robots there are. I would make the strength of each robot's gun increase per level. For example, on level 1, Weak robots could have a normal Cannon. On level 2, they would have the same type of weapon (a Cannon) but with an attachment on it (Pulse, Silencer, whatever). Next level, same Cannon and attachment, but with yet another new attachment.

I don't like the idea of having each robot have a different weapon, as that would be far too confusing in my opinion and remove some tactics there could be in favor of more random game play.

Even if there is only one type of robot, I still believe each should have the same type of weapon per level.

[guest509]

  Each robot of each type will be identical.

  The plan was to introduce one new robot type each level. Like how Random Realms does it. In between levels it tells you what to expect and gives a little blurb about the enemy that you'll be facing in the next level.

  So level 1 would have several level 1 type robots. Level 2 would have several level 1's and a couple of level 2 bots. With the occasional out of depth bot you know nothing about.

  I'll have a list of possible 'mods' to the robot, and a robot will get mods depending on it's level. So a level 5 robot, for example, would have maybe 5 mods. Increase speed, more hp, more aggressive AI, teleporting, etc...I want to make special Terminator bots that will have the characteristics of a robot that killed you in the past.

  Of course this is way in the future and I'm getting WAY ahead of myself. Right now I'm just shooting for one robot, one player, one terrain tile set and a simple procedural level. Not getting stuck in walls would be nice. HA! I asked the programming question because I need to set up the objects and data structures now so as to not have to rewrite everything later when I start adding different weapons.

[Alex E]

I actually like your method for robots. Maybe on level 4, level 1 robots will stop appearing. Likewise on level 5 for level 2 robots. And so on. Would it be a good idea to have level 1 robots always stay the same? For the first time appearing, level robots could get random stats, and stay that way until the eventually disappear a few levels later.

Just some ideas unless that is exactly what you're planning on doing, then completely ignore it. Or just disregard this until you actually start working on the different types of robots.

[guest509]

  Lol. That's exactly it.

  I'm currently simplifying the entire thing right now.

[Pueo]

I'm not sure if this has already been mentioned (I might have gotten lost in all the technical-talk), but could you just assign an ID to the instance of the projectile, then when you get a collision, read the ID? It would tell you what the projectile was, and then you could act accordingly.

[guest509]

I'm not sure if this has already been mentioned (I might have gotten lost in all the technical-talk), but could you just assign an ID to the instance of the projectile, then when you get a collision, read the ID? It would tell you what the projectile was, and then you could act accordingly.

Yeah, that's exactly what I'm going to do.

[wire_hall_medic]

I would have the projectile variables stored in the gun (possibly more than on set, for secondary fire), and have each projectile reference the gun.  If you've got 10 slots for variables, and can fire 10 shots per second, it's a decent savings in object creation overhead.

For randomness, I've found that things in real-time games need to much more varied than in turn-based.  In the chaos of a firefight, it can be very hard for the player to tell the difference between a sawed-off plasma scatter cannon and a hot-loaded particle shotgun.  I did like what they did in Mass Effect; there were basic guns (pistol, shotgun, assault rifle, sniper rifle), and then mod packs which worked with everything (damage over time, higher RoF, armor piercing, specific damage types).  But only because I would pause, removing myself from the action, and dig through my inventory.