Friday, July 20, 2012

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.
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

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.

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

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.


  1. Maybe you should upgrade your loltechnology to rofltechnology.

  2. take a look here: and here

    Artemis have a supporting forum here, the guy behind project can provide some ideas and feedback for your project

  3. for your arrow problem: just let what the player sees be a local arrow and then let the server do all the physics and stuff for it. you dont really have to send an ID for the arrow back since it will only exist for like a secound anyway. so let the player see a local arrow and let the server send back if it hits or not

    1. But I still have to share the arrow entity between clients. Arrows can be fired in arcs and are subject to physics, so they can take a relatively long time to hit and must be visible to all players. For instance player A fires an arrow, and by random luck player B happens to cross the arrow path.

      Firing bullets is easier, they can be abstracted into a simple ray trace that instantly hit or not.

  4. Replies
    1. Looks like he's using the java monkey engine, so I'd more then likely.

    2. Dak toshtakh, tovarich kommandir!

  5. If I want to pitch ideas, will you listen?

    1. I'll read but I can't guarantee anything.

    2. well, i was thinking about the map setups, business, park, etc. and was thinking it would be cool if there was a wilderness sort of area, with little to no roads and few houses, but with the occasional farm.

    3. My goal is to have a large world map with more than one town and wilderness.
      That's the theory. In practice I'll make one town first and see if my engine can handle more.

    4. also, items like radios, to get announcements from the military. and a some other ways to get rid of your infection percentage besides those pills.

    5. TV to get rid of insanity.