Hi!

[tedsta]

First off, thanks for all the code and well written blog posts! I love these hexagonal planets, and I'm not geometrically-minded enough to have ever come up with this.

A friend of mine (3D artist), and I are working on a game together, just for fun. I've been using your code as a base. It's going to be a 3D version of a 2D game we made several years back (also just for fun). Here's the premise:

Cross between third person shooter and RTS. Networked multiplayer. Each player has a hero which he controls using WASD and mouse to aim. You can build buildings, and from there construct minions. For now we want to keep it simple with just 2 unit types - miners and fighters. Planets will have some natural resources that you need to mine to build more structures and minions. You can press left ctrl to disable mouse aiming so that you can select and command your units/structures. Conquer the solar system!

So far all I've done is made a third person camera and got the player to rotate smoothly while still maintaining the cell-based turning/movement that you have set up. I think for smooth movement, I will interpolate position between cells. Movement is slightly awkward with smooth rotations, because you walk to the cell that you are "most rotated towards", so it can feel a little strafe-y if you are not facing directly toward the cell you will move to. But I think it feels fine enough.

Check out a video of what I have so far

Anyway, I'd love to collaborate, even if only just to help myself stay up-to-date with your progress on this.

[jeffparsons]

Hi, @tedsta!

Thanks for sharing. Your game sounds really cool, and is exactly the kind of thing I hoped PlanetKit might be useful for.

Some of the fairly under-developed game ideas on my list are:

• Block Dude in 3D, with chasms you need to build across, etc. -- this is what I'm trying to build first.
• Tower defence plus heroes, where you need to work together to protect some central structure from ever-growing waves of mobs.
• A 3D re-make of a simple 2D game I made in high school, where you use blocks both to build your base, and also to throw at each other.
• Some kind of multi-planetary RTS.
• A minimalist Kerbal Space Program rip-off with a stronger focus on setting up a base on other planets, rather than building a spaceship capable of getting there.
• Foolishly-ambitious MMO with a strong focus on being able to build stable social groups, townships, defences, etc.

So I think our goals are pretty well aligned!

I have a rough roadmap for PlanetKit in my head, but a lot of it is un-ordered. Some of the main things on my list are:

• Arbitrarily large planets. This initially needs some smarter handling of the idea that not all chunks will always be loaded, and a system to prioritise keeping chunks close to the player loaded.
• Saving/loading chunks.
• More interesting and pluggable terrain generation.
• Properly "lib-ify" PlanetKit, so that it's easier to build new components and systems on top of PlanetKit to build a game, rather than needing to fork it for even the most basic applications.
• Network support. (Presumably via tokio.) I'm going to make it kinda decentralised from the ground up, with a central owner of the world being a special case. I'll need to write something more detailed on this for my justification to make any kind of sense. 😄
• Hierarchical coordinate system, to support real-scale universe with multiple planets.
• Rigid body physics, to support entities with movement not constrained to the grid. I'm going to try using nphysics for this; as far as I can tell from a distance, it looks really well made, and perfectly suited to my needs!
• ...things I've forgotten right now.

I'm thinking it might be helpful if I wrote up a proper/detailed roadmap, so that other people like yourself could get a better idea where I'm going with this, and see where our goals are naturally aligned and there might be room for collaboration, and where we're more likely to want to keep parts separate.

My initial goal is to get a playable "Block Dude" up and running, but after that I'll definitely be open to having my priorities influenced by what other people are working on, too. 😎

[tedsta]

Sounds like you've got a lot of cool game ideas! Maybe Kerbal Space Program can merge with MMO :)

It's great to hear you're planning movement not constrained to the grid. I was planning on seeing how I like faking smooth movement with a cell-based movement system, and if it didn't cut it I was just going to use ncollide as I don't need full on physics. Perhaps we can make pluggable movement systems.

