• Content count

  • Joined

  • Last visited

Community Reputation

209 Neutral

About caymanbruce

  • Rank

Personal Information

  • Interests
  1. Introduction to Octrees

    I felt I have learned something from your article although I just try to implement a RTree spatial partition for my 2D game. You've done an amazing job. I am very interested in updating only the changed branches as my current RTree implementation failed to do so. I will have to come up with a better solution.
  2. Yes it is using more than 90% CPU most of the time. Sometimes 126%. I don't know how come CPU usage can be 126% though. Memory usage never changes. However because V8 engine is built on top of C++, when profiling the code of my game it often boils down to how deep I understand how the V8 engine works. A bit off-topic now but I think I am standing at a fork in the road, whether to continue development in javascript or use a more concurrent-friendly language to rewrite the backend. I wish I had so many devices at hand. Not to mention I have to learn to face new problems installing things to a Raspberry Pi.
  3. My game runs extremely smooth on local dual-core computer. But on a remote 4-core VPS after running for 20 hours it is just slow as hell, CPU usage is 100%. I can't even login to play on the next day. It is hard to diagnose because working on a remote server is very inconvenient.
  4. Thanks. Although you don't directly explain the algorithm I get what you mean and I totally agree with you. At the beginning of writing my game server I just want to see how far can javascript go on server side. The curiosity is driving me forward and there are a lot of tools and libraries available to keep me going. At first I was very happy that I can code a game server with javascript but it is becoming harder and harder as I try to improve the performance of the server. Maybe I can just use other typed languages which have better support for multi-threading to rewrite my game in a much shorter time. I am not very familiar with multi-threading programming though. The other language that I have used before is Java. Maybe I should pickup Erlang, or Go, then rewrite my game server?
  5. I've come across a multiplayer game framework and it features an algorithm to efficiently handle the movement and collisions of multiple players on a huge map. What it tries to do is to divide the map into smaller cells and create child processes (because it is single thread in javascript) for those cells. Then the algorithm distributes the game workload to different processes of the CPU. So basically each cell will be handled by a child process but everyone of them will share the same game context. This way if I use a 4 core or 8 core CPU I can use all the cores of the CPU by creating new workers processes. And supposedly it will reduce the burden of the master process. In C++ or Java we may choose to create new threads but in javascript there is only one thread in the code so creating processes is very similar. However, I am not familiar with the algorithm. I am not very sure if this is a standard way or a better way to deal with the multiplayer game scenario. But by looking at the way it describes this should be more efficient than using a single core to run the game server on a modern computer. I guess if this is the case there must be some kind of algorithm using by the game development community that does the same thing. What is the name of this algorithm and how can I find articles/materials about it? At the moment I find it hard to understand the algorithm. Particularly in how to deal with the cell overlapping and avoid duplicate calculations when players frequently moving between two adjacent cells. I hope this is not too programming language specific because we all need to deal with multi-core CPU and distribute the workload to improve game performance at some point.
  6. @Kylotan Thanks I will update my code with this in mind.
  7. @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?
  8. @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?
  9. 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.
  10. @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.
  11. 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.
  12. 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.
  13. 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?
  14. @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?
  15. @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.