Marketplace Multiplayer Large Player Scaled Servers

[Rhynedahll]

Ah like that,

That's something that, to make a universal uniform around, is going to be near impossible as you can't expect everyone to follow those guidelines.
Besides that there's no built in way to connect it through Json or any other form to connect to a outside DB, but it's add-able by the buyer.

Yes, indeed. These are the fundamental limitations of UE4. It's a game engine designed for small games and little effort appears to being expended by Unreal at the moment towards adding larger multiplayer functionality.

I would suggest that if all creators worked in a voluntary fashion to expose data in a consistent way, (which they would of course have to agree upon in advance, not an easy thing) then implementing the db functions would be a simple matter instead of having to tailor the solution for each purchased system.

My impression at this time is that the majority of Marketplace content is aimed at the casual hobbyist who is creating a single player game. If that is the case, most creators would see no point in extending their system functionality to include MMO type play.

It does save your stats and reputation based on your User ID, so as long the system stays on one server the player will always have their own settings.

Unfortunately, our project will, until something better shows up in the server department, have zones on different dedicated Unreal servers. Our test map set up is a single player map (where everything of course works fine), then an exterior landscape to which all the players join at will, and finally a dungeon map which players can elect to enter. The latter two are on severs on different machines. Because of the inherent player limits of UE4 dedicated servers, we expect that this basic setup will have to expand to perhaps a dozen servers.

We have encountered problems with systems that we have bought from the Marketplace. Clients running on a single pc play nice, but clients on different PC's don't.

We have to save and load all character data at each server swap and it appears that your stats would also require this?

[eXi]

UE4 has a Map-based unique ID. Switching Map creates a new ID. Since UE4 Servers only support one UWorld aka one Map, you need
multiple Servers for multiple Instances. If you place a Subsystem like Steam into the backend, you'll have a UniqueID that stays the same over Map changes
as well as a Cloud System where you can save user files.

For an MMO type Game, it would be recommended to build up your own Database System and maybe even using a different Server Framework to support multiworlds.

This is no issue with the Marketplace Projects, but a limitation to the UE4 Servers.

Also UE4 is directed at "causual hobbyists", but not only at the Single Player ones. The Multiplayer side of UE4 is huge and really strong. Just not suited for MMO out of the box.

[Rhynedahll]

UE4 has a Map-based unique ID. Switching Map creates a new ID. Since UE4 Servers only support one UWorld aka one Map, you need
multiple Servers for multiple Instances. If you place a Subsystem like Steam into the backend, you'll have a UniqueID that stays the same over Map changes
as well as a Cloud System where you can save user files.

This clarifies my suppositions. Thanks. We are unlikely to venture into Steam any time soon.

For an MMO type Game, it would be recommended to build up your own Database System and maybe even using a different Server Framework to support multiworlds.

There are some projects in the works that we are waiting on that promise this functionality. At the moment, we're just working on a demo MUD that will use UE4 standard parts.

This is no issue with the Marketplace Projects, but a limitation to the UE4 Servers.

By default, a limitation that exists in the UE4 servers also exists in the Marketplace Projects that extend from them. My point here is that if MMO features are to be added, they will have to be added by the content creators themselves or the task falls to the end user. When buying content, we would prefer it to be as close to our needs as possible. While I understand why content creators would not be inclined to do this, I can still wish for it.

Also UE4 is directed at "causual hobbyists", but not only at the Single Player ones. The Multiplayer side of UE4 is huge and really strong. Just not suited for MMO out of the box.

When you use the term "multiplayer" you mean small scale games that handle <64 players. When I use the term "multiplayer" I mean 500 players. So while the Multiplayer side of UE4 may be huge in terms of features, it is not huge in terms of actual size.

While UE4 may be directed at "casual hobbyists", it does have commercial potential and there are indications, at least to me, that Epic welcomes larger scale commercial projects.

[eXi]

My point here is that if MMO features are to be added, they will have to be added by the content creators themselves or the task falls to the end user.

The Marketplace Creators can't create them. We are limited to Blueprint Only or C++ Plugins. And I don't know how much third party stuff the C++ Plugins allow.
So this is not up to the Content Creators, but to Epic Games itself. If you want the Engine to support more than 64 Players per server, request that at Epics door, not at ours.

