• Content count

  • Joined

  • Last visited

Community Reputation

209 Neutral

About caymanbruce

  • Rank

Personal Information

  • Interests
  1. @Kylotan Thanks I will update my code with this in mind.
  2. @Kylotan I mean I put those extra properties in because I want to query it directly from "currentRenderState" when I want to display or use them on client. But if I don't put those properties into "currentRenderState" I need to maintain a separate data structure that only contains those values. That will be a lot of work when adding or deleting values(player status) in it. I guess that will be fine?
  3. @Kylotan I might have been too lazy to split those properties such as "alive" and "username". But I have this concern: because I am putting every state into a big object, when I query a state from a list of players or NPCs I can quickly get the property and display its status. Otherwise I will have to maintain and query another state list to get these properties. And if this other state list doesn't have the same player IDs with the current state I am in big trouble. Back to 'commiting' the current state. I think you mean recalculate it when I need to store it to the "previousRenderState"? Would that be doing extra calculation when that situation comes up?
  4. Sorry I went the other route because I felt that was enough for my game and easier to implement. But what does 'commit' mean? Apart from those values I have "alive" to check if player is alive, and "username" because I need to show it on screen, and the player's "score". The player's position is not just x and y. It has many parts moving after it so I need to pass those position values too.
  5. @Kylotan But I am very curious though. How not to store the current interpolated state? You see, one of the biggest headaches I have when changing my code is that I have to assign my "currentRenderState" to the "previousRenderState" (outside of interpolation). This results in copying a very complicated object into another object, value by value, and I can't copy its reference otherwise weird things would happen and those states will become unstable because changing one state can affect another.
  6. I agree with you too storing it on a per-object basis breaks it down into smaller unit so it's easier to debug. Unlike what I am doing now every time I debug or change some data structure it is a nightmare. But I still need to fix my code to adapt to the new structure.
  7. Thank you for your input. I have thought about putting the interpolation logic inside the loop of the player list. But maybe I am just being lazy not to test out if that works better or not because changing my interpolation code is really a headache. It can take up a day or even more. And it usually breaks my game and takes me even more time to debug. The main reason of separating NPC and player states is that they are different thing. They behave totally diffenrently and NPC has only a few properties versus player which has a lot more properties. In my game, it works like this: (Pseudo code, not in interpolation, but in the code when client receives an update) previousRenderState = futureRenderState; if (currentRenderState exists AND currentRenderState.timestamp > previousRenderState.timestamp) { previousRenderState = currentRenderState; } futureRenderState = (incoming update state values...); So sometimes I need to assign the current state to the "previousRenderState" for better interpolation.
  8. I have implemented client interpolation and it works well. But I don't like my current structure. It looks really ugly and created too many temporary objects, besides that it is really hard to maintain the code. I am not going to show too many logic here as it is very tightly coupled with other parts of my game. Note that my code is written in javascript but if you show me some direction in generic language or C++ that's OK too because I think the logic should not be too different. In my game I have hundreds of players and other NPCs, and every network update I get a timestamp. I just bundle them up in a very big state object. Let's call it "currentRenderState", similarly I have "previousRenderState" and "futureRenderState", which means the state I receive in last update and the state I receive in current update. I am going to interpolate from "previousRenderState" to "futureRenderState". The interpolation result will be stored in "currentRenderState". If next update state hasn't arrived and the player state hasn't reached "futureRenderState" I will interpolate from "currentRenderState" to "futureRenderState". So my state object contains a lot of information. state = { timestamp, allPlayerStates, allNPCStates } Here "allPlayerStates" is a very big object too. It contains all the states of all players and each player contains dozens or even hundreds of properties. Every time I interpolate I need to clear the object in currentRenderState, also I need to reference allPlayerStates and allNPCStates in "previousRenderState" and "futureRenderState" to get one of the individual state and interpolate it. At the end of the interpolation I create a very big temporary state object and put the interpolation value into this state object and assign to "currentRenderState". Then in the interpolation code I loop through the "allPlayerStates" of "currentRenderState", and assign the value to each player on client side. Also I loop through "allNPCStates" to assign the value to each NPC on client side. This logic works, but I feel tiresome each time I read through my code. Is there a better way to organise my interpolation code, and probably make it more efficient too?
  9. @Kylotan I I worry that because I am not inserting only one object. I am inserting and clearing 8000 objects 4 times per second. Maybe that's not a lot for a game but I have no idea because I am building a game for the first time. Now I guess your suggestion is like what I said in my first post, just update/add/remove the entities that actually change, instead of recreating everything again, is that correct?
  10. @Kylotan Thanks but I am already doing what you said. Maybe I didn't explain it properly. I did only query based on a player's position. I do not perform the insert/clear operation on every player. I am just worrying about inserting all the entities too many times during game play. For example when my player is moving I find player A is also moving around me, 250ms later when I do a second spatial partitioning by inserting all the entities again into the hash, A is still moving around me. So I am inserting it two times. after 1 second maybe A is still moving in the same region and I am inserting it and removing it 4 times already. The same applies to the foods for example, which are static unless they are removed from the map. When my player is moving sometimes half of the foods on the screen never change, but during this time I have to insert them many times for spatial partitioning.
  11. Yes I have 1 spatial hash. But what I am doing is for every player I clear the hash and insert everything again and use the player's position to determine the interested entities. I am just being lazy not to look into the performance details when I first implemented it. I find the spatial partitioning method is easy to find interested entities of a player. I used to use a radius-based system to get interested entities but that's more like brutal-force so I removed that. But I guess what you mean is to only insert/delete those players/entities that change their status. How should I use spatial partition correctly? How often should I check the environmental updates in interested region for each player? a few times a second or less, or more?
  12. For example I have 6000 entities on a 2D map and I want to get about 180 which are on my player's screen. When my player is moving new entities may appear on the map, at the same time some entities or enemies die so they disappear. I used to clear the entire spatial hash and insert everything again a few times a second. But I am thinking maybe it is better to only update those entities that change on the map, the number of changes may be huge though, but still, compared to the number of entities on the map it is still small. I am just not sure if this is worthy or not.
  13. @hplus0603 Thank you. I am not using a game engine. I just build everything from scratch, for a simple game of course. I am not sure if a simulation tick means a update tick. But if I have such an event queue as you described, do I have to check the events in the queue in each update tick? I wonder whether it will put more burden on server or not if I put all the events in the update tick? In my game the update tick is 60 ticks /s and I do a network update at an interval of 10 times/s. Currently I am checking those status changes and events in the network update at various interval (100ms, 300ms, 500ms, etc.). And it is working nicely. But I always wonder if there is some subtle problem later on if I keep doing it this way.
  14. I want the dead players to be able to watch environmental changes for a few seconds (or a fix amount of time) before they are cut off from the server. How can I achieve this? I am thinking of using a timestamp. So when the player is dead I record the time for that player and a few seconds later I loop through the player list and disconnect the players that have been dead for certain amount of time. The problem is I loop through the player list at a fix interval which is about 10 seconds. Some players may get disconnected early and some may get disconnected after a longer period because if they miss current loop they need to wait for another 10 seconds to be disconnected. Another problem is that on client side I don't see any environmental changes after the player gets killed. It just stops there and looks like connection is lost. (I don't have any client data controlling the updates, all the data comes from the server).
  15. Players states interaction on the same screen

    Thanks I have fixed the problem in my game. So far so good. I've spent days fixing it here and there before I ask the question. But I will do more testing to make it better.