caymanbruce

Members
  • Content count

    64
  • Joined

  • Last visited

Community Reputation

210 Neutral

About caymanbruce

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. Yes I go into too much detail here. I think I understand the high level requirements. I just want to experiment getting rid of the username first and then try delta encoding further. But then I was bogged down by the implementation because it is tightly related to my protocol design and the 3rd party schema tool I am using. And I am reading related topics here and there which just pop into my head but only to find they are not fit later. I think I will go with my own way for now. I try to use a dirty field in the message body to tell the client what messages are sent in the update packet but later when I use a more customized protocol I might be able to do delta encoding more easily.
  2. Sorry my bad it's not uint32 I actually initially use uint8 that's 0-255 but then I extend it to a varuint type I defined so it seems OK for now. I am drilling down the problem that I have. I think the problem is that I don't break up the packets and send them separately to be able to do the basic delta encoding. Currently I am sending everything in every update package. That's why "username" field is there. Because of what I am doing at the moment, the client learns of the entities from a normal update package, which includes other players' names. And If other entity is not on the client side, it will be created with the incoming information. Pseudo code: entityStruct = receiveUpdate(); // Receive update package from the server remoteEntity = decodeFromSchema(schema, entityStruct); // Decode the struct using a schema if !playerList.has(remoteEntity.id) { createNewPlayer(remoteEntity) // Create new player with incoming update package, which includes the username } I know, this won't scale well. So I think this is actually a delta encoding for sparse repeating fields problem. I have learned from StackOverflow.com that I can do that by sending different frames to the client. Such as delta frame and key frame. But I am using a schema technique which is similar to ProtoBuf to encode and decode my data packets, so I will need to send 2 or 3 types of information from the server at different frequencies. 3 types of information: 1) The full packet which is key frame. 2) Delta frame which contains the changes and this will be used for interpolation. 3) Maybe for "username" kind of thing that never changes? By doing this, I am not sure where I should place the "createNewPlayer" method, as different information comes at different intervals and I can't collect a full copy of the remote player info at the moment I want to recreate it on the client side.
  3. Yes suppose I am keeping some usernames on the clients for a longer period, the main thing I should do is to match usernames with incoming packages. I did mention in my post I will be searching them by ID. I just wonder how often do I need to add or remove a username from the client. When a player dies its ID will be assigned to a new player. So when I remove this player's username on the client and possibly add the new one which uses the previous player's ID, how should I deal with this? I am recycling the ID because I want to use uint 32 to reduce bandwidth.
  4. I am having this problem but I struggle to find a way to properly address it. I have a string type "username" field of the player instance that I want to send from the server to the client. Let's say there are 300 players in the game. I don't want to send the "username" too often because that will stack up the data package size both sent out from the server and received by the client. Sadly I am doing this right now and it is costly. All I want is to show the player's username on the screen of the client. It will always be on top of each player's entity. If the players are always on the client that is very easy to code. I will just send all usernames once and assign them to all the players. Done. Tricky thing is, the players are often on and off the screen when they move, which means another player will move inside of a player's view or outside of his view. So every time the client receives the data package from the server, it will try to look for the players that matches the existing usernames, if the "username" field was not sent in every update package. This will require me to maintain a data structure that frequently adds and removes a "username" value and search for one that matches the package and the client side and then display it. I may need to match the players and the existing names on the client side by using their IDs. This may seem obvious. But before I implement anything. I just want to know if there is any standard/common way to do this in game?
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. I've come across a multiplayer game framework https://github.com/jondubois/iogrid 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.
  10. @Kylotan Thanks I will update my code with this in mind.
  11. @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?
  12. @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?
  13. 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.
  14. @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.
  15. 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.