MMORPG

BlitzMax Forums/BlitzMax Programming/MMORPG

Trader3564(Posted 2008) [#1]
Ok, i may not be the first to start a topic on MMORPG, but im not going to ask you to make one for me :P (would be nice tough, hah)

Ive done a little game with +-50 players, using a ClickTeam product called MultiMedia Fusion, based on TCP/IP. Ye, it lagged my socks off if lots of stuff was happening but i spend a year at least trying to master some dead-reckoning techniques and packet filtering and stuff.. so i pushed it far. But im not happy. I want to support at least 250 playes on 1 server. That is the reason i plan to switch all to BlitzMax.
However, What i miss here is a server/client framework that handles connections and all that. Basicly, i have my sockets in blitzmax and need to setup a good mangement arround that.
Does anyone know a good and if possible, up-to-date library that can help me get this done?
Your input is very much apriciated. Thanks.


Barbapapa(Posted 2008) [#2]
I'm thinking of porting my BlitzMax stuff to Python on the server side. Many modules for every case. Speed can be handled by integrating C parts where needed. Threading included. I have nearly finished my proxy simulation with BlitzMax now. A soon as I have gathered enough information I will decide what to use. Seems that I can get away without Java, which I find to be too scary due to its complexity.


Trader3564(Posted 2008) [#3]
ye, i heard Python is like a no#1 to build servers in.


FlameDuck(Posted 2008) [#4]
That is the reason i plan to switch all to BlitzMax.
That's a rather poor choice considering BlitzMAX doesn't support (and likely isn't ever going to) multithreading.

I can get away without Java, which I find to be too scary due to its complexity.
You won't be liking Python much then. Python is at least an order of magnitude more complex than Java.

i heard Python is like a no#1 to build servers in.
You heard wrong. Erlang is by far the best language for server applications. Java and C# are distant seconds. Python is not even on the list.


Barbapapa(Posted 2008) [#5]
Python is at least an order of magnitude more complex than Java.

explain please...

Erlang is by far the best language for server applications. Java and C# are distant seconds

Erlang I belive, Java too, but C#?? Considering that most servers run under some sort of Unix or Linux how can C# be?


Trader3564(Posted 2008) [#6]
That's a rather poor choice considering BlitzMAX doesn't support (and likely isn't ever going to) multithreading.

You serious?! man, that sux. But wouldnt it still work for 250?! its only an RPG, no FPS or something fancy... hmmm...


Barbapapa(Posted 2008) [#7]
Well, RealmCrafter (the old standard version) is built with BlitzPlus and Blitz3D and it works, so 250 shouldn't be any problems IMO.


FlameDuck(Posted 2008) [#8]
explain please...
It has more features and a different philosophy than Java. Duck typing vs. inheritance, late binding vs. early binding, lambda calculus vs. nothing, the list goes on.

Considering that most servers run under some sort of Unix or Linux how can C# be?
There are plenty of C# compilers for Unix/Linux. Besides most MMORPG servers most certainly do not run Linux.

But wouldnt it still work for 250?!
Well that depends on quite a few factors, including but not limited to the hardware and amount of data involved. The main problem here is that as the numbers of players increase linearly, the amount of data and traffic increases exponentially. Solving this issue is an NP-complete problem.


Barbapapa(Posted 2008) [#9]
Well Python doesn't seem to be this bad...Stackless Python
I think Python as Server and BMax as Client seems quite nice.
But I have some time to decide yet...


FlameDuck(Posted 2008) [#10]
Well Python doesn't seem to be this bad.
Stackless Python is not Python. And I never said it was bad. I'm saying it's nowhere near as good as Erlang, and if you're going to learn a new language anyway, you might as well go with one that was designed for scalability and concurrency from the beginning, rather than one that has been hacked on top of an existing language.

I think Python as Server and BMax as Client seems quite nice.
Well, don't let me stand in the way of your happiness.


xlsior(Posted 2008) [#11]
I want to support at least 250 playes on 1 server. That is the reason i plan to switch all to BlitzMax.


That seems a bit hasty, considering that network calls in BlitzMax block your program execution while it's waiting to receive the results.

If you're running into socket lag issues already, then I doubt that Blitzmax is going to be the answer here... (Not without using some external DLL's or something for network handling, at least... The built-in functionality probably won't be sufficient for what you are trying to accomplish.)


Raph(Posted 2008) [#12]
All major MMORPGs are written in C++, afaik.


Chroma(Posted 2008) [#13]
considering that network calls in BlitzMax block your program execution while it's waiting to receive the results
So what you're saying is that multiplayer in BMax will always suck?


Barbapapa(Posted 2008) [#14]
Does Blitzplus work differently or why is it that a server coded in Blitzplus actually works (RC)?


Trader3564(Posted 2008) [#15]
"BlitzMax block your program execution"
I must have not noticed.. but if that is true, that indeed could be a problem... aww. I so liked BlitzMax. I already have my RPG loader, that read from the oldgame mapstructure. So i render now in BlitzMax what used to be rendered in MMF. Its lots faster in BlitzMax.
How come tough, that RealCrafter was working out so well?


FlameDuck(Posted 2008) [#16]
All major MMORPGs are written in C++, afaik.
Puzzle Pirates is written in Java.

So what you're saying is that multiplayer in BMax will always suck?
No. Clever level design and/or beefy hardware will be able to compensate somewhat. Also there are certain software architectural choices you can take to work around this issue.

Does Blitzplus work differently or why is it that a server coded in Blitzplus actually works (RC)?
Without actually seeing the RealmCrafter source code, there is no way to tell for sure. I'm guessing that either a) It doesn't scale as well as you assume, or b) That some workaround is being used.

How come tough, that RealCrafter was working out so well?
Just how well? Has anyone actually tried running an RC game with 250 consecutive players?


Barbapapa(Posted 2008) [#17]
I emailed them a short time ago.


3) How many clients can I have at one time in a zone?

A-3: The answer is that it depends on the individual connection quality. Upload speed is more important than download. It also depends on the distribution of players and of NPCs, and the Server machines RAM. Here are some estimates based on our testing.

512k cable: 15 players
2 Mb cable: 40 players
10 Mb cable: 400 players
100 Mb cable: 3000 players



If you buy RC now, you get the source-code for the standard version and the pro version (c++) free when it comes out but without the source code.

So, it seems to work well enough with Blitzplus...


ImaginaryHuman(Posted 2008) [#18]
I would go with something that uses UDP not TCP and make your data really compact and design your own networking system.

I was reading the x-wing vs tie fighter networking article where they had like 8 players with only 28k bandwidth, so you should be able to get more than 15 from 512k.


Trader3564(Posted 2008) [#19]
100 Mb cable: 3000 players, thats cool. I got one of those. Seems 250 aint a problem then :P
Now all i need todo is have a Linux compatible serverside.


FlameDuck(Posted 2008) [#20]
Here are some estimates based on our testing.
That sounds somewhat dubious. If we accept that 15 players on a half-megabit is the base line, a quadrupling of bandwidth only allows for 2.5 times as many users (which seems accurate, considering the exponential nature of bandwidth requirements as mentioned before). However then a factor 5 increase in bandwidth allows for a factor 10 increase in players, which seems implausible at best. Lastly the idea that an order of magnitude increase in bandwidth allows more than a factor seven increase in players is unrealistic. This is not even close to an exponential function (which is what you would expect, in fact in some places it's the exact opposite) which can only lead to one of two possible conclusions. a) RealmCrafters heuristic network algorithm is better than any professionally developed MMO currently in existence (Blizzard can't even run 3000 consecutive players on one of their servers) b) the numbers in the higher end of the scale could charitably be described as extrapolated incorrectly, or uncharitably be described as lies.

I would go with something that uses UDP not TCP and make your data really compact and design your own networking system.
Making your data really compact is not necessarily your best option.

100 Mb cable: 3000 players, thats cool. I got one of those.
Nice! We can't get more than 25Mb in our country. Unless you want to pay entirely too much for your Internet connection.

Seems 250 aint a problem then :P
Hahah. Famous last words.


Retimer(Posted 2008) [#21]
A big portion of it doesn't have to deal with just the network speed, but the way things are processed and ofcourse, the hardware.

Saying that the bandwidth increases by an exponential factor for every player added I would think is only true if your application is extremely unoptimized. For 3d games, you're not going to send movement and action packets from a player at coord [x,y]: 0,0,0 to a player at coordinate 10000,10000...hiding behind a wall with a fog-view distance of 1000.

And in 2d games, you're only sending actions done by players within the screen region....why would you update every player in a 200x200 map when the screen is only 30x20?. I don't recall games where every player decides to join the exact same map in the exact same location for 'playing' (maybe pvp...so have another server host that map).

Optimize the packets...make the clients do the dirty work. Dont send packets like:

"Position,115,36,"

Although it's pretty and easy to understand the packets that way....its horrible.
Const PositionPacket:byte = 1

writebyte(PositionPacket)
writebyte(115)
WriteByte(36)

turns out like : "s$"

Even that can be optimized better.
I wish I didn't have to agree with FlameDuck that I really doubt the single server can run for 3000 players simultaneously. Unlimited bandwidth doesn't mean unlimited users. It just doesnt work that way. It's also pretty doubtful that you'll ever really need 250 people in a single area. If you have a community where you have >250 players on at once...i'm sure you can add some effort into coding for interacting servers (that each run a seperate area/map) and afford them to say the least.

Blitzmax can definitely do the job. Just work around things.


nawi(Posted 2008) [#22]
You shouldn't send those bytes one by one, use writebytes (or equivalent).


ImaginaryHuman(Posted 2008) [#23]
Also I read that ideally you should make reasonable sized packets so you need to join several pieces of information together into one packet if possible rather than get all the extra packet overhead.

Also are you going with a single server for all users or are you making some users offload some of the server work? Or peer-to-peer even?


Trader3564(Posted 2008) [#24]
Best way to send packets is using SSPP
Basicly that meens ending a short with the lengt of the packet. The packet is send in bytes. Done.


FlameDuck(Posted 2008) [#25]
Saying that the bandwidth increases by an exponential factor for every player added I would think is only true if your application is extremely unoptimized.
Optimized for what? Which is faster, just sending all the data, or figuring out which objects can see other objects? Traversing a dense graph, is very time consuming (at best polynomial time, most likely factorial time).

why would you update every player in a 200x200 map when the screen is only 30x20?
Because doing the math to figure out, for each player, which other player is within their "area" is an NP-complete problem, not solvable in polynomial time? Sure it works well for small amounts of players, but 3000! is a HUGE number. Even if checking every object in the game world only took 1 CPU cycle, calculating the exact solution, would take forever.

Best way to send packets is using SSPP
A what?

Basicly that meens ending a short with the lengt of the packet. The packet is send in bytes. Done.
The UDP header already contains the size of the packet. Adding redundant data doesn't seem like it's an efficient thing to do.


Retimer(Posted 2008) [#26]

Optimized for what? Which is faster, just sending all the data, or figuring out which objects can see other objects? Traversing a dense graph, is very time consuming (at best polynomial time, most likely factorial time).



Optimized for bandwidth. I personally don't want applications sending me all kinds of useless information. When i'm alone on the screen/large area, I don't think I should be recieving 50 packets/s of the 15 players moving on the other side of the map. If the extremely minor delay of doing some checks is caused, it would make up for the client-side not having to process all the useless packets.

Sure it works well for small amounts of players, but 3000!


And continuing what I said, what game have you ever seen with 3000 people in the same area? I have gone through so many stages of online mmo's that I get no enjoyment from gameplay anymore and I still have not seen more than a couple hundred in a single map/large scaled area.

Doesn't Eve Online use a single server? And it's complete crap from what i've heard....the lag. A server might be able to handle a couple thousand players, by spamming packets without checks but wouldn't the client just lag over completely defeating the purpose? I only have some experience in hosting game servers, and certainly not thousands of players simultaneously. But I think it's the wrong approach to even plot the idea.

All the professional games I have come by used seperate servers for every area. Not seamless...but even that could be achieved with seperate servers. Everquest, Anarchy online, Project Entropia [Seamless I believe], WoW (as much as I despise blizzard), etc.

It would be cheaper to rent several servers that can host several different maps/areas rather than a single server and line that is truly capable of hosting it all. Initial load times would be ridiculous, server restarts & crashes would require the entire game go down, rather than zones at a time which can be extremely advantageous for updating small parts of the game, only nudging a small portion of the community for a short while.

I'm thinking for the customers|player-base. Not what's easier for me.


Tab(Posted 2008) [#27]
FlameDuck allways says the same things without concrete bases.


nawi(Posted 2008) [#28]
FlameDuck, it is just stupid to send every coordinate of every player to every other player. If you have 3000 players your internet connection will explode. Just use an array to save the positions of characters, which makes it super fast to check whether there are other players nearby.


Dreamora(Posted 2008) [#29]
On the RC stuff: RC uses UDP. UDP is not blocking, its only TCP that uses blocking calls ... although it does not use blocking calls ... its just how TCP works: It sends till it gets the acknowledge that the message was received ... and as Blitz does not handle TCP connections in their own thread as any "modern" language, which BM still wants to be called, TCP is a no go for realtime, still nice for meta server handling, login, update downloads etc etc where a real stream is needed, especially everything on the HTTP and FTP protocol.


Czar Flavius(Posted 2008) [#30]
I love FlameDuck.


Trader3564(Posted 2008) [#31]
Hmm, Seems FlameDuck is legendary. Both hated and loved.


ImaginaryHuman(Posted 2008) [#32]
I'm glad to hear that UDP doesn't wait. When you are trying to read the port to see if there is UDP data arrived, does that wait for something to arrive or just return an error if empty?


Trader3564(Posted 2008) [#33]
Is there actualy a way to send over TCP without stream?
On the serverside you can instead read the received bytes.
In my experiance, If you open a stream its going to block the main loop.

Here is the servercode i wrote, maybe it is usefull to anyone:
(Do not that i got lost trying to receive the bytes _without_ stream, so it still needs some work. Basicly this demonstrates the basics of connecting and storing clientconnections.)
Graphics 320, 480, 0

Local My_server:TSocket=CreateTCPSocket()
BindSocket My_server,1233
SocketListen My_server

Type TClient
	Field sock:TSocket
	Field stream:Tsocketstream
	Field buffer:TBank
	Field data:TList
	Field lastmsg:String
End Type

clients:TList = CreateList()

While Not KeyDown(KEY_ESCAPE)
	'New connection?
	Local sock:TSocket=SocketAccept(My_server)
	If sock
		c:TClient=New TClient
		c.sock = sock
		c.buffer = CreateBank()
		c.data = CreateList()
		ListAddLast clients, c
	EndIf
	'Show connections
	DrawText ">Loops: "+l,10,10
	DrawText ">Connected: "+CountList(clients),10,20
	l:+1
	offset=30
	For c:TClient = EachIn clients
		'Connected?
		If SocketConnected(c.sock) Then
			clientname$ = DottedIP(SocketRemoteIP(c.sock))
			
			'New data/packets?
			buf=SocketReadAvail(c.sock)
			Rem
			bufsize=SizeOf(buf)
			size=BankSize(c.buffer)
			ResizeBank(c.buffer,1000)
			For p=0 To bufsize-1
				b:Byte=Byte(Mid(buf,p,1))
				If b=Null Then
					'Que packets
					ListAddLast c.data, c.buffer
					c.buffer = CreateBank()
				Else
					Print size
					Print bufsize
					Print p
					PokeByte(c.buffer,size+p,b)
				End If
			Next
			
			'Prossess packets
			For d:TBank = EachIn c.data
				data$=""
				For p=0 To BankSize(d)-1
					data=data+Chr(PeekByte(d,p))
				Next
				c.lastmsg=data
			Next
			EndRem
			For p=0 To SizeOf(buf)-1
				c.lastmsg=c.lastmsg+Chr(Int(Mid(buf,p,1)))
			Next
				
			DrawText clientname$+": "+c.lastmsg,10,offset
			offset:+10
		Else
		'Disconnect?
			CloseSocket(c.sock)
			ListRemove clients, c
		End If
	Next
	Flip
	Cls
Wend

For c:TClient = EachIn clients
	'CloseStream(c.stream)
	CloseSocket(c.sock)
	ListRemove clients, c
Next



Dreamora(Posted 2008) [#34]
no TCP is a stream bound format.
If you don't want a stream -> UDP
If you want reliable UDP and ordered -> Pub.ENet


*(Posted 2008) [#35]
You can do server/client stuff in BlitzMax, im using it for Elite Multiplayer. It is true the more players you have the more bandwidth you require for example 64bytes per packet for one player (say 10 packets a second is 640bytes). Now if you have ten players thats 6400bytes so the more you add the more bandwidth you need to keep it flowing properly.

Yes it doesnt have multithreading but not all server stuff requires it, yes TBH its down to the programmer not the language. Hell I wrote a game with a mate back in 1990 using Turbo Pascal and that handled 128 players over IPX.


ImaginaryHuman(Posted 2008) [#36]
What's the difference between using ENet and using standard socket commands? Is ENet any faster?


FlameDuck(Posted 2008) [#37]
When i'm alone on the screen/large area, I don't think I should be recieving 50 packets/s of the 15 players moving on the other side of the map.
That's really clever. How does the computer determine that you're alone in an area?

If the extremely minor delay of doing some checks is caused
A algorithm running in non-polynomial time is NOT a minor delay for any non-trivial amounts of clients.

And continuing what I said, what game have you ever seen with 3000 people in the same area?
Plenty of times. If you want a list, Eve Online, City of Heroes, World of Warcraft, and Tabula Rasa.

And it's complete crap from what i've heard....the lag.
Well I don't find it particularly enjoyable, but the lag is fairly reasonable. Certainly compared to games like Tabula Rasa.

But I think it's the wrong approach to even plot the idea.
I didn't say it was the right idea. I'm advocating a heuristic approach, where you send some superfluous data, potentially avoiding the factorial time complexity of traversing a dense graph.

FlameDuck allways says the same things without concrete bases.
While I appreciate your ad hominem argument, it doesn't exactly contribute constructively to the debate. Think I'm wrong? Prove it. As it happens I have plenty of concrete experience in this area. Developing distributed systems is what I do for a living.

Just use an array to save the positions of characters, which makes it super fast to check whether there are other players nearby.
How? How do you not have to visit n! (factorial) amount of entries in the array in order to determine how many players are nearby? If you have an actual solution for how you can solve an NP complete problem like the traveling salesman problem (which is the closest analog to this problem) step forward and claim your turing award young man, you'll be famous!


Trader3564(Posted 2008) [#38]
Whats a "___NP____ complete problem"?

So, what is wrong with:

'clients:Tlist
for c:TClient = EachIn clients
c.x<> etc..
c.y 'compare positions?
next


Michael Reitzenstein(Posted 2008) [#39]
Because doing the math to figure out, for each player, which other player is within their "area" is an NP-complete problem, not solvable in polynomial time? Sure it works well for small amounts of players, but 3000! is a HUGE number. Even if checking every object in the game world only took 1 CPU cycle, calculating the exact solution, would take forever.


Umm... no it's not. It's roughly linear to the number of zones you have, depending on how you do it. Just insert the players into buckets, and have a worst case list of what zones can see each other.

This of course neglects that player in zone a can see player in zone b can see player in zone c. That's a reasonable tradeoff. But even if you don't do that, it's just a mark and sweep per player, which is O( n^2 ) not O( n! ). Which is an unpleasant growth when you're trying to deal with 3000 players on a single server, but you should be using buckets anyway and if you don't packet growth will also be O( n^2 ).

I'm not 100% convinced Erlang is a sensible choice for an MMO server. I mean it blows away C++, Java, Python (GIL). But you could probably use a commercial lisp implementation (like Franz) and achieve most of the benefit. That's more of a language preference on my part though, I guess.

I will probably write my games server in Python, but that's only because I'm going to be using it on a single threaded EC2 instance anyway.


Trader3564(Posted 2008) [#40]
Ive been thinking about the buckets idea of Michael. What about when players move zones, you remove them from the zone bucket, and put them in another bucket?
meens each zone has a bucket. using a TList in a TBank, would work rather quick and efficient i think asuming your banks are named like "x0y0z0", etc..


Michael Reitzenstein(Posted 2008) [#41]
I'd use a TMap, that way you're not doing unsafe casting to/from an int. You can probably clear the TMap each frame, I mean it's not exactly a taxing operation rebuilding it (n inserts per player, where n is the number of zones that can possibly see each other - probably 9 in a 2D game). Keep in mind that you have to keep the player in all zones that can see the player, not just the one he's currently in (think of a border case).

The zones also have to be bigger than the players sight range, otherwise you can 'skip' a zone and it will be able to see more than its neighbours.


Trader3564(Posted 2008) [#42]
*ugh*, i dont know why i wrote TBank, i ment to say a TMap haha. ofcorse. :P


Michael Reitzenstein(Posted 2008) [#43]
You might want to just use a 3D array if the memory required is reasonable. So if you've got 40x40 zones, I'd just create a TList[,] and eat the (minimal) allocation cost. If you've got 1000x1000x1000 zones, then you're better off using a TMap. Of course, if you've got a billion zones you've probably got a really clever algorithm for generating/packing them, so...


Tab(Posted 2008) [#44]
@FlameDuck
Sorry, but... I don't need probe anything, your words prove the wrong way in terms of how a MMO server work.


Retimer(Posted 2008) [#45]
Like I said, I've never hosted a 3000 player server, but I have hosted very large world content and what I did was create an array for every position.

A Map of 100x100x1[levels in map] had a [100,100] array, and when a player moves into a position, that arrayed integer would be changed to the index of the player. This kind of checking is trivial and very minimal in costs.

About your "NP-complete system". I have seen many games run several hundred players via TCP and using this by-view checking (Either that or worse: distance checking). The title is MMORPG, not MMOFPS.

I have no problems at all with you flameduck, as these spit-backs are a good way to open up new questions, theories and answer uncertainty. I am very impressed though that you have seen 3000 user models (players) in a single scene, and recieving updates for each one in every one of those games. I've just asked several people I know that are heavily retarded in WoW who claim to never have seen anything like that, even during events.

It seems most of us think that you're wheel is square. Can you completely elaborate your method?
For example:

Which is faster, just sending all the data, or figuring out which objects can see other objects



Can you explain how sending all the data to all the players (even if they will never have use of that data) is helpful for running a multi-thousand populated server? How all those packets to each of the 3000 players would not lock up both the clients AND the server?
If you can give us an elaborate answer to that, I think you'll have presented us a breakthrough in our primative design.

Time


Chroma(Posted 2008) [#46]
No. Clever level design and/or beefy hardware will be able to compensate somewhat. Also there are certain software architectural choices you can take to work around this issue.

So basically then, multiplayer in bmax will always suck...

I thought someone came up with a way to make the sockets non-blocking? Or maybe it was Blitz3D. Either way I'm sure with the ingenuity around here it can be overcame eh?


nawi(Posted 2008) [#47]
Shouldn't this be quite fast?

Const Width=2000,Height=2000
Const ScreenWidth=20,ScreenHeight=20
Type Player
	Field ID
	Field X,Y
	Global List:TList
	Global Map:Player[Width,Height]

	Method New()
		X = Rand(0,Width-1)
		Y = Rand(0,Height-1)
		ID = Player.List.count()
		ListAddLast(Player.List,Self)
		Player.Map[X,Y] = Self
	End Method
End Type
Player.List = CreateList()

For t=0 To 3000
	Local p:Player = New Player
Next

'Loop players
For p:Player = EachIn Player.List
	For i=-ScreenWidth*0.5 To ScreenWidth*0.5-1
		For j=-ScreeHeight*0.5 To ScreenHeight*0.5-1
			If i+p.X>=0 And j+p.Y>=0 And i+p.X<Width And j+p.Y<Height Then
				Local p2:Player = Player.Map[i+p.X,j+p.Y]
				If p2 <> Null And p <> p2 Then
					Print p.ID+" sees "+Player.Map[i+p.X,j+p.Y].ID
				EndIf
			EndIf
		Next
	Next
Next



Dreamora(Posted 2008) [#48]
Chroma: UDP is not locking
You can do that with BM. But most here already strugle with using pure sockets, so they definitely will struggle with stuff thats 2 level of that complexity wise.


Trader3564(Posted 2008) [#49]
Are there actualy any UDP server + client demo's?
I found many libraries tough....


Dreamora(Posted 2008) [#50]
with the old bnet there was the 2 player jump'n'run tutorial.
For the new BNetEx versions there isn't any but you still could use that tutorial as base (its linked on assaris 2dgamecreator.com page).

If you want to go pure UDP, I would suggest using BNetEx


Wings(Posted 2008) [#51]
Well am i the only one that dosent have problem blitzbasic tcpip :D

my engine aim is 1000 users.
at 50 users i have no lag at all.

My engine written in blitz pluyss is tested this wia millisecs() command from 50 clients connected over 3g network)


Dreamora(Posted 2008) [#52]
test the game in reality ie with internet latency. network straight within a LAN is not realistic nor will it show the least problems.


Retimer(Posted 2008) [#53]
Dreamora is correct. I have used tcp + blitzmax for one of my projects. It's basically a project that allows multiple users to create maps, item databases, animations, etc. With only 2 people (pinging 90 from eachother, and 70 from the master server) setting tiles, there was very odd response times in setting the tiles. The opposite user was able to send me messages via aim sometimes before tiles he set would show on my screen.
I was hoping dreamora was exagerating, but I made another similar test in VB6 using TCP with virtually no latency. I also tried this in blitzmax by myself, running multiple clients and ofcourse there was no latency. But testing with players & latency & master server = caka.

TCP+BM might be usable for things like multiplayer texas holdem, but I just lost all enthusiasm with BM + tcp for an online game to host 10+ players.
Wings, can I suggest to you what i'm suggesting to myself? Create a reliable udp method or use one of the available libraries that support it. It will improve response times for non-congested networks anyways.

I hope no one here is getting discouraged by blitzmax. It's still a great language that makes up for its flaws. And i'm sure one day mark will fix this issue in BM (when he stops itching at max3d and scratches a couple older issues), even though it's not worth waiting for because there are other options, all of which Dreamora has posted many times in topics that relate to this.


Dreamora(Posted 2008) [#54]
My suggestion would be a Pub.ENet wrapper.
Its simple, lightweight and has Reliable as well as ordered support so you could even replicate TCP behavior.


Trader3564(Posted 2008) [#55]
Exactly, what is the difference between ENet and blitzmax raw sockets?

And why isn't blitzmax sockets the same as visualbasic sockets? Isnt a socket a socket?
(sorry for my lag of understanding here)

You should know i moved from one thing to the other, that is to blitzmax, for its online support. Am i doing something wrong here?
If i hear that BMax TCP can only support arround 10+ players im concerned, either about the skill level on MMO games, or BlitzMax. Having seen whos posting here and what they came up with, i rather doubt BlitzMax and rest assured there is nothing wrong with the skills.
But to let you know, i accomplished writing an 2D RPG engine on TCP for arround 50 players. Yes, we had lag, and sometimes a player would warp all around the map or run from one point to another. But it was acceptable. The packets send where like on average only 1 each second. Basicly i send only when the direction or speed changed. It is, as if you are controlling (remotely) a robot/ball that goes ahead without new orders. That also explains why players where wrapping crazy sometimes.
I find sending X,Y positions over either TCP or UDP rather primitive. Its really not nessesary to just boom out the positions in every loop. For security reasons you can do it like once every 5 sec so the ball keeps on track.
On the other end you have a delayed interpolation to catch up the flaws. Result is tough, that there is a few sec delay always between A and B.
Having interpolation without delay would be pointless.... I hope im making sense :P


Retimer(Posted 2008) [#56]
I personally don't understand the difference between the two, I only tested with my projects and relayed the problematic results here. I was going to use raknet instead, but Enet is free and open source it seems.

As for the difference...I think ENet is more sophisticated and includes much of which will just take you more time to develop (such as reliability, and a few other features).


TaskMaster(Posted 2008) [#57]
Wow, a lot of bad information floating around this thread... :)


Trader3564(Posted 2008) [#58]
You meen different options are discussed? i cannot see what is bad about it :)


Dreamora(Posted 2008) [#59]
Enet offers reliable and ordered packet sent. A raw socket is just that ... UDP is not reliable nor ordered, so packet order can change during its travel or they can get lost.
thats it.


FlameDuck(Posted 2008) [#60]
I don't need probe anything, your words prove the wrong way in terms of how a MMO server work.
My MMO server works just fine thanks.

I've just asked several people I know that are heavily retarded in WoW who claim to never have seen anything like that, even during events.
That's because WoW doesn't support that many concurrent players. However player positions are not the only things you need to send information about. You don't really need 3000 players to have 3000 game objects that need data sent through the pipe. One example of a game like this is City of Heroes were they have a pop-up that reads something to the effect of "You have been hit by more than 1000 particle effects - performance may suffer as a result".

Can you explain how sending all the data to all the players (even if they will never have use of that data) is helpful for running a multi-thousand populated server?
It's not a matter of being helpful. It's a matter of which is faster. Sending all the data requires some fairly decent pipes - determining which objects are visible to EVERY PLAYER IN THE GAME requires ridiculous amounts of processing power. My solution is a heuristic algorithm that determines when further calculations on the data set are to "expensive" in terms of lag, and just sends the result. It works reasonably well, but still has room for optimization.

Shouldn't this be quite fast?
Compared to what? From what i can see you've got 3 levels of nested loops, and are possibly missing one. Both Michaels method and mine should give better on average results. Michaels will give better best case results, mine better worse case results.

Exactly, what is the difference between ENet and blitzmax raw sockets?
ENet is much more abstract.


jhocking(Posted 2008) [#61]
A quick question about something, in all this talk of figuring out what players are visible, you are referring to the server determining this and only sending to clients information about visible players, correct? Sorry for such a dumb question, but nobody has said this explicitly and I want to make sure people aren't referring to something else that I'm missing.

Also, dreamora made reference to bnet/BNetEx. What's that? Is that related to the GNet module that comes with BlitzMax?


TaskMaster(Posted 2008) [#62]
A simple way to determine who can be seen and what data to be sent can be done by using an overlapping grid.

If someone is in your grid area or any of the overlapping grids, then send their data because they may be visible. This is similar to the way EQ originally used zones. But you don't have to load from zone to zone. And the overlapping areas makes it so that you don't have to worry about two people being at the edge of two separate areas but being right next to each other and not able to see one another. Each area just needs to be a bit large than how far a player can see or be affected by another player.

I hope this makes sense. Needs a picture to illustrate it I think.

A server is not just one machine in a big MMO like WoW. Every WoW server is actually a farm of MANY computers. No way one machine is going to handle 3000 players. Hell, probably not even 1000.

You need a very fast backend database for storage, which should be a separate machine as well. You can't just keep it all on the one machine in memory, because a server failure will lose all the data. You would then have to go to your last backup, which could be hours or days. No players are going to want to lose hours or days of progress in the game.

A server in an MMORPG does a LOT more than just send data to players. It has to verify that everything the player wants to do is possible to keep players from cheating. It has to manage the actions of ALL NPCs and other objects. There is a lot going on in the background other than forwarding info from one player to another.

And as for Puzzle Pirates being written in Java. I have no doubt the client is Java. The server, that is probably C++ .


Paposo(Posted 2008) [#63]
Take a look to quadtree struct for make a grid.

Ahhh! Java is very eficient making servers and run as -server flag. The speed is like C++ using NIO.

Bye,
Paposo


ImaginaryHuman(Posted 2008) [#64]
You could keep a sorted list of all players coordinates and whenever two players swap positions you swap their positions in the sorted list (ie don't have to sort the whole lot every time), and then you can figure out what range of players are within a given zone or grid cell and only include those players. This way you are not necessarily restricted to grid-cell-resolution.


nawi(Posted 2008) [#65]
FlameDuck, are you on crack? I'm not missing a loop, and I'm just scanning all the tiles nearby the player. You could optimize that by using another array which tells whether a nXn rectangle from the map contains a player, but I just made up a simple example to show the idea.


Czar Flavius(Posted 2008) [#66]
What if it were not a tile-based game?


Dreamora(Posted 2008) [#67]
make it virtual grid based by dividing it into AxB sized areas.

"non tile based" is an approach that only works if you write a 3D engine highly opted for different pick and check operations so AI can be world aware ... but thats a highly complex tasks so normally virtual grids are far simpler. Or potential fields


Zethrax(Posted 2008) [#68]
What if it were not a tile-based game?


Whether the game is tile based or not, you would be sorting the mobile game objects into a grid or something similar, to optimize object interactions.

---

Regarding discussions about how many concurrent players a single conventional server can handle, I recommend reading this blog http://eternal-lands.blogspot.com/ by Radu Privantu, the guy who runs the Eternal Lands mmo. Theory and discussion are all well and good, but hearing about the experiences of someone who has had a working game running 'in the wild' for several years is more useful.