region generation sometimes begins far away from the player about chunkstories HOT 6 CLOSED

I cleaned up the PR a little bit, by removing an import I had accidentally left in, and by going back to chunkstories-api and adding back in the original aquireHeightmap() signature; that let me reduce the footprint of this PR, by keeping most calls to aquireHeightmap() the same as what they were prior to my initial version of this PR.

from chunkstories.

Hey nice. I see you're really making yourself familiar with the code base, happy to see that.

The 32 view distance is meant to equalize the playing field, no matter how the player set their actual chunk draw distance, they can at least see the rough landscape far away. This has obviously very negative effects with client side world generation, as it causes a crushing load on the user computer when he firsts creates the world ( even a high-end cpu like my Ryzen 1700 takes a good minute to do the initial computations ). This is obviously not really usable/production-ready.

It should be noted than chunk stories is meant more as a multiplayer-oriented platform, and so the local singleplayer mode is a second-class citizen, being used mostly for quick and easy debug sessions. I don't really intend it to be a part of the game, or at least not in it's current crappy form. The world generation then, is more supposed to be handled ahead of time if possible, and on a (hopefully) high-power server. I have plans for a fancier world generation including road networks that would require a full offline generation phase no matter what.

The fix you're proposing looks like it helps with the single player situation but not so much when multiplayer is involved, if two players are walking towards each other and necessitate the generation of a region in between them, one of them is bound to see drawing terrain away from him first. Now granted this isn't something that happens often. It does complexify the generation code a bit, and makes the world-loading API very client-oriented.

I do see the value of the idea behind this PR, but maybe this can be implemented as an heuristic in acquireHeightmap() by looking at the worldUser parameter ( instanceof Player ) ? As this is more of an optional/performance/user-experience improvement, it doesn't need to be exposed in the API, in my opinion.

Another benefit of doing it implicitly is that you could actually read the entire users set from Heightmap, and have an even fancier scheduling algorithm that could sort the priority of the individual chunk generation tasks based on the distance to all players who acquired that bit of the map.

Oh and I've just realized it's acquire, not aquire. Silly me without a typo detector in my IDE.

from chunkstories.

I see your points. Your suggestion about re-implementing this as a heuristic in aquireHeightmap() intrigues me; I will look into that.

I do feel like I'm becoming familiar with the codebase, although there is much ground I have not covered. I'm diving in because I'm very enthusiastic about your project. Your goals are nearly a perfect match for my own goals for a voxel game / game-engine. I've investigated at least a dozen similar projects, and Chunk Stories is the best match by far for what I'd like to see take shape.

I did gather the sense that singleplayer is sort of a 2nd-class citizen, as you put it. This is one area where my goals do diverge a bit from yours. I enjoy playing single-player survival, and I would love to help craft a really good open-world survival game. Of course, I'm not at all opposed to multi-player being the focus and the primary goal, and ultimately I do enjoy multiplayer gameplay as well, so I do not want to introduce anything that would take away from that aim.

I'll attempt to rework my update to fit more seamlessly, with these considerations in mind.

from chunkstories.

heh -- Once I opened up the files, I realized I had first attempted this in the way you suggested : as additional logic inside of aquireHeightmap(). I failed to access the Player correctly though, neglecting the use of instanceof. (I do most of my professional coding in other languages, so I don't have a deep familiarity with Java -- thanks for the hint / tip!)

Let me know if the reduced PR addresses your concerns about spreading into the API. Thanks.

from chunkstories.

My take on single player/multiplayer is that I don't want to waste resources on a feature that is basically a subset of multiplayer; I want as little as possible duplicated code for SP/MP, so always treat the SP mode as a locally hosted server, with the same rules and logic as the standalone server. If memory concerns were more relaxed, I'd simply launch a real server executable behind the scenes, but this means double the memory consumption so I've not gone that route.

If you've read through enough of the Wiki or seen it in the code, the way CS multiplayer works is that there is a "Master" and a "Slave", the master the one with the global authority, the game instance responsible from simulating everything, so WorldServer implements WorldMaster for instance. The Slave is being updated with all that information and can reply back with the status of it's controlled entity (his character). SP is just master and slave combined.

If you're really interested in making a nice single player experience, it would be actually great to have someone who can spend the time to make the supporting code not subpar and match ( or better yet, use ) the rest of the server logic. I want mods to be written fully agonistically of whether they are run on a remote server or SP, some formalization will probably be required there to make that happen properly.

Also I couldn't be happier if you decided to add plain old content, my current student job is cutting my summer time in half and the other one is likely to be heavily oriented towards finalizing my bachelor degree. Stuff like mining drops, basic crafting mechanics and even dumb mobs could really make this project feel like the massive undertaking it really has been for 3 years now !

I'll save my comments on the updated PR for it's own thread

from chunkstories.

I'm with you on this philosophy of multiplayer and singleplayer. And, I picked up on the gist of what you've described in following through the code to understand the program flow, in the process of determining how to implement what I was aiming at with this PR and the /tp PR.

I'll focus more purposefully on singleplayer as a 'mode' of multiplayer, as you put it, emphasizing the fundamental client-server / master-slave relationship.

I also have several ideas for content. In fact, I began with content ideas, but the programmer in me got a wee bit distracted by the "quick" fixes to the /tp command and region/chunk generation. ;-)

Thanks again for your detailed comments. I look forward to contributing in various ways to Chunk Stories.

from chunkstories.