Best option to make MMORPG Server with blitztech?

BlitzPlus or BlitzMax?

A little question for the users with experience in network. :D

BlitzMax. You get raw access to the sockets. You can write your own socket code in C++ if you need ultra-high performance socket code such as that provided with IOCP, and call it via BlitzMax. And, BlitzMax is object oriented, something that will become a practical necessity in an MMO of any size.

I'm sure there are other reasons as I'm not all that familiar with BlitzPlus. But i guarantee Max is the better choice here.

Yep, plus having started learning Blitzmax I've found a few nice functions, like the ability to load media from a web URL too, for instance you can

mypic = LoadImage(LoadBank("http::www.url.com/mypicture.jpg"))

Would be really handy for something like a MMORPG where you update the content regularly.

BM as well has the possibility to share data between instances of BM, which will be needed to get some kind of "multithreading". A thread (in blitz this means a single application) can not handle a whole server. A few zones, thats it, at best.

Neither. It is not realistic to think you can handle a "massive" number (ie. more than about 20) of clients in a single-threaded environment.

If you really insist, use BlitzMAX as there is a chance you'll get multithreading down the line. But if you want to be certain, go for C#.

BlitzMAX also has several other advantages over BlitzPlus. It's object oriented, like SOS said, and the compiler is an order of magnitude better. But for an MMOG? Get another language.

Hey Dreamora: is there some trick about sharing data between different BlitzMax app instances or do you just open a local network connection between both and send the data through them? Because that should be possible with BlitzPlus as well...

You might want to try ...

Minions of Mirth Technology

Possible, yes - but rediculously overcomplicated and inefficient.

> FlameDuck
I tested a server in blitzplus with 150 clients sending/reciving packets to the server about 1 hour without any problem and a really fast response from server...

soon, i will test with 500 or more clients...

this might eb a stupid suggestion, but to get tround the multiple threading thing. Why not have an access datbase and four or five server programs all running simultaneously writing to the same database?

Multiple threading and database access is difficult due to synchronization issues.

While I suppose you could use a heavyweight cross process mutex and multiple BMax processes, it would be ugly and inefficient - not to mention even more difficult to schedule correctly.

Theoretically, all Turing-complete languages can perform equivalent tasks - but realistically it's just exponentially more difficult to perform certain tasks with certain tools.

yes, like what he said

Interesting, may i ask how you test it? Have you found 150 testers or have you simulated it in any way?

UO works quiet well but i havent heard anything about threading in 1997. Since when programmers use threads?
Couldnt find that info on the Net, maybe its old tech and i mix it with hyper threading..

Using one of the .net languages with a SQL Server based product is great for the backend. Either MSDE(based on SQL 2000) or SQL Server 2005 Xpress combined with one of the Xpress editions of C# or VB.net would work. VB.Net can do pretty much anything C# can do now, so not as big of a hurdle if you have only programmed Blitz.

The math disagrees with you. Bandwidth requirements grow exponentially, as the number of clients grow linearly. Even if you're only sending 64 bytes (the lowest possible size of an Ethernet frame) you'e pumping out 1.36 Megabytes each *syncronous* update. Say you have 5 of those each second (which is low, roughly about every 200ms) you'll be punching out nearly 7MB every second, sent synronously constantly being interupted by more than 1500 context switches?

I don't see how that's even remotely plausible, even if you where doing nothing else, but sending random data. I guess we have a difference of opinion on what constitutes a "fast response from [the] server".

Since about 1971.

Yes. HyperThreading is basicly a "poor mans dual core" processor. In order to increase performance in Intels single-core CPU's Intel engineers decided to give each core, two instruction pipelines. This means that while the core is executing instructions in one pipeline, it can load the other with instruction, thus significantly lowering the performance impact of a context switch.

No it's not. MSDE support expires ultimo 2007, and doesn't work at all on Windows Vista, and SQL Server 2005 Express doesn't have a scheduler agent. Add to that the 4GB data limit which pretty much eliminates it as a viable option for anything wanting to be "massive" or "persistent". A much better solution would be to get a proper database, like Postgres or Firebird.