• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
FredrikHolmstr

Sending actor events in an FPS networking model

11 posts in this topic

I have implemented the networking model described in this, by now very well known, document: [url="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking"]https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking[/url] Everything is working above my expectations. However, I seem to have hit a little bit of a snag.

The client collect input at 15ms intervals, which is used to locally predict the clients actions but is also sent to the server in groups of 2+ every ~30ms. From the server I send out snapshots of the world state to the clients every 50ms. Since the input interval is lower then the snapshot interval (and I can't really change them to match each-other without effecting game-play), I will receiver several input packets (2+ or more, usually 3) to the server for every snapshot it sends out,

It's here my problem lies, say that in the first of the three input packets I receive I see that the "Fire" is key is down, but in the second or third it's not. This needs to be recorded in some event-queue and sent to the remote clients. How is this usually solved? The fact that the snapshot rate is lower then the game rate, and "over-writing"/"conflicting" things can happen between the snapshots?
0

Share this post


Link to post
Share on other sites
You'll need to forward a copy of the inputs for each step; at least for inputs that "matter," which it sounds like firing does in this case.
1

Share this post


Link to post
Share on other sites
Another good article

[url="http://gafferongames.com/game-physics/networked-physics/"]http://gafferongames.com/game-physics/networked-physics/[/url]
1

Share this post


Link to post
Share on other sites
Would it be too expensive to roll back the simulation on the server until before the inputs happend and then simulate again with the new inputs?
0

Share this post


Link to post
Share on other sites
Counterstrike afaik introduced the idea of rollback to interpret firing to prevent cheating.

i.e. You can do a hit check on the client and see whether the shot hit another player, but the server shouldn't blindly trust this, because you might be cheating. So the server winds back player positions and animations (bone positions) to do a hit check to determine as the authority whether the hit actually happened. Once there's a hit, the server can just fire off a packet to the other clients to tell them that the player has been hit, play the appropriate animations, blood particle effects etc. The server doesn't actually have to reverse the simulation other than to determine whether there's a hit or not.

It doesn't actually matter that the client doing the shooting has seen a 'client side predicted' hit earlier than the other players will see it, just as long as the game is consistent. Smoke and mirrors. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
0

Share this post


Link to post
Share on other sites
Yes, this is also described in the article. But for movement input you would have to rewind either at the client or the server for the best results, but i guess in most scenarios this is prohibitively complex.

And i guess this was not even the question in this tread :)

If you have multiple inputs that happen on the same time considering the server simulation, you should probably process all inputs in the input queue and then do a simulation step. So you do not miss inputs which result in an immediate action, like shooting.
0

Share this post


Link to post
Share on other sites
[quote name='Inferiarum' timestamp='1342181411' post='4958763']
Yes, this is also described in the article. But for movement input you would have to rewind either at the client or the server for the best results, but i guess in most scenarios this is prohibitively complex.

If you have multiple inputs that happen on the same time considering the server simulation, you should probably process all inputs in the input queue and then do a simulation step. So you do not miss inputs which result in an immediate action, like shooting.
[/quote]

It's a few months since I worked on the network code of my current FPS but from memory:

For movement input on the server, I think I just simulate the physics for each actor as far as I've got the client input up to. So there's no rewinding or extrapolation. So each actor *could* be on a different tick, depending on how up to date it is with input from its client. Whether this is the best way, I don't know, but it works for me, and looks alright with multiple clients, under varying conditions of lag / packet loss / packet reordering. Remember you can have quite a bit of smoothing client side to provide the rendered positions of the other players. There may also be some other jiggery pokery I did elsewhere to compensate for this.

The main rewinding stuff I do is in the client side prediction code, if the server reported position is different from that of the client prediction, the client rolls back and reruns its simulation from the server reported 'authority' position.

So essentially, if you've got a rubbish connection, the server can only simulate you as far as its got input for, and you'll suffer competitively against the other players. Which is what you'd expect really.
0

Share this post


Link to post
Share on other sites
And sorry, got a bit sidetracked there, I'm a bit of a loon.

To answer the original question .. I don't send the fire as a normal input packet. The client normal input packet is stuff that will affect the physics - pressing left, right, forward backward etc. I just send these as off and on for each physics tick (with a history of past input up to the last acknowledged receipt from the server). You could go for sub tick accuracy if you wanted, and e.g. estimate the percentage of the tick the key was pressed .. I currently don't bother.

