(Need Help) Godot 4+ Multiplayer Seamless Open-World Chunks. Combat Latency Server Mystery? #15
Replies: 9 comments 6 replies
-
|
Notes:
All three of these test chunk games have the same navigation and number of entities yet the combat runs slower the bigger the empty field. Why is this? How can this be solved? What are the possible solutions? What will this take to solve? Please give feedback. These 3 area chunk areas all need proper testing. Please test with profiler and monitors. I am curious if the navigation is the culprit for there was an earlier test of JDungeon on itch.io with navigation disabled and it has good combat ~10-99 ms to 100-199 ms latency. The switch to Astar navigation fixed this but when tested with Astar navigation with x4 and x16 map sizes with just a bigger open area with the same amount of entities the combat slowed again. (Results: After testing with no navigation for the chunk it was found that Astar was only a tiny slowdown. Its still the raw tile map size seeming to slow down the combat and the server. Even with all navigation removed the raw big area tile size slows down the combat and server start up. Perhaps it is the server not optimized for large raw areas sizes that is potentially causing slow down with big empty tile area?) I figured out by taking off the Astar and other navigation featurea and just leaving the combat there was a very slight improvement. Yet at the big 1,024x1,024 tile map it was still 4-7 second lag from hit to damage received to the mob. So it seems that the navigation before was okay? Now I'm trying to figure out what is causing the lag with the big area? Also the server starts slower with a bigger chunk so I'm not sure what it could be? Server does not like big areas or? Any suggestions are helpful with this mystery. |
Beta Was this translation helpful? Give feedback.
-
|
From Discord Archive: Matthew — Today at 22:11 [22:16]
|
Beta Was this translation helpful? Give feedback.
-
|
Possible loads for open-world seamless chunk loading and unloading for multiplayer with server in Godot 4.2.1.NET Matthew — Today at 01:29 |
Beta Was this translation helpful? Give feedback.
-
|
Archive From Github: Test chunks link: #15 What can work for seamlessly loading and unloading chunks Godot 4+ games with multiplayer and open world construction? I'm trying to find a way to seamless load and unload chunks for a 2D multiplayer game project to make an open world with a working server using Godot 4.2.1.NET. Example: https://www.youtube.com/watch?v=uE36MVjB5-8 How can this work for multiplayer and what is needed for this to potentially work? What options can be used for chunk loading and unloading seamlessly in Godot 4.2.1.NET? Please give feedback. The chunk sizes are too small and the combat and server lags with large areas. I think seamless chunk loading and unloading is the solution in most MMORPGs and large open world multiplayer games like Minecraft and Terraria. Unfortunately there is a lack of working examples for how to implement this 20+ year old critical feature and make near-infinite open worlds for multiplayer games in Godot 4.2.1.NET. Seamless chunk loading and unloading is the solution in most MMORPGs and large open world multiplayer games like Minecraft and Terraria. This enables large open world games with multiplayer and still use relatively reasonable hardware to run the world client and server. There is a lack of examples for this so a demonstration or guide or anything that works to follow and replicate would be greatly appreciated. A proper demonstration / guide / solution would open up the community creatively and practically where people can follow the example and build upon it to make near infinite multiplayer open worlds. This will take away near exclusive game making features from competitors such as Unity and Unreal engines and make these critical world building features forever free for the entire world. As in most MMORPGs like World of Warcraft, RuneScape, Everquest and multiplayer voxels games Minecraft and Terraria and other multiplayer large open world games: When the player / client reaches a chunk border threshold (set by the developer) the closest chunks to the player load. This is done so that the systems running the game and player game field of play are seamlessly able to transition to the new chunk and unload the unused previous chunks. This creates the ability to seamlessly explore a large to even near infinite open worlds in multiplayer with using smaller chunks to keep the server and client working smoothly. There just is not an easy to find or known example of this in Godot 4.2.1.NET multiplayer. I am not sure if this is applicable this seems like a larger kind of request. Hey if it works I am all ears. Please anything that can work well would be great. There is a lack of working examples for Godot 4.2.1.NET so anything that works would be incredibly helpful. This is a world building feature and with other game engines like Unreal and Unity there are features built into the 'core' that handle this kind of serious multiplayer open world chunk loading and unloading. This would be a great addition to the capabilities of Godot engine and would make large open world multiplayer games reasonably accessible to the entire world and every large scale game could start to be practically built from the ground up in Godot. Anyone could make Massively Multiplayer Online games and the community can democratize the powerful tools needed to do this heavy lifting world building with multiplayer servers. It would make the community able to make incredible massive scale multiplayer games for this generation and all the subsequent generations after forever free." |
Beta Was this translation helpful? Give feedback.
-
|
I'm here from: godotengine/godot-proposals#9109 I agree Godot could use more and better multiplayer tutorials and examples. In fact, Godot multiplayer is an area I also lack knowledge on. I also agree Godot could use a built-in content streaming solution, right now we have to build that on our own... But it will take time until somebody makes one that is:
However, I want to point out that those 20+ years old MMORPGs that have "seamless" "chunk" loading didn't have small chunks, didn't have player to player physics (characters walk through each other), and didn't have destructible terrain (and consequently the portions of the map could be downloaded in advance). Minecraft and Terraria on the other hand fall short on the first M of MMORPG: Massive (the average Minecraft server has around 30 players, although I admit some servers can see above 1000 concurrent players). And I remind you they are NOT 20+ years old. With the caveat that I have not build one of these systems myself, I can point out what some of the old games used. First of all, for loading chunks you will want to use threading (having some threads waiting on IO operation is cheap, in particular compared to doing everything in a single thread). Since you seem to be interested in games where the players modify the terrain, you need to propagate changes to the terrain via network... So look into eventual consistency. Notice that Minecraft does not wait for players to have their chunks up to date. Anyway, from what I gather you were struggling with navigation. Since the mention of Minecraft and Terraria, I'm guessing you will not be baking navigation (because destructible terrain). So, yes, the techniques you want to use are different, and yes old games did manage this... But you don't want to look at old MMORPGs (they had fixed navigation maps, because again, terrain was not destructible) but look at RTS and City Builders, which had tons of units moving around a dynamic map. This is the idea: Your game will have a time budget to do a limited number of astar queries per server tick... So don't do more. The units that do not get an astar query right away can start moving in the general direction (and even walk around obstacles if the path is blocked) until they get their turn to run a query. You also mention that the size is a problem. You already have a kind of hierarchical space partitioning: chunks and tiles (you can have more levels). If you can store connectivity at the higher levels, you can do a short search on high level (e.g. find the path at the scale of chunks), and another search at lower level for the portion of the path immediately ahead (e.g. find the path to the next chunk according to the high level path). That way the total path you have to search is never too long. I'm not interested in a long discussion here. Instead I'll suggest you bring questions to https://gamedev.stackexchange.com/ (oh, and search there, you might find information already there because there is plenty of people who has been interested in these topics from the perspective of not using an engine/rolling their own). |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much this is what feels like a giant light gleaming in the dark for myself. |
Beta Was this translation helpful? Give feedback.
-
|
I have no idea of your goals, so I can't tell you which branch to go with. But ok, you can apply a bit of software engineering to this problem: if you have two working competing implementations, consider putting them behind a common interface so you can swap between them (either at launch or at runtime). Yes, you will have to figure out what the common interface should be (hint: it is usually more about the code that needs to use the implementations). But once you do, that common interface will be what is future proof, because you would be able to add a third or a fourth implementation behind the same interface without needing to change the rest of the project. Anyway, try to break your problems into smaller problems, at some point the problems are small enough you can find a solution, either by yourself or by asking. |
Beta Was this translation helpful? Give feedback.
-
|
https://jonathaneeckhout.itch.io/jdungeon Oh for the goal right now it is easy to play this but imagine it has seamless chunk loading and unloading. As instead of the black world boundary a new chunk loads in seamlessly. What are your suggestions and thoughts? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Oi I found some working Godot 4.2.1.NET seamless chunk system demonstrations from github .zip files that I downloaded and archive from before asking for help. I am just getting through the m now. I found two 2D ones and two 3D ones and 3D one is made voxels like minecraft. This real progress. We just have to find a way to bring this to multiplayer and save chunks. We are closing in on the solution to this puzzle. This is great! https://github.com/DennisSmuda/godot-chunking-system [2D Chunk Generator] |
Beta Was this translation helpful? Give feedback.
-
|
"chunkloaders"in github I found https://github.com/TerminatorNL/SimpleChunkloaders "Simple server-side only forge mod capable of loading chunks for online players." Its maybe not for Godot but like maybe a lead? |
Beta Was this translation helpful? Give feedback.
-
|
I am doing a from scratch build now for the multiplayer chunk system. What should I do for the server and the data and chunk storage? |
Beta Was this translation helpful? Give feedback.
-
|
Update: Zylann/voxelgame#100 (comment) We figured it out! Now its phase 3 with trying to convert the working multiplayer dynamic seamless chunk system to top down 2D. We are onto the next puzzle to solve now: Zylann/voxelgame#101 How do we make the top down 2D multiplayer branch / version of this that can run on Godot 4.2.1.NET+ Compatibility and for online web / browser game hosting (so pretty much anything everything can play this power multiplayer seamless chunk system? Requirements: A hand made and dynamic main over world map 100 areas combined with 1,024 x 1,024 tile map for an at least tile map size of 104,857,600 tiles with 16 x 16 pixel tiles at least. Perhaps double that with subterranean and interiors included to the total amount of tiles for a multiplayer seamless chunk system. The intended client / player / population / server size is to be ~2K to ~16K+ clients on one server. How can we convert the Blockygame multiplayer seamless chunk system for this forever free open source forever free goal? My first thoughts are to get just to the basics and start from a stripped down 2D array. Yet I have to do this properly to keep the dynamic multiplayer seamless chunk system intact and future proof for 2.5D and 3D games; when they are ready to be made in subsequent order. I must seek guidance to do this properly and make a beautiful work for the community to be empowered with too for making massive multiplayer games. I call this whole open source forever free community dynamic multiplayer seamless chunk system Infinite Worlds. |
Beta Was this translation helpful? Give feedback.
-
|
Zylann/voxelgame#103 How can entities and player storage work for this demo? Are there any examples or prototypes? How can entities and storage system like chests stored in chunk data like minecraft? Bonus for account linked storage like M.M.O. player inventory and banks / minecraft player account inventory with shulker boxes. |
Beta Was this translation helpful? Give feedback.
-
https://jonathaneeckhout.itch.io/jdungeon For the goal right now it is easy to play this but imagine it has seamless chunk loading and unloading. As instead of the black world boundary a new chunk loads in seamlessly. What are your suggestions and thoughts?
Update: https://github.com/WithinAmnesia/ARPG/tree/ARPG-Infinite-Worlds Here is the 128x128 with 32x32 pixel tile chunk to test. How to start: Run 3-4 instances in the debug -> run multiple instances. Then run the first instance as Gateway. The second instance should run as Server. The third instance as Client. Make an account then log in. The fourth and more instances can be for client multi-boxing testing and work the same as the third instance.
My initial testing seems to feel even faster combat with the 128x128 chunk. This 128x128 chunk has the same amount of entities as the 256x256 chunk. For I moved all of the entities over into the 128x128 chunk. This 128x128 chunk is a good test for using the Infinite-Worlds using the BinarySerializer for Godot 4.2+ from Theraot: https://gist.github.com/theraot/31515e28e2d8bfea33f6c6d5bcd852f6 . There needs to be some testing how to make the chunks seamlessly load and unload.
Beta Was this translation helpful? Give feedback.
All reactions