General ES managing questions

Alright, so I’m about to start writing my first game, which is going to be a MMORPG (I know I really shouldn’t do this as a first game, but it’s what I really want to do and I like to dive into these big projects, I’ll hopefully learn a lot).

Anyways, I’m first (still, actually) orienting on how I am gonna set up the foundation of it because I’m working alone on this and want a way to build it to something working within a ~year, and start upgrading it from there on.

One of the things I’m currently investigating is how to properly do the hierarchy of my game. I would be a lot more comfortable by using OOP hierarchy for my game entities, especially at first…but if I would do that I would likely need to change pretty much all game code when the day comes I really do need an entity system, right? So I’d like to do this with ZAY-ES from the start…

I’ve looked at all the links & examples on ZAY-ES and I’m pretty sure I get what you’re supposed to do / how it works, but I’m still not exactly sure how you would properly link an account, or anything else that can be saved, to an entity? For example, I get that an entityid that represents an arrow is only there for a little while, and when another arrow is shot…a new entityid is created. But how does this work for characters that are linked to an account? Is a new entityid created when the player logs on? Or is the same entityid from the previous session reused?

This related to the previous question, but I was planning on having a management system (web based) that can control things in the game (give player certain skills, items etc.), how can you do this using an es? An answer to the previous question probably answer this one already though…

Also, as an entity system can potentially create A LOT of new entity’s every second, how would this perform in a multiple server setup, where accounts can log in on different servers (not at the same time though, ofc)?

  • ignore this post lol

You just create a new entity and via the components you can identify it. So a user logs in, you load his user name and attach a PlayerComponent with the name == username or something to that extent.

And, by the way, here is the entire expense of creating a new entity:
nextEntityId++

…that’s it. That’s really all Zay-ES does internally to create a new entity.

Create all you want. It costs nothing unless you set components to it… and you’d do that even if you were reusing an entity.

If your entity IDs are persistent (ie: saved to the database, ie: you are using the persistent version of the ES) then you can have one entityId per player, per account, whatever. You don’t need to give the player a new entity ID every time they login as long as you can lookup their account info again and find it.

Thanks for your answers,

From what I understand from them I can choose to either load seperately stored account data - where components are recreated at login based on that account data, or choose to only save the entity id the player used, and load all components back using that id when a player logs in. Although the first solutions is ideal to manage things in game from a website, it would be a huge maintenance job as for every extra component I create, I have to add ways to save and load it back to/from the account data…

I think I’m still a bit confused on the concept but it seems like reusing the entityid would be far less maintenance, and a better option for me…although making highscores on a website etc. seem alot harder as I’d have to search a huge table for entityids that are players…find their current components and read their skills from those…in that way the first solution is a lot easier as you’d have access to the data by property…

About those incremented entityids, if there are multiple servers and ZayES does the nextEntityId++ on each one of them, based on the same database, how can upi get them to not interfere with each other? Surely they’re gonna create the same ids right? And if they’d have to communicate with a database to find out their next available entityid for every arrow, bullet, npc that is created…well that can’t go well right?

The only purpose of the id is that the entities are different, you do everything else via component data. I don’t get your fixation on the id really.

@normen said: The only purpose of the id is that the entities are different, you do everything else via component data. I don't get your fixation on the id really.
If there are multiple gameservers running simultaniously with a shared database, the entityid's that are being generated (by every server) are going to be the same...unless you communicate with the shared database for the next available id...but with so many entities created per second that can't possibly work well
@reveance said: If there are multiple gameservers running simultaniously with a shared database, the entityid's that are being generated (by every server) are going to be the same...unless you communicate with the shared database for the next available id...but with so many entities created per second that can't possibly work well

You will need a different ID generation scheme in this case. The rest of your code won’t need to change, though. That’s why the EntityIdGenerator is for… easiest way would be to give each server its own ID prefix. 8 bits out of 64 isn’t much and will let you have up to 256 servers.

But really, you have a better chance of winning the lottery than of actually completing an MMORPG. (Even Blizzard can’t manage to do it anymore.) So worrying too much about multi-server scalability before you’ve even really started is putting the cart way before the horse. You will probably rewrite your game 3 times by then, anyway, for 100 different reasons.

While we’re on the subject of accounts, I wouldn’t use entities for accounts at all. You are better off with a regular database for account management so that you don’t have to instantiate game code just to reset someone’s password, etc… You can have standard web apps that manipulate it and so on. The account can store the entityID of the player character (they may have more than one character, after all)… and potentially any game-related account data could go onto a ‘player’ entity. Account management itself should be completely separate from the game objects.

So then if your ‘multiple servers’ are really separate game instances (like different shards or whatever) then you don’t even have to worry about synchronizing the entity databases. Just store the server + entityId of each character in the player’s account info so that when they join that server again you can find the right entity ID.

1 Like
@reveance said: If there are multiple gameservers running simultaniously with a shared database, the entityid's that are being generated (by every server) are going to be the same...unless you communicate with the shared database for the next available id...but with so many entities created per second that can't possibly work well

Again, you don’t separate entities by the entity ID, just by the Components. You wouldn’t try to make all java Object IDs to be the same across servers would you? You’re fine if your objects have the same DATA so you can work with them and assign them to the correct ones on the other computer. That is things like user name etc., maybe even a user ID but that would be Component data as well, not the actual entity ID.

@pspeed said: You will need a different ID generation scheme in this case. The rest of your code won't need to change, though. That's why the EntityIdGenerator is for... easiest way would be to give each server its own ID prefix. 8 bits out of 64 isn't much and will let you have up to 256 servers.

