I believe this is all possible with your own scripts using Anet, however it would be a nice feature to offer, so long as it is over the top of the existing low-level functions.

Don
have a great day

Through http_get_result().

@lyingmime: I think it's no problem if there are all 100 entities created. It will take a few seconds when synchronizing but thats only once when you load the level.
The only problem is, that if 100 player entities are in one level, you will have an amzingly high traffic on each client. This can be removed by implementing an update range which can be done easily with the built in features. Update range means: Only send the position updates to a client that is in a certain range.
All you need for that is vec_dist() and enet_send_skills/var/pos/ang/...


I'm already making great progress with the new features. This is what I already finished:


If you have ideas for new macros/defines, let me know

EDIT: Forgot a feature that I've implemented!

A team member mentioned a "port punchthrough"... A feature that makes sure people don't have to manually open ports when they start a server.
Would something like this be a realistic feature request?
I don't really know anything about it...

I can see lyingmime's point. I am only using the variable sending feature, and the event feature, and making my own custom ent management system because i need complete control of what entities are where, on what machines.

This is only supported by some routers, so it's not worth to implement this.



But you can do this with the current entity management. The management only does creating the entity everywhere and gives it a unique pointer so that the entity can be controlled by every participant. After that it's up to you, the entity manager does nothing to update the positions, angles, skills or flags. => you have still pretty much room to do whatever you like.
What makes your project so unique that you can't use the entity built in entity management functions? This could help me to improve it.

I don't get the point why it's needed to permanently create/remove an entity if it get's out of this "range" like lyingmime mentioned. If you don't want that this entity is visible, use the invisible flag. And if you don't want that this entity produces traffic, don't send something to the clients that don't see the entity.


This are the new macros:


Are you using such macros? What else do you think would be useful?

I forgot to post a feature that I've already implemented: - enet_send_array/skills/flags produce less traffic
I edited my old post!

Good news! Thanks to JCL I had the breakthrough for the 3DVoIP.

I think the 3DVoIP will be finished tomorrow. When it's done I will upload a demo

Dark_samurai and lostclimate,

I don't think it's a unique case. Let's take some pretty typical numbers for an MMO:

Just as a hypothetical, say you have a modest-sized zone with 1,000 player characters. And like most MMOs, there are mobs of monsters that outnumber the players, perhaps 5,000 of them. And say each player is killing a monster every few seconds. Each time a monster is killed, it is removed from every client, and each time one respawns it is created on every client. The aggregate is that ent_create and ent_remove are being sent 1,000 / 3 = 333 times per second to 1,000 clients!

Our bandwidth tally per second is something like:
1,000 spawns * 1/3 seconds * 1,000 clients = 333,000 ent_creates
1,000 kills * 1/3 seconds * 1,000 clients = 333,000 ent_removes
6,000 entities * 3/second * 1,000 clients = 18,000,000 position updates

333,000 + 333,000 + 18,000,000 = 18,666,000 updates per second.

Now, I don't know the packet sizes offhand, but ent_create is considerably larger than a position update (because of player/monster statistics, etc.), but even if we take them as equal, making the entities invisible and limiting their position updates is only part of the battle.

If we limit entity updating like you suggested so that each client is only in range of 10 other players and 50 monsters, we get:
1,000 spawns * 1/3 seconds * 1,000 clients = 333,000 ent_creates
1,000 kills * 1/3 seconds * 1,000 clients = 333,000 ent_removes
60 entities * 3/second * 1,000 clients = 180,000 position updates

333,000 + 333,000 + 180,000 = 846,000 updates per second.

Which is a lot better. Though a connecting client still has to wait for 6,000 ent_creates to transfer. If ent_creates and ent_removes are sent only to clients in range, we get:

10 spawns * 1/3 seconds * 1,000 clients = 3,300 ent_creates
10 kills * 1/3 seconds * 1,000 clients = 3,300 ent_removes
60 entities * 3/second * 1,000 clients = 180,000 position updates

3,300 + 3,300 + 180,000 = 186,600 updates per second. And a connecting client only has to wait for 60 ent_creates to transfer.

From 846,000 to 186,600 is almost another magnitude reduction even assuming the packet sizes are equal. If server bandwidth is the limiting factor, that's another 10x as many clients that can connect, the difference between capping out at 500 or 5,000 clients per server. It's a huge difference in terms of 'lag.' So it's something that every large-scaled MMO has to do.

Yeah, it can be done with ent_createlocal, but these aren't really local entities. The server needs to create a unique pointer to reference them across all of the clients.

so i'm thinking what you're after to avoid using ent_createlocal is a ent_create(ENTITY, Location, NetworkRange) - adding a range variable to all ent_creates which only gives their data to valid clients...

Interesting point- if we create a server with a million "zones" or areas we don't really want ent_create to send all init data to all clients, only the ones that are in the vicinity, and need to see it appear.

This won't take that long. Loadingtime will still be like in a normal MMO game. I would guess max. ~10 seconds or less.
I don't see a problem here.

First of all to your numbers and calculations:
I only know/played one MMORPG in my life, and this was everquest 2. The whole world was split in hundrets of small levels which only contained ~20 players.

1000 or even 100 players at the same time can't be done by an indie developer because of several reasons:
- Such a game won't be played at the same time by so much people!
- You won't have the people to test your system!
- You won't have the money to rent as much servers!
- You won't have the people to create that big world/dungeons...
- ...

And if you as indie developer want to create a MMORPG game do it like the maker of Everquest did it: Split your world into small levels/zones. Then an MMORPG can be done so easy with ANet (read the Multizones HowTo). Now you will say: If there are so much zones, there will be so much level loadings. Yes, thats true! But loading a level with Gamestudio is that fast that this won't be a problem

To the feature itselfe:
If I think more exact about this feature I think about a lot of problems that would come with it.

So my conclution: If you really have a game that will be the next WOW then writing it for yourself won't be a problem. You still will get the richest man on the earth
And for all "smaller"/normal multiplayer games, the current entity manager is ideal!


[EDIT] I'm afraid that I have less time to finish 3DVoIP today. I will post the demo as soon as I'm ready.

I have not much time for the 3DVoIP at the moment, because I'm currently working on 2 other projects. Sorry!

I did a few small things for ANet:
- All functions are overloaded now (in Lite-C). So they also except char* now.
- I removed a few typing/translation mistakes from the manual.

What I plan to do for ANet in the next time:
- finishing 3D VoIP
- creating a version of ANet that uses no threads for the enet function (only for testing purpose)
- an example of serverside movement, using the physic engine and interpolation