I'm actually really interested in a pluggable game networking framework. Like generic client-side-prediction and error correction. User could specify their own structs for player input, and object states, and their own function for the world update. The framework would take care of rewinding, resimulating, error correction, etc. I'd love to collaborate on this. Not sure what you mean by "central owner of the world", though. This networking system is what I plan on working on next.

Latest progress: basic integration of wavefront_obj crate with your render system:

That model is our first 3D character from a christmas themed FPS we made back in high school.

Looking forward to playing Block Dude!

[jeffparsons]

This is really cool! Are you willing to share your code? Totally fine if not, of course; otherwise I'd be pretty silly for picking a permissive license for this. 😉

I am interested in all the networking feature you mention but, to be honest, anything beyond really basic "proof of concept so you can play around" networking is way in the distance for me.

Regarding pluggable this, and pluggable that, I hear you, and this is exactly what I want to do. I imagine getting up and running with PlanetKit eventually being a case of copy+pasting some example/tutorial code that looks closest to what you're trying to achieve, mixing and matching off-the-shelf systems to get a bit closer, and then making your own systems + components to fill the gaps that implement the bits that are special to your game.

Not sure what you mean by "central owner of the world", though.

I'll try to explain it quickly without going on a long rant. Imagine 30+ peer nodes together hosting a Minecraft-style game, with no need for a central server. They would decide through consensus (https://raft.github.io/ maybe) which peers own which part of the world. Kind of like a normal clustered server but with different primary nodes throughout the physical world. It's a very imperfect design, but it might be good enough most of the time for communities to host really big worlds without any individual contributor needing to commit too many resources to the project, and with people coming and going over time without needing to tear the whole thing down.

[tedsta]

Are you willing to share your code?

Totally, I was just too lazy to publish my changes. TBH I never even forked it until just now :P Very minimal changes so far.

https://github.com/tedsta/planetkit

Let me know if you want the obj file I'm using.

[francesco-cattoglio]

I'm here to say hi as well! I am very curious about your library, having attempted something similar myself looooong time ago. If I had small questions or wanted to discuss a bit with you, would I be able to find you on #rust-gamedev IRC channel? (or anything similar)

[jeffparsons]

Thanks, @tedsta. I'll get around to integrating the wavefront_obj stuff on master "soon". 😄

[jeffparsons]

Hi @francesco-cattoglio! Thanks for dropping by!

I very rarely hang out on IRC etc.; I'm sometimes on Gitter, but not much.

A better bet would be to ask stuff directly here; I'm happy to use GitHub issues as a "poor man's forum". Feel free to open an issue for even the smallest of questions, or the most ambitious of proposals. 😃

[jeffparsons]

@tedsta I've just pushed a change that makes the coordinate system hierarchical, and uses that to render from a camera floating somewhere behind the player.

I'm guessing this will totally bust up your branch. But you should be able to get back to somewhere sane by giving each of your Spatials a parent, and specifying their transform relative to their parent. Not sure how it'll interact with the way you're doing your camera...

Let me know if you run into trouble. Alas, breakage is going to be part of life for now, but I'm keen to know what sorts of merge conflicts have been the most annoying to resolve in case there's something I could do to mitigate them.

For now I think I'm just going to draw inspiration from some of your changes rather than trying to merge them. Otherwise we'll probably just both end up frustrated as we try to go in different directions and prioritise different things. I do still have the goal of "lib-ifying" this better as soon as possible to increase the chance of our being able to build on a common base rather than forking forever.

[jeffparsons]

@francesco-cattoglio I'm also very happy to answer emails, however short or long they may be. jeff@parsons.io

[tedsta]

@jeffparsons cool thanks for the heads up. The biggest merge conflict happened when you moved all the system registration stuff out from app.rs, but it was for a good cause :)

I'll probably switch to your camera system. I'm (slowly) working on collisions now using ncollide. I'll need to figure out a way to keep track of the chunk each player is over so I only have to check collisions with the chunk mesh(es?) the player is over.