But really, you have a better chance of winning the lottery than of actually completing an MMORPG. (Even Blizzard can’t manage to do it anymore.) So worrying too much about multi-server scalability before you’ve even really started is putting the cart way before the horse. You will probably rewrite your game 3 times by then, anyway, for 100 different reasons.

While we’re on the subject of accounts, I wouldn’t use entities for accounts at all. You are better off with a regular database for account management so that you don’t have to instantiate game code just to reset someone’s password, etc… You can have standard web apps that manipulate it and so on. The account can store the entityID of the player character (they may have more than one character, after all)… and potentially any game-related account data could go onto a ‘player’ entity. Account management itself should be completely separate from the game objects.

So then if your ‘multiple servers’ are really separate game instances (like different shards or whatever) then you don’t even have to worry about synchronizing the entity databases. Just store the server + entityId of each character in the player’s account info so that when they join that server again you can find the right entity ID.


Thanks for all the info, it makes a lot of sense to use a prefix for every server using the EntityIdGenerator and the way you described handling accounts seems to be exactly what I was looking for!

And yeah, I know I’m thinking way too far ahead in a practically impossible goal, but it’s just a way for me to decide what to use in the foundation of the game in order to hopefully save a few total rewrites :p. And the worst case scenario is that I’ve gained quite a bit of knowledge about game development and maybe even make up my mind about following an education in game development in the process…so I don’t have that much to lose :stuck_out_tongue:

@normen said: Again, you don't separate entities by the entity ID, just by the Components. You wouldn't try to make all java Object IDs to be the same across servers would you? You're fine if your objects have the same DATA so you can work with them and assign them to the correct ones on the other computer. That is things like user name etc., maybe even a user ID but that would be Component data as well, not the actual entity ID.
I'm not trying to separate entities by id, I was worried that different servers would generate the same entityid's because they're running at the same time, but pspeed's answer explained exactly what I was worried about. Sorry if I wasn't clear..

Well, in a MMO the hardest part is NOT datas management. This is a pretty easy part, i could do it without too much problems. The network part itself is likely not hard, but very very ugly, cause you need to optimize it a lot.

No, the in a MMO the hardest part is … content.
Content is : music, sound effects, 3D models, level design, animations, textures, quests, story, dialogs, voices, icons, abilities … yeah, you got the idea. All of this doesn’t require a computer scientist at all, you will use artists.

And, believe me, “content” is the thing that will stab your game all the time.
The solution to this is : keep a very clean design (dirty things involve details, and details mean more work), do a lot of procedural generation (it will give to your game a pseudo-content, it’s better than nothing), have a network part (so you get a chance that people will keep playing your game not for its content but for their friends), a plugin system (so people can create content themselves AND you’ll be able to split your game into several projects and maintain a good separation between parts), have something original (don’t do a minecraft-clone, even if you manage to have a perfect clone people will keep using minecraft instead of your game) and make sure that your game is always fun (there is a LOT of games out there, and a lot of free games).

DON’T do a MMO. And DON’T do an rts (just sayin … )
And understand me : i am not sayin that you’ll not be able to do the programmation part. I say that even if you can re-create a wow-like game engine you’ll have no content to put on it.
Except if you are an omni-skill artist.

@bubuche said: Well, in a MMO the hardest part is NOT datas management. This is a pretty easy part, i could do it without too much problems. The network part itself is likely not hard, but very very ugly, cause you need to optimize it a lot.

No, the in a MMO the hardest part is … content.
Content is : music, sound effects, 3D models, level design, animations, textures, quests, story, dialogs, voices, icons, abilities … yeah, you got the idea. All of this doesn’t require a computer scientist at all, you will use artists.

And, believe me, “content” is the thing that will stab your game all the time.
The solution to this is : keep a very clean design (dirty things involve details, and details mean more work), do a lot of procedural generation (it will give to your game a pseudo-content, it’s better than nothing), have a network part (so you get a chance that people will keep playing your game not for its content but for their friends), a plugin system (so people can create content themselves AND you’ll be able to split your game into several projects and maintain a good separation between parts), have something original (don’t do a minecraft-clone, even if you manage to have a perfect clone people will keep using minecraft instead of your game) and make sure that your game is always fun (there is a LOT of games out there, and a lot of free games).

DON’T do a MMO. And DON’T do an rts (just sayin … )
And understand me : i am not sayin that you’ll not be able to do the programmation part. I say that even if you can re-create a wow-like game engine you’ll have no content to put on it.
Except if you are an omni-skill artist.


Yeah you’re right about a lot of those things, but just because a game is of genre MMO doesn’t mean I plan on having as much content/assets as an AAA MMO…I mean I’m a dreamer not an idiot xD

Nah, but I was planning on relying on generated content quite alot for the environment, and make the foundation quite bare regarding models etc…but I’m still not quite finished on the concepts for the game. Thanks for your concern and advise anyways :slight_smile:

For the ids, I use following scheme

[java]
final long timePart = Timer.getRealTime();
final long directPart = EntitySystemCore.pack(this.nodeId, this.instanciateId.incrementAndGet());
new UUID(timePart, directPart)
[/java]

Nowe you might say uuids are impractical for networks, and you are right, but I plan to use serverlocal ids for network that are shortened as much as possible.
-> Also pro you cannot memory scan for an id to find your enemy clan members ect.

1 Like
@reveance said: Thanks for all the info, it makes a lot of sense to use a prefix for every server using the EntityIdGenerator and the way you described handling accounts seems to be exactly what I was looking for!

But note: you only need to worry about this if you are actually trying to distribute the same game world over multiple servers… and then you have a bunch of other issues to deal with since Zay-ES currently does not have a federated back end at this point.

1 Like