When you use the term "multiplayer" you mean small scale games that handle <64 players. When I use the term "multiplayer" I mean 500 players. So while the Multiplayer side of UE4 may be huge in terms of features, it is not huge in terms of actual size.

I know. That's why I said it's not suited for MMO type games.

Epic is open to all kinds of games. As said, if you want MMO features, or "large amount of players" features, then post a request in the feedback and request forum of Epic.
Looking back the past 2 years, I don't see this large scale coming any time soon.

You will be forced to implement the Server backend yourself.

PS:

When buying content, we would prefer it to be as close to our needs as possible.

Marketplace content is directed at a bigger scale. A lot of people should buy this. If you need a personalized content package, you should try contracting a programmer (:


EDIT: I moved this to a new thread in the Feedback forum to keep PandaStudios thread clean.

[Rhynedahll]

The Marketplace Creators can't create them. We are limited to Blueprint Only or C++ Plugins. And I don't know how much third party stuff the C++ Plugins allow.
So this is not up to the Content Creators, but to Epic Games itself. If you want the Engine to support more than 64 Players per server, request that at Epics door, not at ours.

I haven't requested changes in the Engine, only the content. All content that uses data needs a way to easily send that data to a db. All content creators could add this feature to their content because it does not depend on the engine.

I know. That's why I said it's not suited for MMO type games.

This was a given.

Epic is open to all kinds of games. As said, if you want MMO features, or "large amount of players" features, then post a request in the feedback and request forum of Epic.
Looking back the past 2 years, I don't see this large scale coming any time soon.

We learned this early on.

You will be forced to implement the Server backend yourself.

No, actually, we will eventually purchase it, as someone is already working on it. We aren't creating a project for fun. We're going to assemble one from off the shelf parts. If this plan proves not viable, then we'll change direction.

PS: Marketplace content is directed at a bigger scale. A lot of people should buy this. If you need a personalized content package, you should try contracting a programmer (:
EDIT: I moved this to a new thread in the Feedback forum to keep PandaStudios thread clean.

By definition, Marketplace Creators are, at least in terms of systems as opposed to artistic content, programmers. Therefore, if I reply to a Marketplace Place thread, I am contacting a programmer.

As an aside, the tenor of your suggestion seems to imply that you believe that I am not a programmer. At least technically, I am, as I have a degree laying around here somewhere ....

[CriErr]

I think by those words @Exi means if you want personalised package, you should hire personal programmer. Because marketplace creator making a product as he want it to be and your rights as a buyer to buy it or not to buy. Im not saying you are the case, but i have seen a lot of people, buying marketplace product and expecting the Seller to do stuff for them, to make the product fit their personal need.

[Rhynedahll]

I think by those words @Exi means if you want personalised package, you should hire personal programmer. Because marketplace creator making a product as he want it to be and your rights as a buyer to buy it or not to buy. Im not saying you are the case, but i have seen a lot of people, buying marketplace product and expecting the Seller to do stuff for them, to make the product fit their personal need.

I have, as a matter of fact, not requested a "personalized" package.

It is not unreasonable or improper to ask any producer to add features to his product. Nor is it unreasonable or improper for that producer to answer "No."

Having had some experience in this area, I can tell you that content, this not being limited to gaming content, sells if it proves useful/productive/entertaining to the target audience. That means that, in order to increase unit sales, that content must often be altered or adapted to suit that audience.

While every producer certainly has the right to say "This is my product. Use it as is or leave it." unless it is whizz bang to start with, I have seen such content
left more often than taken.

[eXi]

It's certainly true, that specific updates will make products sell better, but regarding the MMO features stuff, we really
can't do sh*t about it. I would love to have a Server with multiple worlds etc and I already tried different approaches:

For example giving every Actor a NetID Variable and overriding the "NetRelevantFor" function, to only replicate Actors
to other Actors that share the same NetID. With this you could have multiple parallel matches on the same map.

But I kinda doubt that, first, the Server can handle that with too many players and, second, that this will solve the issue of
a single Map on a Server. I don't even know if that's legit approach.

The stats pack, in which this discussion started, can't add databases or the varest plugin to the project. We are not allowed
to add such stuff to Blueprint Submissions. So she's forced to use the build in databases for smaller scaled game genres.

And even if we were allowed to add that, we still can't fix the ONE world per Server issue, that still needs you to run ONE
Server, per instance of what ever level you need.

You certainly know "Borderlands". That's a UE3 game iirc. In that Game, you always need to travel with your teammates to the next zone.
Exactly because there is only one level for the ListenHost. He can't run a second map while the teammates stay on the old one.

This way of handling servers exists for a longer time and i doubt that Epic will change their server any time soon.
That's why I suggested you and other large scale game devs, to check out other Server models and only use UE4 for the Client site.

PS: The only hope we have would be the Paragon Team to shed some light on their Servers, because I doubt they use one Server per Match.
At least not the one we know as Dedicated Server.

[Rhynedahll]

It's certainly true, that specific updates will make products sell better, but regarding the MMO features stuff, we really
can't do sh*t about it. I would love to have a Server with multiple worlds etc and I already tried different approaches:

I am resigned, until something better shows up, to having multiple dedicated servers to handle the several zones in our proving ground demo.

May I ask a question in relation to your experience with dedicated servers?

Our current plan is to generate and store on the db a unique player identifier and to use that to manage and index all external player data. The Unreal servers will of course continue to manage player movement and so forth. Are you aware of any inbuilt Unreal server limitation that would prevent individual players from moving freely from server to server and back again?

[lunyBunny]

...Also UE4 is directed at "causual hobbyists", but not only at the Single Player ones. The Multiplayer side of UE4 is huge and really strong. Just not suited for MMO out of the box.

Hi [MENTION=14476]eXi[/MENTION]

About EU4 be directed to hobbyists as you have previously Mentioned

Paragon is an MMO????????????
How does it work Please?????????????


-luny

[DotCam]

Hi [MENTION=14476]eXi[/MENTION]

About EU4 be directed to hobbyists as you have previously Mentioned

Paragon is an MMO????????????
How does it work Please?????????????


-luny

Is this really necessary?

Paragon does not come with the engine download, they have customized the base engine to their games requirements. Like eXi said, it is not suited for an MMO "out of the box", but can be modified for most use cases.

[eXi]

I am resigned, until something better shows up, to having multiple dedicated servers to handle the several zones in our proving ground demo.

May I ask a question in relation to your experience with dedicated servers?

Our current plan is to generate and store on the db a unique player identifier and to use that to manage and index all external player data. The Unreal servers will of course continue to manage player movement and so forth. Are you aware of any inbuilt Unreal server limitation that would prevent individual players from moving freely from server to server and back again?

Well, what do you call freely? You would need a backend System that provides the Players with the IP of the new Server to move to.
After that, you can simply let the Client travel over to the new Server and that Server, on PostLogin or so, requests the Unique ID and fills in the data again.

[TheJamsh]

I wouldn't call Paragon an MMO... it only supports up to ten players per-match.

[lunyBunny]

I wouldn't call Paragon an MMO... it only supports up to ten players per-match.

Yes [MENTION=155]TheJamsh[/MENTION]

You're right about Paragon.

And what to say about Realms? When I tried to analize a WoW server a few years ago I realized that it are distributed in the form of something called Realm, which probably could supported a number of 100 users or more by Realm, one user could choosing one disponible Realm from a list containing many other Realms. I do not know if this has anything in common with cloud system mentioned, but from what I understood it works the same way that a Hard Drive in Raid Partition works. Each Realm located on a different server or in an same Server is an exact copy of the World.

[iniside]

I've been thinking about this for few days now. I have come to few points.

A). Zonning is pretty obvious choice. But even if server can handle no problem 64 players alone.. what about AI ? Moving, pathfinding, actions of AI can easily eat up entire server power.
B). So even if world will be split into instanced zones, splitting processing into multiple cores/machines still will be needed to handle rest of the world. Especially on massive scale.
C). Sharing single map between multiple servers is impossible with how unreal works by default.
D). What is really needed is load balancing backend, which will coordinate various servers working over specific task. for example AI simulation. Backend would send messages between multiple servers, which work on this single thing (and make sure they all have the same world state), and then send processed data, to single server which handle actual map with players.

E) Other possible solution which could work on single server instance is to still distribute load over many machines but do it on engine level. Using something like project Orleans or CAF (actor framework for C++), it could be possible to create actor for each AI running, which then is transparently distributed in cloud, and or run in pararell with other AI actors.
I this context I mean actor from Actor Model.
This is assuming we limit our player count, but still want to have some kind of simulated persistent world.

I would actually try last solution. It also possibly could be expanded for players avatars as well.