Firing a gun for me has no reason to be tied to the tick rate, and for accuracy of server checking you actually don't want it to be. So I just send a packet when you fire.
0

Share this post


Link to post
Share on other sites
I think I explained myself poorly, hplus0603 gave me the response that I was looking for. But I think the rest of you misunderstood me. Basically, I'm not talking about sending input from the controlling client to the server, but rather how to properly propagate this to the remote clients without overwriting conflicting input states, and it was obviously as simple as just forwarding the input state as soon as it gets to the server (and allowing the server to modify it before hand in case some actions are not valid, like shooting when you have no bullets, etc.).

Lawnjelly: Do you run your input on a fixed timestep? How do you deal with rendering a smooth display of movement? I feel that when I run input on a fixed time-step the rendered movement ends up getting a little choppy when the frame render speed don't line up with the fixed time-step. Do you do some sort of local interpolation or just live with the slight choppy-ness?
0

Share this post


Link to post
Share on other sites
[quote name='fholm' timestamp='1342188411' post='4958797']
I think I explained myself poorly, hplus0603 gave me the response that I was looking for. But I think the rest of you misunderstood me. Basically, I'm not talking about sending input from the controlling client to the server, but rather how to properly propagate this to the remote clients without overwriting conflicting input states, and it was obviously as simple as just forwarding the input state as soon as it gets to the server (and allowing the server to modify it before hand in case some actions are not valid, like shooting when you have no bullets, etc.).[/quote]

Now this is confusing - this isn't how modern FPSes work at all. The server doesn't forward the input of clients to other clients. The server uses the input to drive the physics, and it sends on the physics positions of the actors at each tick. It may also send packets to drive animations, play sounds, put the actors into certain states etc. The client doesn't know or care what the input of each other client is, it's only interested in what the actor is doing, and that is determined by the server. Client side prediction only needs to be run on the PLAYER not all the other players, it's there to hide lag.

[quote]Lawnjelly: Do you run your input on a fixed timestep? How do you deal with rendering a smooth display of movement? I feel that when I run input on a fixed time-step the rendered movement ends up getting a little choppy when the frame render speed don't line up with the fixed time-step. Do you do some sort of local interpolation or just live with the slight choppy-ness?
[/quote]

Stuff like mouse clicks can be done when the user clicks. Keyboard input can either be monitored / done at the time the key is pressed / depressed, or with an asynchronous check. View angles are sampled at each client tick and sent with the input packet along with left right forward backward. Smooth display of movement - interpolation.

There is an article 'fixing your timestep', I think this explains about interpolation. You have interpolation for your client stuff, and interpolation for your other player positions, possibly a different codepath (I have a different codepath, but the idea is similar).

If you write your stuff properly your game will work whether your tick rate is 100 ticks per second or 5, or 1 tick a second, and still look smooth (it's just the input / physics are more dodgy the lower the tick rate, I'm using 10-20).

Sorry would write more but have to go out! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
0

Share this post


Link to post
Share on other sites
Yeah, only the server is interested in the actual inputs of the client, for physics updates, verification and correction.

The remote clients will receive the occasional event message.and state updates, these get extrapolated / interpolated. Running and walking anims are either implicit (computed from the path of interpolation) or explicit (anim velocity replicated).

You can send each and every bullet event to remote clients, but that's rather inefficient, and clients are mostly interested in what 'looks good', bar things like grenades, rockets which would have to be replicated pretty accurately.

You can for example keep a count of the bullets to detect how many were fired since last update, or when to reload, or just flag the gun as firing, and only worry about simulating gun fire and reload anims regardless of what ammo is in the gun. The 'infinite gun firing' when a client drops for example.
0

Share this post


Link to post
Share on other sites
[quote]The server doesn't forward the input of clients to other clients. [/quote]

It depends. It's certainly possible to build an FPS which is input-driven rather than state-snapshot-driven. Doing so will likely allow your server to scale to more players per map instance. I would be highly surprised if there is no "modern" FPS game that uses input update packets, perhaps with occasional "baseline" snapshots. I also think that, the more players per map are supported by the game, the more likely it is to use input forwarding instead of state forwarding.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0