Kill count for individual units, like in TA

Remember in TA, looking at your Buzzsaw/Vulcan and seeing Kills:2643 at the bottom of the screen...it was rather satisfying

So, I was just musing, whether other people liked that idea as much as I did and if they would like it to be implemented into PA...?

Also, this is not a discussion on unit veterency, just on kill counts attached to individual units.

Thoughts...?

Cheerz.

No reason not to have it.

I liked this feature much when I seen it in TA when I play it first time in 1998 (don't sure if i play TA right after release). For now I think it's must have feature for smashing robots game.

I could be wrong, but I don't know that the information wouldn't be readily available to assign kill counts to units. If not, I would prefer compute cycles not be spent on this.

Well.. the kill count could hold some tactical information. If a turret has killed alot of units, it could be wise to build a second turret beside it

I liked this. It was fun trying to get one unit to have more kills than others without dying. They all died though...

Actually it really shouldn't be much to add it as the code will have to report to each unit about the kill so it can decide to move on to another target anyway.

killcount++; //not going to eat your CPU

This is actually a valid point - it would also give you feedback on how well you have laid out your base.
And I am pretty sure this is not going to cost a lot of ressources in terms of CPU power at all. In the end it was no problem in TA 15 years ago - so it will not be a problem today.

i thought kill counts for individual units were standard in all strategy games? i personally cannot recall an rts that doesnt have this.

It depends on how they code it. If it is already set up so that a kill isn't reported to anyone, the enemy unit is just not there when you re-scan, then adding kill counts (i.e. figuring out what unit actually killed said unit(s)) will be extra computations.

I think the best games to look at for a guess as to whether PA will are TA, SC, FA and SCII... actually ignore the last one.

:lol:
We're not using Gameboy anymore.
Adding +1 to a table at the same time as the engine removes a unit from the game, spawns wreckage, triggers the explosion effect, plays the sound effects, modulates the sound by distance, places scorchmarks on the ground on a pixel-by-pixel basis..

I don't think that +1 per unit kill is going to make much difference.
It's like suggesting that part of the reason why Total War games are so cpu intensive is because the kills are being tracked for the end-battle screen.
Trust me, that stuff is nothing compared to everything else that needs to go on, even just simple stuff like having a unit select a target to shoot at.
Heck, the bullet trajectory itself requires far more math and cpu cycles than adding a 1.

adding an incremented counter that tracks some in game event is not going to change any performance tests anytime soon, have no worries.

+1 to this thread!

True - but then of course that might be better - consider the 2 turrets firing on 1 enemy - who gets the kill? How it's coded to report the death of the unit will likely determine if both turrets get a kill or just 1. I suspect because such a counter is likely to be an after thought that the simplest method is likely to be chosen.

We can only speculate...unless of course someone who's not totally overloaded trying to get an Alpha out wishes to put us out of our misery....

Why would that be a problem, ephoscus? No two units will ever kill a unit at the same time, as time can be broken up in infinitely smaller and smaller units. 'Sides, this has never been a problem with mechanics such as veterancy.

I'm no expert programmer by any means but it shouldn't be too hard. Say that a bot and a bullet is based in a structure. A bullet can carry a pointer to its host and when that bullet kills a bot it can inform the host it made a kill.

Function checkHits(struct projectile *bullet){

If hitAnEnemy(bullet)
Bullet -> host -> killcount++;

}

a fair point to bring up, but as nlspeed911 brought up, the engine has a very good idea of what happens at what time, down to nanoseconds if truly necessary. the edge case that two shots literally fired at the exact same time and landed at the exact same time (down to billionths of a second) is quite unlikely, but even if that does happen once every ten-thousand kills, at that point flipping a coin on it isn't a big deal

What about having assisted kills count too? So, for instance, when calculating which units get the kill, it could just check which units were attacking when it died and award kills to all of them. That would probably be more accurate than just to the one that got the last shot.

that's a design decision at that point, assuming kill counts actually affect gameplay somehow. in any case that has 3 scenarios I can think of:

a) units who damaged the killed unit in any point of its lifetime get a kill/assist
b) units who damaged the killed unit in the last X seconds of its lifetime get a kill/assist
c) units who damaged the killed unit by X% of its total health get a kill/assist

Well calculating 2 shots at the same time on 2 different threads (lets say core's on a CPU, though that's not actually correct) can be a problem because of concurrency http://en.wikipedia.org/wiki/Concurrenc ... er_science) – you end up with both deciding their shot was the last one and if the code depends on only 1 having the kill, you have a bug.

you have essentially described data races, and there are more than a few ways to handle it

edit:

i guess i should add, one way of handling it i can think of is something called a mutex lock. this ensures threads are essentially not reading stale data or writing over data that a different thread wrote that it should actually wait to read from first.