Regarding the limit on Networking

[AloneInTheDark]

Not sure how to ask this... hmm, I'm not sure if I understood this correctly but there seems to be a limit on number of networking connections or players with this "free" version?

I mean, is it possible to connect or use external modules or does this "free" engine has no possibility of having an unlimited networking? Say I want 1000 or more players?

EDIT : I mean this : "Client-server model support for up to 64 players." ( http://udk.com/features-networking.html )

[musilowski]

I think the limit could be bypassed with external "plugins", from what I've read on these forums... Could be wrong though. You're trying to create a MMOG I presume?

[Brexer]

if he ask's for 1000 or more players, the term is most likely MMO (as in massive multiplayer..blabla)

And yeah, it could be done using TCPLink, search the forum on other subjects.

Actually, you could have done that before making this post, considering its been answered (aswell) by Epic in here :P

[Makaze]

Realistically, no. I'm sure you'll have some eager beavers pop in here and tell you that "in theory" you should be able to create various hacks to make this happen. But the truth of the matter is that the Unreal networking layer was never designed to support that many simultaneous users and without heavy modification to parts of the code that you don't have access to it simply will not do what you want. And the local server TCPLink hack is not fast enough to have a full on MMO networking system passed through it at any kind of reasonable speed.

It may be possible to have a lobby system with 1000s of players in it that then are shuttled off into 64 max player instances, but that's as close as you're likely to get. TCPLink is fast enough for things like chat. Although I have not yet experimented with the UDK match making system or how easy/possible it is to make the server 100% authoritative in all important matters (without which your MMO is a pointless wasteland of cheaters).

As an aside, expecting any engine to out of the box have a fully functional MMO scale networking layer is... to be polite, an unrealistic expectation.

[AloneInTheDark]

Yes, My question was related to MMO.

In all honesty, I was just fishing the waters since I found UDK interesting. I agree with "makaze", we will be better off with our own engine since we'll have full control over it.

In case of curiosity, http://www.TheLandsBeyond.net is what we are um... trying to create. ..an indie MMO ( which hopefully won't suck.. hehhe... ).

Thank your very much everyone for the great answers.

[Brexer]

Makaze your missing the point

Unreal and its internal networking has absolutely nothing to do with it.

You will run a server and client on the users local pc, and THAT will do all the MMO client work.

I fail to see how that is not fast enough, unless the TCPLink layer itself is lagging (or the users internet connection).

[Game Client -> TCPLink Server (you create)] -> WAN -> [MMO server]
[MMO server] -> WAN -> [TCPLink Server (you create) -> Game Client]

You MAY want some sort of packet prediction, but thats another story.

As i understand it, its similar to the Lineage II system, so i guess that dont work aswell (poor NCSoft !)

Fact is, yes its possible, and since you can problem your client/server (local TCPLink layer) in c++ or C# or whatever it can be pretty fast.

And for security, thats a hole chapter on itself, but if you have a mmo, run whats most imporant (data) on the server, not client side, but i wont sit here writing a intire book on that subject

- Edit : Yes, you ofcourse have to program this yourself in unreal script and your preferred coding language (c++, C# ect ect).

[Makaze]

It's not the local TCP communication time that's at issue, that will be <1ms in most cases. Rather it's the cumulative time it takes you via unreal script to collect, serialize, unserialize, and act on the data being passed through the local TCPLink. You're essentially adding an additional, fairly inefficient, layer onto an already very performance sensitive and complex system.

I agree that in theory with unlimited computational resources that it is possible, but realistically having it run at an acceptable speed is a pipedream, not to mention a nightmare to implement. If someone could get a fully functional game setup with even 64 players running like that I'd be fairly impressed considering all the technical hurdles they'd run smack into.

I'd also argue that security as a primary concern should be thoroughly examined long before any code is put to keyboard. Unreal as is currently written is not a strict client/server architecture. I know there are some things that are controlled authoritatively on the server but have not fully explored the system to know if everything can be (and so far I'm thinking not)

[DragonSpawn]

Extending the network capabilities with the usage of TCPLink would not be good even if it was high performing.
There's no MMO out there that uses TCP for anything except for stuff like chat and other non time critical aspects. TCP in itself is very slow, this is why all games now a days use UDP (for all other aspects).
Even if you were to create a seperate application with UDP/TCP to the game server and then connect to the game via TCPLink it would still be very slow. I have never used TCPLink, but since the documentations itself say

A word of caution, this is not a high performance feature. Using it can have a serious impact on the game performance. The performance impact is higher when providing a service. So keep this in mind when using this functionality.

then I must assume that it is quite slow and is not supposed to be used for time critical functionality and will definetly not be scalable enough to pull off being a pipeline for MMO networking.

[Brexer]

There TCPLink, and there UDPLink

http://udn.epicgames.com/Two/UnrealSockets.html#UdpLink

Anyways, i know some MMO's that use TCP only, and they are running fine.

[DragonSpawn]

There TCPLink, and there UDPLink

http://udn.epicgames.com/Two/UnrealSockets.html#UdpLink

Anyways, i know some MMO's that use TCP only, and they are running fine.

Well the performance warning still applies. The implementation complexity is the same between udp and tcp. And tcp only mmo makes no sense. Since before you even get the acknowledgement of a previous package it has already been time to send several others. Since coordinate updates are sent continously, a couple of lost packages along the way does not matter.

[BryanRobertson]

I could be wrong here, as this is the first I've heard of TCPLink/UDPLink, but unless I'm mistaken, using TCPLink/UDPLink for networking would mean completely ignoring Unreal's system for network replication, and rolling your own system.

This would be a non-trivial amount of work. You'd essentially have to write your own networking system in UnrealScript, and reimplement features in the engine yourself (such as deciding which clients need to know about each other, spawning actors on appropriate clients at the appropriate time, and replicating state, etc). This would most likely be slow as hell, and not scale very well, defeating the point entirely.

To be honest, if I were you I'd question whether trying to write an indie MMO is a good idea at all. MMOs are very expensive to run, and very difficult to develop. Not to mention, the chances of attracting enough players to an indie MMO to justify this amount of effort, is pretty slim.

[neai]

The provided netcode is optimized for up to about 64 players. I believe it's more about things like algorithmic complexity of the netcode and bandwidth than anything else. So if you want more, you need to optimize further where possible or roll your own.

[musilowski]

The provided netcode is optimized for up to about 64 players. I believe it's more about things like algorithmic complexity of the netcode and bandwidth than anything else. So if you want more, you need to optimize further where possible or roll your own.

Is the 64 limit hardcoded or can it be changed on a gametype basis?

[neai]

Is the 64 limit hardcoded or can it be changed on a gametype basis?

TBH I don't know, I haven't seen the code, but I don't remember any hard limits. Well, other than ie some assumption in UT3 script about expected max numbers of players, which doesn't matter when you're making a new game.

[BryanRobertson]

I think if you manage to make an indie game successful enough to have 64 players playing at once, you'll be doing pretty well. Aside from technical restrictions, it's pretty difficult to make an indie game that popular, and to make enough content to keep 64 simultaneous players happy.

To be honest, while one could argue that it's not "massively" multiplayer. Depending on game content and persistence, I think you could make a perfectly good MMO (or at least pseudo-MMO) with only 64 simulataneous players per map.

[Cheyenne]

There's no MMO out there that uses TCP for anything except for stuff like chat and other non time critical aspects. TCP in itself is very slow, this is why all games now a days use UDP (for all other aspects).

World of Warcraft uses only TCP for everything.

If anyone is interested in TCP-based MMO servers you can always download MANGOS (a WoW clone server with source) and change the programming to run with your own game. WoW is extremely light on network traffic, ~10 meg per hour in many cases.

The networking inside of UDK is designed for twitch games which is typically much more demanding than you average MMO.

Indies can produce MMOs. Look at Minions of Mirth produced by 2 people in 9 months using the original Torque engine (that's a small miracle in itself ). Sure, it's not going to take on WoW with it's army of professional programmers and artists, but, Indie MMOs can be and have been done. You will need to be very dedicated and you will have to have some money to lease servers.

As far as making money with an Indie MMO, I would recommend making it free but offering subscriptions for enhanced play features. Just make sure it's good and addictive. Remember, it takes a lot less revenue to support an Indie than it does to support Blizzard, etc..

[BryanRobertson]

Indies can produce MMOs. Look at Minions of Mirth produced by 2 people in 9 months using the original Torque engine (that's a small miracle in itself ). Sure, it's not going to take on WoW with it's army of professional programmers and artists, but, Indie MMOs can be and have been done. You will need to be very dedicated and you will have to have some money to lease servers.

I'm not saying it can't happen at all, just that the vast majority of people that want to make an Indie MMO have neither the skills nor the resources to actually create one, and have ideas that are far beyond what a small team can create in a reasonable amount of time.

Even for those that do manage to create one, I think breaking even on the investment of servers would probably be pretty difficult.

If I wanted to create an MMO-style game with UDK (if such a thing is possible), I'd personally aim towards a 64 player game with a lot of persistence. Give the world and characters a persistent state that the server loads from a database.

[Makaze]

Realistically there is little to no need for >64 players. Even in WoW it's very rare that you interact with more than 64 people at a time via anything other than chat. And TCPLink + a separate chat server is more than enough to unite all your separate 64 man instances, heck I'd argue that's actually a non-hack use of TCPLink.

[Cheyenne]

Realistically there is little to no need for >64 players. Even in WoW it's very rare that you interact with more than 64 people at a time via anything other than chat. And TCPLink + a separate chat server is more than enough to unite all your separate 64 man instances, heck I'd argue that's actually a non-hack use of TCPLink.

Depends on what kind of hardware resources are needed to run a single instance of a dedicated UDK server app. If you can't house enough players on a physical server to cover the cost of the server + bandwidth usage + etc and have some profit then that makes your idea financially unfeasible.

MMOs are a balancing act of capacity per server, bandwidth management and technological wizardry. Something that is technically doable can easily fail the financials side of the equation.

[Blade[UG]]

In UE2, spawning a couple hundred pawns causes a crash as soon as a large quantity of them become relevant to a client. In UT3, doing the exact same thing results in pawns that the clients can no longer keep track of, and they never seem to get corrected, even if they go irrelevant then become relevant again. I'd expect similar things in UDK, although it may be different with AI vs PlayerController pawns.

[Cheyenne]

In UE2, spawning a couple hundred pawns causes a crash as soon as a large quantity of them become relevant to a client. In UT3, doing the exact same thing results in pawns that the clients can no longer keep track of, and they never seem to get corrected, even if they go irrelevant then become relevant again. I'd expect similar things in UDK, although it may be different with AI vs PlayerController pawns.

Since that is the case then that would suggest a hard limitation that can't be worked around without source access. Given this, the question of MMO viability using UDK as the server would boil down to how many UDK server instances you could run on a single, reasonable box. A box would have to be able to support several hundred players at the very least to be able to make the financials.

[Saishy]

I'm sure a UDK server should never be used on a MMO.
It's don't fit it.

[Blade[UG]]

Since that is the case then that would suggest a hard limitation that can't be worked around without source access. Given this, the question of MMO viability using UDK as the server would boil down to how many UDK server instances you could run on a single, reasonable box. A box would have to be able to support several hundred players at the very least to be able to make the financials.

Server itself doesn't really take all that much horsepower, from my experience. Even with large quantities of AI running the old pathnode-type-calculations. Of course, in most real MMO experiences, you're typically not going to have hundreds of players relevant at any given point, to a particular client, so it might well be possible. Someone really needs to actually sit down, build an area, and give it a shot, IMO.

Once you get 50-60 decently detailed player models in view at any point in time, the graphics hardware on the clients becomes more of a problem than the networking ..

[kyoryu]

If you were to do something like that, you'd probably not want to use the existing Pawn support and logic. You'd want something a bit more lightweight.

Add in encryption of your datastream, and it may be a tough task without source.