A good advice applicable to any activity you do, and especially when making apps/games

Example : the last few days, i was trying to add an explosion effect which damages all the entities in range, but also produces particles of damage emitted from each entity with a direction vector entity->explosionand this was not as simple as it sounds because for a 3d explosion how do you choose which area of an entity to emitt the damage particles ? the middle ? what if the entity is really tall ? wide ?

So i stopped for a moment, and played quake 3 arena, a great game, to see how they handled that :there is no such complicated particles effect!there is only a textured quad aligned to the normal for impacts, and a textured quad scaled for explosions.But the game is fun and addictive, and the gameplay is so fast that you won't notice such simple details anyway.

you have the "collision box" of the bullet - and you have the collisionbox of the entity. When they collide you could have a "simple" calculation taking both boxes into consideration. The resulting poly of the "collission"-surface is where your particle effect should emit stuff.

If the calculation is too complicate then simply even more: just store "collission box"-volume for each entity so you can compare - or calculate on the fly. if volume "bullet" is way smaller than the volume of the "entity" (and maybe also max of the both axis not being the movement-axis -> calc relatively!) then assume that the bullet creates an effect. if the bullet is too "big" (cannon shooting at a fly) then no need to emit a particle effect - or just use the whole "collision box" of the hit entity.So use the bullets "front" (the one hitting the entity) as area defining where an effect is emit.

@focus on essentialsIt is the "unimportant" stuff which reads good in PR messages ("body parts can get hit"). Also the "unimportant" stuff is what makes a game look "really polished" instead of "looking good". To make a game working first then yes, focus on the essentials. You will end up with the pareto principle/ratio (80% work done in 20% of time, missing 20% work needs 80% of the time). You will have a working, and maybe "good looking" game but if you want to create something "superiour" (relative to your skills!) then the unimportant details will have to be done too.

This of course does not count for things the player will never see, and which have no impact to the game (simulating hair in a non-zoomable-game running on a 160x120 display).

@Derron>>my problem was more related to determining the appropriate areas of the entities in range affected by one explosion, not the single collision point/normal of a bullet. (which is easy to find)Of course it is doable, but is it worth it (for the gameplay), most likely not... It is more a graphics effect than a gameplay mechanic.

But whatever, my point was that, as programmers, we tend to get obsessed by unimportant details...

@ affected unitsCast rays from center of explosion outwards - check what is colliding with these rays. Amount of rays defines if you can "miss" things.Or cast invisible particles - which have their own collission-checks. Some kind of "explosion wave"-particles.

@ obsessionThat's what defines a "coder" from a "programmer". For me "programmers" are doing what they are told to do - nothing more, nothing less. A "coder" is doing things with a mixture of "motivation", "fun", "explorative desires" ... in other words, we tend to try to code things we knew in advance that we most likely will fail as it is "over our head".

So it is absolutely normal for us "indie coders" to tackle problems which the paid "programmers" would skip for being "time eaters" ;-)(Not saying that we solve that problems ;-)).

Yes i thought about casting rays (14, like a 3d cross) but it would produce serious slowdowns if explosions happen often...

an alternative, not sure if it would work with the collision system, would be to use one ellipsoid (spherical collider) and progressively increase its radius, in the same way that the explosion particles spread...

anyway, i keep it in mind, but not for now...not essential for the gameplay!

One thing that always stuck with me was a dev was talking about explosions and how it looked cool if the sparks bounced off the floor.

Trouble was, framerate took a massive hit when this happened. But what the dev discovered is that not every spark needs to bounce, only say, 1 in 10.At 1 in 10, the player was still fooled into thinking nearly every spark bounced.

Yeah that's a great method. (then again, tech has advanced, nowadays you can just bounce 100s of thousands of particles with a very small speed impact anyway)

In any case, there are so many cool tricks like this that users will barely ever notice. As long as there is action and movement we can get away with a lot. For me it's a huge part of the fun to find and finetune these tricks.

I'd love to see offscreen calculated volumetric effects in more games again, those always look nice if done well and should be fast enough nowadays.When the cam is moving a true volumetric effect will look so much better than a flat sprite based one.And it really doesn't need much detail or accuracy.