Wow, I started this blog to chronicle my tales of developing a game. However, it turns out that a previous game of mine, Mirage Online, needs some TLC (Tender Loving Care), therefore ... This blog will be concerning my development on multiple games *sigh*.
About 90% of the Visual Basic 6 games, engines, and "MMORPG Makers" are from Mirage Online's source code. I released the source code years ago, and since then, the result is what you see these days. Some people thank me, others curse me, but oh well!
With that said, every Mirage derived product is 100 times better then Mirage Online due to one thing. I stopped developing Mirage several times, and most of my developments were bug fixes, not feature completion and the like. Another very bad aspect of the game are the graphics used. Squaresoft would not be pleased.
Since Visual Basic applications will not run on Windows 7, and since that OS will be out next year. I really need to rewrite Mirage with a language supported by Windows 7. I don't have to worry about cross-platform as my customers are windows based. However, OSX is catching up there, so that is considered. Linux (for desktop) is dead for all intent and purposes.
There are the .NET languages, however, only one of them is suitable for client programming, the rest are business suicide. Reason being? .NET (managed) and Java applications provide the source code with the "executable". If you want to keep your properties safe (and not open source/public domain), no business would use those languages for applications that will be on the customer's computers. That is Business 101 folks :)
Visual C++ is not worth using for a small game. The language is more complexed then needed, making the ROI virtually nill. However, C# is excellent for server side programming for the time being.
This means other languages must be used for client side development. Delphi/Pascal is dead, the indy languages are pretty much dead. However, a few "Basic" variants are still alive and well. RealBasic (slow!), purebasic (fast, not really supported), freebasic (draconian syntax), and powerbasic (slowly dying).
So I am pretty much stuck with VC++ or a Basic variant. It's pretty much a choice between taking a year OR taking a few seconds to write "Hello World", respectively. You can guess which one I choose. Granted, the above is over-doing it. But it's true, VC++ is horrible when it comes to coding. It shouldn't take forever to code simple tasks.
Now, I don't see a reason why I couldn't have the best of both worlds, why not C# for the server side? This will allow me to code extremely fast and tight server side code. And, it allows me to code for 64bit Oses with Visual Studio 2005 and higher. This is a high point as the next server release (after Windows 2008) is 64Bit only. Another high point is that I would need to use more then 4GB of RAM for data storage down the road. Plan for the future!
On the client side, I could use a Basic variant. Since speed is the issue, that leaves purebasic. However, that would mean I am on my own if I need help, as support is a huge problem with that language. Oh well, that's life!
Now with my languages decided, technical libraries are needed for the rewrite. For the server side, it is the SQL Server database and Socket Tools for networking with SSL. For the client side, I need Socket Tools, and DirectX9. The Socket Tools are needed due to the ease of use for SSL.
The other reason is that purebasic have incomplete network libraries. The author will not complete the network library, so I ended up buying Socket Tools. So if you are looking at purebasic for a networked application, be prepared to fork some more monies for a complete set of network libraries and mark it off as another cost of doing business.
If you have done any MMORPG programming, especially the network layer, and you care for your customers, you would have encrypted, every, single, packet. This is a good thing! If you care for your customers, more will come. If you don't, you would over sell your service like Blizzard (WOW) and CCP (EVE) currently do.
Overselling is another name for fraud. However, if you commit fraud, and call it overselling, then it is 100% legal in the USA. Banks, Phone Companies, Web Hosts, WOW, EVE, all of them over sells. Funny how Corporate America works, eh?
A great side effect of encrypting all packets is, you will know how your network infrastructure is doing, and how much it can hold. If you start seeing some server induced lag, then it's time to re-evaluate that structure! Another side effects are that the packets are now bigger due to encryption. But like I said, plan accordingly, don't screw your user base, and you will come out great.
There are two types of network protocol types possible, Strings and Bytes/Binary. A great example of a failed network protocol is IRC. The server hardware/bandwidth requirements are massive to to an extremely horrible protocol.
Unfortunately, Mirage was coded the same way back in 2001. Mirage have topped out over 100 players with minor lag on a 10mbit connection, not even 1/2 the pipe was used, so the lag was server induced. At it's 2nd highest peak, there were 60ish players, and the low end was 20ish players. And again, no lag issue from 60 and below.
The problem was having everything in one thread. This slows down the server in a major way. So the solution? Multi-threaded server! 1 Thread for listener, 1 thread per connection, main thread for looping, 1 thread for npcs, etc, and so on. With C# 2008, thread syncing is pretty much a non-issue.
Windows 2003 and higher can hold tons of threads per application very nicely. Now that dual, quad and 16-core servers are available, it is even better. Yes, you can buy a 16-core motherboard and cpus at Newegg.com ... If you run everything as 64bit, it's even better. Any how, that's a bit of an over-kill for this game, so I have a dedicated server running on Dual cores.
This does not deal with the bandwidth issue. However, at the game's peak, there were no bandwidth issue. I can code the client/server in a way where I can swap to byte based protocol with-in a day's worth of work.
Now on to databases. I had a long hard fight with this. My four options were Oracle, SQL Server, mySQL, and Firebird. To make this short, Firebird was extremely slow. Oracle is expensive unless I use the 2G express version. And that version is to small. mySQL have no documentation. What I mean by that is, almost all the documentation provided for mySQL does not apply to the current released version. Most, if not all of the documentation, for simple triggers and inserts will not run on the current version, ouch! That leaves SQL Server, it runs, the documentation is most up to date. And it's triggers actually work. Bingo!
Hibernate is the DAL I use at my day job. It's awesome for data that does not need saving 100x a second ... much like Mirage. Only data need saving is world state and player state. That is all. There is even a NHibernate for .NET ... sounds like a match, we'll see!
Why in the world would I use DX9 when DX7 works? Two reasons, Vista does not fully support DX7 applications and will artificially slow down DX7 applications, tried and tested. And two, Purebasic have an extremely limited DX7 library. The Purebasic DX9 support is slow, however, there is a 3rd party Dx9 library that works in purebasic, and is fast.
People have asked me about Unicode support. For Mirage, I have no plans to support Unicode at this time. There is 1 person out of hundreds that do not speak American (not English). If we get more, I will need to consider it.
With the release of the source, there have been many criminals trying to break the game by making rogue clients. SSL will help fend off some, while account validation will fend off some other. Basically, this will check if the email is valid. It won't prevent people from using rogue clients after the account is created, but I wont get into that yet.
However, the only 100% way to prevent people from hijacking your game, is to make it browser/web based. That way, nothing is downloaded and can be modified on the player's computer.
Whew! Told you it was a long post!