Day 32 - Serious Problems, Serious Design

WARNING: complicated stuff ahead not properly explained but with pictures ok not really picture but diagrams and they are complicated too for non programmes sorry lol did you read this or not trololo :-)

Alright I got that primitive prototype with some stuff going using a simple lolphysics.
But my lolphysics won't be able to do what I want it to do.
I want players to be able to stack random objects to form makeshift barricades, Zombies to smash said barricades, throwing crates at bikers from the rooftop to smash their heads by proxy and all that jazz. And possibly chopping zombies arms and heads off.
So no lolphysics. Sorry, I liked you, but you're not good enough. (acutally I'm not good enough to make it good enough eh)
So I'll use jbullet which by pure random luck conveniently comes wrapped in jme3. Omagad. It works fine I can very easily make crates stack and bounce around and its of course much faster than my lolphysics while doing more things.
Hey, didn't I also wanted multiplayer? Lol.
Ooook.
Time for some serious design. I coded relative crap fast to get things going and test if jme3 was suited for procedurally generated maps and if I could code threaded chunks and collisions in a box world, now onto more serious stuff.

Game Design : Serious Business

STANDARD OOP

Example Standard OOP Design : game types ~ classes

This is more or less what I currently have.
And it won't work.
Or should I say it will work but will quickly become messy not doubt about that. I could insert more data-driven behavior like I did in RS1 to flaten the hierarchy and allow a bit more flexibility, but it won't just do it.
I also intent/hope /pray to re-use most of RS2 engine for another game, which won't necessarily have things as specific as Backpacks or Undeads. Nor Undeads with Backpacks.


ENTITY - COMPONENT - SYSTEM
It's all the craze. I won't write an article on that, there are plenty out there. This is a good start point, plenty of links. Here's my current take on it.

Example Entity Component System

MY PROBLEM : ENTITIES ID IN CLIENT-SERVER
I got my hands dirty by prototyping a couple of lolentitysystems to understand the challenges in designing and using one and then tried using established frameworks like Artemis.
They look good, but like most of these frameworks I could get my hands on it gets a bit less easy when you have a client-server architecture : how do you ensure one there is no duplicate entity ID between clients and servers, and more importantly you can't re-assign an ID to an entity once created, there is only once source of creation and you can't insert arbitrary foreign ID.

- Solution A : the server is authoritative and the sole source of IDs. When a client wants to spawn an entity, it must ask the server to get an ID. That's 100% reliable.
But: a player fires its bow, it must create a flying arrow, so it asks the server for an ID. That's 50-100ms latency at best before the arrow actually appearing on the client. The lag is for other clients, but not for the player who fired the shot. Image you play single-player and have a 100ms latency on all your shots. Ugh.

- Solution B : map client local entity IDs to server entity IDs. Allows clients to create entities when they need to, but only the server is a reliable source of global IDs and there must be a map between local IDs on the client and global IDs on the server. And on the other way too.

Then you have solutions in between. For instance, you could create a temporary entity on the client and ask for a proper ID to the server. In the meantime the client can shoot the arrow with no lag, but it exist only on this client. Then when you get a server answer the client must re-assign the arrow ID to the correct one provided by the server. Mmmh. But then what happens if in the meantime the server sends you an entity with an ID the client has assigned to his arrow? Mmmmmmmmh. Lots of re-allocation of IDs and ID collision management to do.

I'll try solution B. We'll see how it goes.

Entity UID between Clients and Server

Using classes diagram for what they are not supposed to be used for and that's a long caption hope you read it kthksbye

Good luck me.

PS: diagrams made with NClass. You have ArgoUML too, but I prefer NClass for rapid loldesign.
End of post.