Mobs, Health, Death - Better Late Than Never

posted in Fidelum Games
Published February 04, 2016
Advertisement

Some things came up preventing me from working on the project for a couple of days, but I was able to get my base AI, health and death working (mostly).

I've noticed a few unwanted behaviours caused by Unity's physics engine and my projectiles where they'll sometimes hit an enemy and ricochet in strange ways instead of just disappearing like they're supposed to. I leave fixing that for clean up after I've implemented the rest of my features.

But I've gotten a simple AI that all (or most) of my enemies will inherit. They basically just move within a certain range of the player and continue to attack until he's out of range, at which point they begin to move again.

I've tested the behaviour with a large group of enemies, and it all seems fine. The enemies overlap one another, and visually I don't much care for this, but I'm not sure there's any way around it if I want to allow multiple enemies to attack the player at the same time (which I do). Maybe I'll add a semi-random hue to the enemies' sprites when they're spawned just to spice up how it looks a bit.

The player spawns indication text similar to that shown in my last post when he's taken damage. He also actually takes the damage and dies (destroys his own gameObject for now) when his health drops below 0.

Haven't had the time to code the UI to display health correctly yet, but that should only take five minutes (I probably just jinxed myself...)

Anyway, it's coming along. I think this journal thing might be helping a bit.

Hopefully tonight I can get the health bar working. After that it's spawning cash pickups on enemy death with a chance of ammo or health pickups being dropped.

Once those things are finished (hopefully one development session), I'll work on the motor bike repair. After that's done, the core gameplay mechanics will be in place and all that's left to do is add the levelling/upgrade functionality (I think the design will take longer than the implementation on this one), add different enemies and create the rest of the graphics.

If I'm lucky/diligent, hopefully I'll be done this bad boy by the end of February.

0 likes 4 comments

Comments

ferrous

For Unity and physics, it's kind of a battle. Have you already messed with the interpolation types? Extrapolate or Interpolate might help. You might also want to up the solver iteration count on the projectiles. And I've found that with things like OnTriggerEnter, it just sometimes doesn't fire reliably, to the point where every place I have OnTriggerEnter, I also have OnTriggerStay, and duplicate the logic there.

Ex: OnTriggerEnter() { KillProjectile(); } OnTriggerStay { KillProjectile(); }

Finally, you can update the rate at which physics gets updated, though that can have major performance impacts.

EDIT: And failing that, if you're shooting a fast enough projectile, you might be better off just doing a ray or sphere cast.

February 04, 2016 05:16 PM
JEJoll

For Unity and physics, it's kind of a battle. Have you already messed with the interpolation types? Extrapolate or Interpolate might help. You might also want to up the solver iteration count on the projectiles. And I've found that with things like OnTriggerEnter, it just sometimes doesn't fire reliably, to the point where every place I have OnTriggerEnter, I also have OnTriggerStay, and duplicate the logic there.

Ex: OnTriggerEnter() { KillProjectile(); } OnTriggerStay { KillProjectile(); }

Finally, you can update the rate at which physics gets updated, though that can have major performance impacts.

EDIT: And failing that, if you're shooting a fast enough projectile, you might be better off just doing a ray or sphere cast.

Yeah I've fiddled with interpolation. None actually seems to work best since I'm using a trailrenderer on the projectile. Both Interpolate and Extrapolate cause weird 'back and forth' effects on the trail renderer.

I've been thinking of switching it over to get rid of the physics altogether. My projectiles are pretty much the only thing that use it (other than my player's jump) and it's just created issues so far. It's not really a physics based game anyway.

I'm thinking of raycasting and just drawing a line from my weapon to the target on hit instead of using the physics and trail renderer solution. This might make fixing my weapon accuracy issues easier as well. I'll try out a few things.

And thanks for mentioning OnTriggerStay. An issue arose last night where my enemies sometimes stop attacking my player if I'm stationary and firing at them (I haven't debugged, but presumably, the collision between the projectiles and the enemies might be interfering with the triggers between the player and enemy). OnTriggerStay might be a solution.

Also, as you mentioned, my projectiles are quite fast. I've tried using triggers for the 'collision' detection, but they've been far too unreliable. Projectiles pass right through most of the time.

I might try cranking up the physics iterations though. Haven't fiddled with that yet. So far the game runs without any lag whatsoever, even with ~100 enemies and ~50 projectiles on the screen, so I think I can afford a little more computation. How do WebGL builds handle that kind of stuff versus PC builds?

Lastly, I've never even heard of Spherecasting. I'll have to look into it.

Thanks for the input! Much obliged.

February 04, 2016 07:31 PM
ferrous

Spherecasting would be more useful if you had a large projectile, like a large rocket launcher, it just projects what is basically a cylinder that is capped with a sphere on each end. (A pill shape)

Yeah, for your bullets, since they are travelling that fast (and relatively small), I'd go with the raycasts, you can either do a hitscan, and have them hit things on the frame they are fired, or move the bullet yourself during it's update loop rather than having it be a rigidbody that is moved by Unity's physics, and use the physics.raycast to check for collisions on that frame.

WebGL, so far, for my 2d game, I haven't noticed much of a drop in perf for webGL, but my game isn't super taxing, and i'm semi-optimized (i could probably use another pass through using the profiler to check for garbage and whatnot)

February 05, 2016 10:27 PM
JEJoll

Thanks for the tips. I definitely want my projectiles visible to the player, so I think the way I'm going to tackle the problem is:

  • Cast a ray in the direction of the mouse in relation to the player, with a small degree of random offset to simulate weapon inaccuracy
  • Deduct enemy health if there is a hit
  • Draw a line from the ray's origin to the hit location, having the line persist for a few frames. (This will be the visual representation of the projectile).

Depending on how good/bad this looks, I may have the line move/grow over a few frames to give a sense of movement.

February 09, 2016 02:29 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement