• 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.

gabrielefarina

Members
  • Content count

    26
  • Joined

  • Last visited

Community Reputation

204 Neutral

About gabrielefarina

  • Rank
    Member

Personal Information

  • Location
    Milan
  1. Hello, I've an additional question related to this topic.   I'm doing prediction on the player and interpolation on the server-controlled entities. This puts me in a situation where entities are a few milliseconds behind in time. When I receive a bunch of events from the server, I immediately apply to the ones that target the player, and I queue the ones that target the server-controlled entities; these will be executed in the future, as soon as the interpolation window reaches the right time. By doing that though, I hit weird situations where, for example, I execute an "hit" event on the player, while the "attack" event from one of the entities is still pending execution (attacks happens instantaneously for now).   Should I simply queue also the events on the player, and execute them with some delay? Or is there another common way to deal with issues like the one I explained above?
  2.   I think you are right. I don't need shooting to be super precise, so I might solve the issue by having hitboxes big enough to compensate for the fact that the event is being executed later. I might even enlarge these hitboxes only when an entity is moving, thus still having fairly precise collision detection when an entity is standing.     I think it is another fair point: enemies at the moment tend to not move too much, as long as most of them have ranged attacks, and the ones who don't usually come straight to the player and stop when close enough.   PvP will still be an issue with the approach above, but I think that I could design the PvP-related networking system in a slightly different way, so that it is more precise and compensates for lag.
  3. If delaying the death animation is one option, how do games that show instant death deal with this kind of situation? I guess some of them simply have unsafe authoritative clients, and they live with that (I think that Realm of the Mad God was like that, at least for the first few months)?   Also, is lag compensation than useful mostly when interacting with other player characters? I mean in a PvP like situation?
  4. Links with examples of different solutions to this are in the Forum FAQ item #12.   It looks like you are getting close to what Source does, that link is one of several techniques mentioned in FAQ Item #12.   I already read the FAQ and most of the linked posts, but I still didn't find anything specific for the topic I'm mentioning :(       The game I'm prototyping is an ARPG without any notion of targeting. Something similar to Realm of the Mad God to give you an idea.   I wonder what will happen if I only rollback the position of the entities, not their entire state. If they get killed by an event, even if I get another event that was supposed to be executed before the one that killed the entity, I can ignore it - or maybe I could allow entities to be "killed" twice (for a little time frame) as if the two player contributed the same to the last hit.   In general though, my understanding is that there is not a correct solution for the problem, but it really depends a lot on the game design and how precise the system should be.
  5.   When you say "for the future", does it mean that I should execute the event as soon as it reaches the server (which in practice will mean executing the even in the future, based on the latency)?   Wouldn't this create collision detection issues potentially? The player will shoot at the place where he sees the monster (up to 100ms back in time) and then will get the action executed when the monster is probably at a different location.
  6. hello,   this weekend I went back to an old multiplayer prototype I was working on. For now, I render the world state 100ms back in time, and interpolate the server states to compensate for lag and updating the server-controlled entities smoothly. When the client performs an action, I send the action to the server, roll back the server state to match more or less how the client saw it when performing the action, and execute it. Than I send the response back to the client.   Everything seems to work fine, but I have issue when simulating two players interacting with the same entity. Let's assume the entity is a monster, and both players will level up if they kill it. Player A has a very slow connection, Player B a very fast one. A attacks, and a few milliseconds later B does the same. As long as B has a faster connection, B gets its event to the server earlier, get it processed, kills the monster, get the response and levels up. While this is happending, the event from A arrives: the state goes back to when the moster was still alive, the monster gets killed again, and the response is sent back to A and B. A levels up (correctly because he killed the moster first), but than B is in this weird state where he leveled up, but the new server state says it never did and I need to somehow rollback.   How do you guys solve normally situation like this one? I could execute the events as they arrive to the server, without rolling back. But than nothing works decently 'cause my game is an action-packed game and I have to keep lag in consideration. Any suggestion?   Thanks!
  7.   This will be the cleanest approach IMHO, but I don't want to spend weeks of my time trying to get a way to fix the floating point issues that might come out of this approach (server and client will be running on different architectures). Maybe fixed points will help here? Or should I simply not worry about floating point issues as long as my game does not rely on complex physiscs?
  8. With packet at the moment I mean a UDP packet. Not sure I will be able to fit everything in ~1.4k, but I also want to avoid to split the world update in multiple packets and have some of them potentially arrive delayed due to the fact that I need to re-send them. But I think that's how it is for the most of the games? Or do they send the world update on an unreliable channel and hope for the best?   There is nothing that forces me in using UDP at the moment, but I already have a decent layer based on UDP and I'd rather stick with it unless TCP gives me something that I absolutely need. A game similar to what I'm prototyping (Realm of the Mad God) works over TCP and is working fine, although I believe they have partially authoritative clients or something similar to have such a smooth gameplay?   About the number of events, I have no idea at the moment. I'll see how the game goes and act accordingly. But I will encode in the world update only the events that I can't easily deduce by comparing the old world state and the new world state, so I hope to be able to keep the number low and also make sure they can be packed very tightly in the outgoing message.
  9. For now I'm queueing events (together with the ticks when they happened) and sending them to the client in the "world update" packet; this way on the client it is easier to understand what happened in between two updates without having to decode this information by comparing the new and the old state. I'm limiting the number of events to a very low number, to avoid sending too much stuff to the client. It seems to be working fine for now, but I'll know more as my prototype progresses :) I just need to be sure the delta compressed world update + events always fit one packet I think, to make sure everything arrives together to the client.
  10. Hello everyone,   I'm proceeding with my prototype and everything seems to be working fine. Entity interpolation has still some small issues but I think it is something I can skip for now.   My server sends world state updates to the clients 15 times per frame, while the server updates at a fixed 30 frames per second. Some events might happen between the world state sync, and I was wondering if it is usual practice to send these events immediately or if they should be queued and flushed when I send the world update.   Thanks
  11. Hello everyone, sorry for disappearing for a bit.   I've been able to solve my issues it seems, by resending previous inputs. Now I have a smooth client side prediction of the player entity even when simulating packet loss and quite high jitter.   Thanks for the help!
  12.   Yeah, I'm using the approach I read in the Valve articles, and it is working fine it seems.         Ok, I will try to send the last X input messages, and remove from the outgoing queue a message when an ACK from the server is received (or maybe when they get too old). When the server gets N input messages, should it process them immediately or should I store them in a queue and execute them one by one as the server ticks? Executing all the inputs at the same time might lend to a non-smooth behaviour on the server, but I guess that it is expected in case the stream of incoming messages from the client is not contiguous?
  13.   Does this mean that I should run the simulation on the client in "server time space"? At the moment, when a client connects, I send it the tick-count of the server to sync the client with it, but I didn't thought about running the simulation ahead of time base on the ping. When you say "ahead of time" here u don't mean to process the input with a bit of delay, but simply setting the timestamp/tick-count on the client at "server_ticks+ping/2", correct ?   Thanks, Gabriele
  14. OK, I moved further and I think the things are going better now. I think that some of the jumpiness is due to the fact that I discard messages that arrive out of order, so I don't simulate part of the input on the server. Each of my messages at the moment contains the computed velocity vector and the predicted client position after the velocity is applied; on the server I apply the command and compare the resulting position: if it differs form what the server simulated, I send a "correction" message with all the required information. Due to this, if I skip an input message on the server, the simulation goes out of sync. What I'd like to do at the moment, is to add a buffer of incoming input messages on the server and making sure the messages are reliable (even if unordered): than, once I receive the message I expect, I simulate on the server all the messages in the queue in a single update step, using the difference between the client-tick of the last acknowledged message and the current one to understand how much delta time use in the simulation.   As far as I understood though, it is not a common practice to use this kind of buffer on the server; it seems that most of the games discard old input messages and apply only the latest. Doesn't this create serious issues if (like in my case) the movement is based on velocity or acceleration? Do they use a delta time based on the timestamp of the last acknowledged message when applying the input on the server? Or do they simply ignore this situation an rely on some smoothing on the client to deal with the situation?
  15. In my case, the physics simulation is (and probably will be) very basic but still I think that having a different tick rate will raise problems. Also, as long as I'm aiming to support a low number of players-per-server, I won't probably need to lower the tick rate there, and running physics at 30 and graphics as fast as I can with smoothing already proved to be a good solution.   What about how to deal with dropped or out of order messages delivered to the server btw? Reading again your answers, I think that I like the idea of delaying the execution on the server, as long as it should allow me to keep the server code simple and avoid to have to store the past entities state. As long as I'm planning to use a client-server model also for single player or local multiplayer, maybe I could adapt the delay on the server based on the average latency, or even better set the delay to 0 when playing single player or on a local network, and set it to something more meaningful when running online. Does it make sense?