Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1037043 Posts in 41890 Topics- by 33497 Members - Latest Member: brunurd

August 29, 2014, 06:14:26 AM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)4 billion bullets.
Pages: [1] 2 3
Print
Author Topic: 4 billion bullets.  (Read 1890 times)
PompiPompi
Level 10
*****



View Profile WWW
« on: April 24, 2013, 10:49:37 AM »

In a network game, it make sense to track bullets or almost any object with an ID.
The ID is basically a 32 bit unsigned int that is increased whenever a new object of a specific type is created.

Every bullet the player shoots, the ID counter is increased by one. A shot gun that shoot several bullets(actually shells) at once will increase the bullet counter by more than one.

I am assuming that it is not possible for the players to shoot 4 billion bullets in one match\session. This makes everything easier to generate and deal with IDs since an unsigned int maximum number is 2^32-1.

Is there anything else to consider here? I just think of it like this and ignore the case that the counter might actually loop.
« Last Edit: April 24, 2013, 10:55:07 AM by PompiPompi » Logged

Master of all trades.
Dr. Cooldude
Level 10
*****



View Profile
« Reply #1 on: April 24, 2013, 10:58:37 AM »

Unless someone plays it in over 1000 hours, that should be fine.
for added safety, you could make the IDs reset every game round.
« Last Edit: April 24, 2013, 11:08:02 AM by Dr. Cooldude » Logged
nickgravelyn
Level 0
**



View Profile WWW Email
« Reply #2 on: April 24, 2013, 10:58:57 AM »

You're probably safe just rolling it over if it does run out unless there's somehow a chance that the first bullet is still active in the simulation by the time the last one is fired.

But yeah, if you fired 100 bullets per second it would still take (assuming my admittedly shakey math is right) 1193 hours to exhaust all of those IDs. I think you'll be safe. Smiley
Logged
Dr. Cooldude
Level 10
*****



View Profile
« Reply #3 on: April 24, 2013, 11:07:12 AM »

Well, if someone actually plays it in over 1000 hours, lets just call it a retro kill-screen. Wink


Offtopic: Nick Gravelyn, I didn't know you were on tigs! Love your XNA tutorials :D
Logged
Joshua
Level 5
*****


Be rad to one another!


View Profile WWW Email
« Reply #4 on: April 24, 2013, 11:32:44 AM »

Why not use the object pool pattern?
Logged

Sar
Level 3
***


Likes Violins


View Profile WWW
« Reply #5 on: April 24, 2013, 12:01:44 PM »

Why not use the object pool pattern?

I'm guessing because the point of Ids is to synch up the same bullet on every machine to the server, not to index into an array of instances or anything.
Logged

Currently working on: Chronicle of Mars
Previous Projects: [Käfer|Tristan and Iseult(TIGS)]
Fallsburg
Level 10
*****


Fear the CircleCat


View Profile
« Reply #6 on: April 24, 2013, 12:10:03 PM »

That's not to say you couldn't (and shouldn't) use both an object pool and this id system.

You can also pool unused ids (if a bullet dies [and there's no way to go back in time] it could get added to a list that would be safe to pull from).

The biggest problem I see with this id system, is how do you handle two bullets shot by different players at the same time? 
Logged
Dr. Cooldude
Level 10
*****



View Profile
« Reply #7 on: April 24, 2013, 12:17:20 PM »

The biggest problem I see with this id system, is how do you handle two bullets shot by different players at the same time? 
I guess each players might have their own counter, but I'm not sure...
Logged
Fallsburg
Level 10
*****


Fear the CircleCat


View Profile
« Reply #8 on: April 24, 2013, 12:26:11 PM »

Yeah, I guess it could just be Player ID + Counter.

EDIT:
Obviously not actually adding them, just the combination of the two.
Logged
nickgravelyn
Level 0
**



View Profile WWW Email
« Reply #9 on: April 24, 2013, 12:29:25 PM »

Or more generally you'd use a client/server architecture. One player is deemed the 'host'. All bullet IDs come from him. If another player shoots you'd simulate it locally with no ID (or some ID that signifies it's local only) so the local player sees it immediately on screen. Simultaneously you'd send a packet to the host to fire a bullet. The host then specifies an ID and sends that to all other players.

A good read would be to see how the Source Engine handles networking for their games, most of which are shooters and therefore pretty similar to what you're doing here (though admittedly their bullets are just raycasts).

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Logged
Dragonmaw
Global Moderator
Level 10
******


Notorious D.R.G.


View Profile
« Reply #10 on: April 24, 2013, 12:53:18 PM »

This is assuming that you are actually creating bullet objects and not using hitscan. It's important if you want to do things like simulate bullet drop or impacts on the body, but plenty of games go the raycast route (as mentioned above).

If you have to track bullet ids, go with playername_bullet#, and unload the id once the object has disappeared. If you do this, you won't need 4b slots. More on the order of 100-200.
Logged

My religion consists of a humble admiration of the illimitable superior spirit who reveals himself in the slight details we are able to perceive with our frail and feeble mind.

-Snoop Dogg
Martin 2BAM
Level 10
*****


@iam2bam


View Profile WWW Email
« Reply #11 on: April 25, 2013, 12:31:46 AM »

You're probably safe just rolling it over if it does run out unless there's somehow a chance that the first bullet is still active in the simulation by the time the last one is fired.

I agree, I wouldn't worry even if it wraps around to zero. Also the "Player ID/Object ID" seems the best way to go; even for 64 players you still have 67 million Object IDs available for each player.

Worst case scenario: Someone could attack the server by spamming with a lot of bogus or repeated IDs, but that's somewhat easy to detect.

If you still need like 2 billion objects there's another solution:
As the server knows who each player is it can just keep 2 31-bit IDs internally server-side, one for the client that created the ID and another server-issued ID for the rest of the clients, remembering to address the object accordingly whenever it sends info.
The 1 bit left out lets the client know if the ID is server-issued or one of their own.

This allows players to reconnect without creating weird scenarios like the server telling the new client where to start with it's ids or having to clean up the objects for the player using that slot before.
Logged

Working on HeliBrawl
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW Email
« Reply #12 on: April 25, 2013, 04:19:48 AM »

This makes everything easier to generate and deal with IDs since an unsigned int maximum number is 2^32-1.

unsigned int is 2^64-1 on my system, have you considered that?
Logged

Franchise - The restaurant wars begin!

What would John Carmack do?
kamac
Level 10
*****


Notorious posts editor


View Profile Email
« Reply #13 on: April 25, 2013, 06:05:13 AM »

This makes everything easier to generate and deal with IDs since an unsigned int maximum number is 2^32-1.

unsigned int is 2^64-1 on my system, have you considered that?

Isn't that even better?
He assumed 2^32-1 as standard, since that's the lowest for any decent PC (32-bit, I guess). I don't think here he has to consider somebody who is above that limit. He'll simply treat them as if they have 2^32-1.
Logged

Nothing to do here
PompiPompi
Level 10
*****



View Profile WWW
« Reply #14 on: April 25, 2013, 08:58:18 AM »

Yea,

Well the idea was that in practice I could think as if I have infinte IDs, since in practice no one will ever reach it's limit.
A pool seems like wasteful because instead of searching for a previous available ID, I can just "generate" a new one by increasing the "ID coutner" by one.
Logged

Master of all trades.
Pages: [1] 2 3
Print
Jump to:  

Theme orange-lt created by panic