Oh noes! FRAGS!!

Good day people.
Today's problem is the frag system.

We started yesterday but we are wondering if there's a better way to accomplish this.

Here are some points that we have in mind:
*In order to avoid conflicts at the moment of respawning our player's character. We will NOT destroy the playerprefab GO, instead, we gonna relocate it and replenish life and set ammo to initial values. In this way we will be using the same character using the same network ids for every component all the match.

*Weapons will now send not only "damage" within the call of our function applyDamage... now, we will set as parameter an "damage" ARRAY, with our source GO network id, and the damage to be applied. In case of killing our target, it will pick the ID and tell to a GO running only at the server side "hey man player#12 killed me" using a RPC calling. Then server will refresh scores to rest of players.

*ROCKETS, grenades, superduperays and such, has now stored the id of the player who created them. And will send the same array with id and damage to the applyDamage function.

Questions:
*Is this gonna work??
*Whats the best practice to manage frags in a FPS game?

Question about something else:
*Is there a way to set 3DText to face the camera always? How?

Thats all, we have till friday to finish the first prototype so we are a little stress out

Thanks in advance people.

 

But if you have 3D text facing the camera always, then it's 2D text. So use 2D text instead. If this is about making nametags for players, use Camera.WorldToScreenPoint to position the 2D text. Using 2D text also has the benefit that the text doesn't grow or shrink with distance...if you notice, other games with nametags generally have the text stay the same size, otherwise it's impossible to read if the other players are too far away.

--Eric

 

Yeah, you must send always all the data that allows you to get information like if its a missile from an enemy, a teammate or yourself. Some information can be stored in the local client so you transfer less data (ie just IDs).

.org

 

When determining hits I would recommend you take one of two options I will not elaborate on (maybe later, I'm in a hurry).

1. Let the server do all the calculating.

2. Let each player do the calculation for their own shots.

I would recommend you take route 2. This is probably the easiest to implement and keeps the server-code closer to the client-code.
Games like Counter-Strike, where cheating is a real problem, use the first alternative to make it harder to cheat.

Regarding respawning:
What you described would work, but if a player is dead for a long time, many state-updates will be sent, that are simply not necessary. Unfortunately you cannot tell NetworkViews to stop synchronizing.
I would recommend you destroy the GO and reinstantiate it when needed.