How would you architect this? [General Help]

Ok, so Ive already had one thread which shed some light on the problem but I’m still a bit stumped on how to architect my game.



So! Oh wise and genius jME3 developers, how would YOU start?



I am trying to create an MMO FPS in space, specifically in the Sol System. I want it to be a seamless open world(don’t worry about landing on planets at the moment). Each client is a person, and can go in and out of airlocks at will.



Think of yourself as a single person actually flying space ships.

How would you start?



I am a skilled developer, just new with this engine and some of its architecture is a bit fuzzy to me. I am well versed in a wide array of data structures, just not necessarily how to leverage them towards a 3d game, so please be as specific as is reasonable.



Now GO all you code monkeys! Fly!



(thanks in advance)

1 Like

The last thing you should start is with a MMO. Aim for the small ones first, and you won’t regret.

1 Like

Yeah, the biggest problem isn’t even the programming part but the massive player part :wink: And even if you get them, the know-how in plain old routing server tech is probably the biggest problem then… Anyway look for “entity systems”, “LOD”, moving the world around the player to avoid accuracy issues and definitely detaching world data and visual display to avoid sheer memory issues.

1 Like

Do yourself a favor and make a “Proof of concept” fist and foremost.



You could, for example, make that PoC as a single player experience or as coop. See how things evolve, how fast you learn the concepts and apply new knowledge.



Making a MMO is like climbing Mont Everest, only the most experienced should attempt it. Doing so without that experience is a recipe for disaster.

1 Like
@shirkit said:
The last thing you should start is with a MMO. Aim for the small ones first, and you won't regret.


Under normal conditions an MMO is a daunting task, however this concept plays out as an FPS more than anything else since space is so empty. I am starting small and not worrying about too many features right now.

@normen said:
Yeah, the biggest problem isn't even the programming part but the massive player part ;) And even if you get them, the know-how in plain old routing server tech is probably the biggest problem then.. Anyway look for "entity systems", "LOD", moving the world around the player to avoid accuracy issues and definitely detaching world data and visual display to avoid sheer memory issues.


Thanks for the keywords, that's been the biggest issue with the research. The way i describe what I'm trying to do usually brings no results.
The detaching world data part is what, at my current understanding, I'm struggling with the most.

@madjack said:
Do yourself a favor and make a "Proof of concept" fist and foremost.

You could, for example, make that PoC as a single player experience or as coop. See how things evolve, how fast you learn the concepts and apply new knowledge.

Making a MMO is like climbing Mont Everest, only the most experienced should attempt it. Doing so without that experience is a recipe for disaster.


The PoC is essentially where I'm starting, I've outlines three goals that will essentially encompass all the major piece needed for my game. The first is to have the Client handle updating the location of the planets for the scene graph locally. This allows for objects that arent in the immediate reference frame to be visible as applicable (such as the sun). Next the Client allows an FPS style control of the camera. This is boilerplate at this point with as many awesome tutorials jME3 has available. The third goal is to have the server have a cube somewhere that the client can find and bump into.

As far as the experience part, I agree if the person attempting it has little to no experience coding in the first place. Application states, scene graphs, physics, lighting, heck even user input can be tricky business to a beginner. However, Im pretty well experienced, and this level of complexity is pretty much what it takes to keep me interested.

Y'all are my Rubber Duckies it seems (for those that haven't heard that phrase, it refers to the Rubber Ducky in the bathtub that you talk to for advice, don't lie if you had one you'd talk to it, and in talking to it you discover your solution) as just trying to formulate a response I ended up developing a solution to my problem. Once I get the architecture working Ill submit it as an example for everyone.

hint: client, server, pseudoclient

Ill +1 the first person to figure out the architecture based on this hint ;)

Standard reading:

Source Multiplayer Networking - Valve Developer Community

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization - Valve Developer Community



Usually takes a few full readings before all of the juicy bits sink in.

1 Like
@pspeed said:
Standard reading:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

Usually takes a few full readings before all of the juicy bits sink in.


cool thanks man