About this blog
This log follows the development adventures of Mirage Online & Unformed.
Entries in this blog
Mirage Online was sold for good, many years ago. Whoever has it now is doing whatever they are doing.
Unformed (.com) have been moved over to support a book series of mine, I'll have more information on that later.
Osinia is now my pride and joy.
Mirage.NET is my VB.net 2008 port of Mirage Online, who's source code is released under the Creative Commons license. The Mirage Core website, which is the only official community site for Mirage products and services (http://www.miragecore.com), will have forums and categories for Mirage.NET.
As many have known, I released an old version of the VB6 source code under http://www.miragesource.com/ which is now ran and owned by William. However, since Microsoft dropped support for VB6 a very long time ago, ... you know where this is going.
Therefore, I am working and releasing piece-meal fashion a direct VB.net port (of a different version then MS). Since VB.net is officially supported by Microsoft, and most of the Mirage community are VB6ers, this should work out fine.
This is meant to be a pretty direct port from the VB6 versions. Meaning, that the programming style will most likely not make much use of the .NET advantages, we will see.
Besides those who usually use a .NET managed language, will use C# anyways :) This is meant to be the next step in moving programmers from an old version of VB to the newest.
Since there are only two Mirage products and services, basically Mirage Online, and now, Mirage.NET, the support and community is at the official community site: http://www.miragecore.com .
Linq have been awesome! I ended up creating a few extensions for basic development, but other then that, the feature rules :) I have been doing some researching for developing for OSX. It looks like one of the compilers I am using will natively support that OS in a few months or so, and that is good.
There is an OS called SkyOS (http://www.skyos.org). It's a one-man show, but have been around for years. Unfortunately, the foundation is not complete as of yet, so it's no good for any kind of server development. And it has some basic client side development possibilities. But all in all, it may work well for 2D game clients ... who knows. From what I have seen so far, it whip's Linux's butt for basic use ....
With the database back-end and the DAL complete, I turned my eyes towards networking. As you know from previous entries, Socket Tools is used due to ease of use, SSL, and the fact that purebasic have no plans for a basic server network library.
There are a few servers (software) that must be created to get this game (Unformed) off the ground. One Login server, 2 Shell Servers, 1 Core server, 1 AI server, and 1 instance server.
The login server is where everybody connects, manage their characters (add/delete, etc), and then gets forwarded to a shell server. A shell server is pretty much an enhanced relay server. They are created to run on the least amount of resources possible, with massive amount of connections.
What they do is accept a connection transfer, and forward commands to and from the core server and player. If a core server has a message/packet to send to everybody on a map, it sends one packet to each shell server. And the shell server will relay that message to everybody on that map on it's shell.
This keeps the bandwidth cost of the core server down to a minimum, while the shell servers can handle the huge traffic. Now this brings us to the core server. This is responsible for the movement validations, economy, and various other things. It accepts input from shell servers, and AI server.
Instance server(s), are available for the sole purpose of instances. Each server can hold an instance of a pre-determined amount. When a player/group enters an instance, they are transferred to an instance server that has free slots available. That server will load up the instance, and take the player's connection. Since these servers are mostly self contained, the Instance server fills the roll of the Core, and AI server in one package.
The AI server controls the MOBs, NPCs, Companions, Pets, and Minions in the game. That is the sole purpose of the AI server. With the database backend, this allows for multiple AI servers, each controlling their own portions of the AI ... Scalability at it's best :P
Since my goal is to have each server use less resources, and able to do more in a short time period .. Contention is something to watch out for, especially in threads. With that said, the only thing the login server needs to worry about is a shared (in memory) ban/suspension list. And, since the server is one of the least bandwidth/time resource hog, it can be threaded nicely.
Shell servers are a little bit trickier, they need to maintain one connection to login server, one to core server, and all the player connections. It really only need one thread for sending, and one for receiving per socket class.
The core server isn't rocket science. Environmental controls, zone controls, movement validations, economy, items, effects and the like. Really simple stuff. It has connections to AI, Login, Shell, and instance servers.
That's about it, server wise. Original graphics and music, or at least CC licensed products are a bit tough to find on the net, with permission of course. One of the mistakes with Mirage, is that it uses copyrighted graphics without permission, also known as stealing and is against the law :( Unfortunately, almost the entire Mirage based games, such as Legend of the Zodiac (Ex), Secrets of Mirage, etc follows in Mirage's footsteps, using stolen graphics, and in some cases, stolen music.
With Unformed, I want to get away from that. The way I see it, if I used stolen stuff in my game, then it's not really my game. This is for released versions. Testing is a bit of a difference as it's not really released, its for testing algorithms, etc.
Cost is another issue. Each server/hardware dedicated server costs between $20 to $300 a month to rent. For starting, this is a good deal. But once you start scaling out the servers, it gets expensive. There's the option to buy or build a server and co-locate it. But every single collocation cost I have found is extremely over priced. Head over to http://www.webhostingtalk.com. It is one of the best places to find Dedicated servers. The problem is, the top leaders in the collocation industries who are giving out false information there, even admitted to be scammers when it comes to collocating expenses, ouch!
So it's time to look for small shops ... :P Any how, back to prices. I figured $2 a month per account is adequate. At least with 100 folks, I should be able to pay about one dedicated server, after IRS takes away the taxes.
From there, as the user base grows, I can start placing the individual servers on their own hardware, then eventually add more shell and instance servers. I forgot to mention, having shells in different datacenters around the country is a must to service people in the US with decent speeds. The only catch is that the shell server would need a fat pipe for player connections, and a fast connection to the rest of the gaming network servers.
With all written above, most of the network infrastructure is complete. All except for the update server. I remember reading the Guild Wars developer interviews concerning the updating the game on the fly, claiming to be the first? I laughed since the first mmo that did that came out in 2001 ... years before guild wars.
So, since Mirage pioneered on-the-fly updating, I was looking at doing the exact same for Unformed. It's not hard, create a hash for a version, as well as files, and do a comparison. Same for all updates done.
Now, the workload could be on it's own server, instead of integrated into the game server, but why do it at all? If much of the server side logic are compiled scripts such as CScript (aka C#). Then they could be modified with out modifying the client. Bug fixes and AI changes could be done on the fly. Object data (sans id, name and image) can be modified on the fly.
The only updates truly needed are for additional/modified media (graphics, sound/music), and the media's identifiers (name & id). With that as the case, client updates are rarely (say monthly or so) needed. And even in that case, just have the Patcher run before the client runs, each time to check for updates that way.
As mentioned before, Unformed uses byte based networking. It first came into the MS community by Verrigan, then when Spodi came onto the scene, he created a nice tutorial on his site http://www.vbgore.com, you may even seen him on Gamedev.net :) However, since (it seems), I'm one of the few people who believe security is needed between a client and a server, Unformed will be using SSL for encryption. This does make the packets bigger, but not as big as string packets, since I use bytes instead.... :)
That's all I can think about for this entry. The next one should contain some actual content related info!
Last night, I went out and bought Mario Kart Wii ... Below is my fairly short review on it ... This is an honest review, not a paid fake review that most publications and websites provide.
As a disclaimer I am a huge fan of SNES and Gamecube versions. The N64 and DS versions felt rush, and had some bugs that should of been caught before release. With that said ...
The Good ...
1. It comes in a pretty box ...
2. The graphics look slightly better then the previous versions.
3. Bullet Motorcycles rule!
4. The GUI interfaces look prettier ...
The Bad ...
1. The lack of many new courses is astounding. Most of the courses were remakes of previous versions. Some made better, most not. At least the ghost track is back, but in a bad way. This shows the creativity for course building has died in Nintendo. Reusing old courses is not always a good thing.
2. Nintendo jipped players big time by severely limiting the number of driver licenses to 4. This is unheard of as most families and friends have more then 4 people ... way more. This makes this game for statistics keeping worthless. And statistics is bragging rights both offline and online. This means only the same 4 players can play, ever. One exception, if you want to be a guest, but that's just a hack. Talking about dropping the ball ...
3. Missing the most popular battle type in the history of Mario Kart. The one where you drive around the course, picking up ? blocks and shooting the opposing team. This was last seen in the SNES version ... Hello? Anybody at Nintendo play this series?
4. The wheel is a gimmick, cheaply made, and the designer forgot to try out the prototype before release to production. One of the major thing, is that the wheel was designed backwards. It is not hard, and not expensive to cut holes in the center for buttons to have the wheel face the correct way ... Don't even talk to me about the over-priced wheel. $15 for a $2 plastic wheel? Right ...
5. Motion detection is not correct. There are times where you turn left, and the car turns right .. wtf?
The Ugly ...
1. Online play does not exist. The channel and match making was offline last night. Therefore there was no way to test online play in any shape or form. This effectively limits the game to ... 75% complete ...
2. The AI programmer need to be fired and barred from AI coding for life. You know how some people hate cheaters? Well, this game is full of them, all AI. The Rubber Band effect is a known cheat, which is why most gamers stay away from games that use that cheating AI algorythem.
I have to keep reminding myself that this is one of Nintendo's major cash cows. They will do anything to shave off a few bucks to make mundo money, and the shavings show, in a big way.
I remember back when Mario Kart could be played by kids. Come to think of it, that was the Gamecube version. The Wii version totally throws away that ability and makes this game a Teenager/Adult only game. How unfortunate. It's just not easy enough for kids to play, where kids being under 10. Luckily, I still have the GC version.
With half of the game inaccessable (multiplayer), and another portion unusable (driver licenses), Nintendo should have left the game in testing for a while longer.
With all this said and done, this game can be played, in a limited fashion, making this the Windows ME/Vista of Nintendo, a huge flop. But the numbers don't lie, there are tons of sheep (like myself) who bought this game. No matter how hard I try to find something good in this game, it all comes back to the huge blunders Nintendo made in this game.
Sorry Nintendo, better test the game next time!
Well, little did I know, that Visual Studio 2008 shipped with a product called Linq. If you want to know more about it, check it out: http://msdn2.microsoft.com/en-us/library/bb425822.aspx
It solves the DAL problem in a major way :) Plus, with VS 2008 SP1 coming out with the Entity Framework as another way to provide a DAL .... It's all cheers!
You would figure a DAL (Data Access Layer) generation tool would be simple to find, for .NET 2008, but it's not ... I have found many code for manually creating a DAL, it's not that hard at all, only time consuming for even the slightest change.
So I'm off searching for a DAL generator ...
... Came across the vaporware known as CodeSmith / NetTiers. One of the problems with this product is that .. it haven't been supported (reality) in years. Lack of (usable) documentation, with existing docs outdated by quiet a few major versions ... yet they are still selling it to unsuspecting customers ... shame shame ... It looks like they are going the way Adobe did with Capture Server. Sell expensive licenses, then tell the customer, sorry, we no longer support this product ...
There is the NHibernate, but as all programmers know, XML = HUGE performance problems at runtime. I know .NET makes massive use of XML, which is a major shame, but oh well. I am looking for code, not sloppy XML .. ;)
As it stands, there are not many DAL generators for C#/.Net 2008. Most of the ones out there are either, vaporware, discontinued, incomplete, or all the above. Ouch!
Back to manually creating this layer #$%^&%#@$.
Sometimes, it pisses me off when compiler/suite developers decide to cheap out on some of their components, yet sell those very same components for $$$ to customers. Talking about a huge profit!
For example, I spent the last 30 minutes customizing a customer made C# .NET class that should of been part of .NET framework. After some googling, I have found the following:
It fit my needs, almost. So I ended up modifying it to make it a bit more full proof and integrated ;) ... at least for C# 2008.
Below is the code ...
public class IniFile
public string path;
private static extern long WritePrivateProfileString(string section,
string key, string val, string filePath);
private static extern int GetPrivateProfileString(string section,
string key, string def, StringBuilder retVal,
int size, string filePath);
throw new System.ArgumentException("Parameter cannot be null.", "IniFile");
public IniFile(string INIPath)
path = INIPath;
public void SetFile(string INIPath)
path = INIPath;
public void WriteValue(string Section, string Key, string Value)
WritePrivateProfileString(Section, Key, Value, this.path);
private string ReadValue(string Section, string Key)
StringBuilder temp = new StringBuilder(255);
int i = GetPrivateProfileString(Section, Key, "", temp, 255, this.path);
private string ReadValue(string Section, string Key, string Def)
string sTemp = ReadValue(Section, Key);
if (sTemp == string.Empty)
sTemp = Def;
public string ReadString(string Section, string Key)
return ReadValue(Section, Key);
public string ReadString(string Section, string Key, string Def)
return ReadValue(Section, Key, Def);
public int ReadInt(string Section, string Key)
string r = ReadValue(Section, Key, "0");
int.TryParse(r, out ret);
public int ReadInt(string Section, string Key, int Def)
string r = ReadValue(Section, Key, Def.ToString());
int.TryParse(r, out ret);
I am sure there may be other, better ways of doing the above and support all primary data types .net supports. But the above supports my needs nicely.
Sometimes it makes me thankful that the Pure Basic author have at least partially implemented such functionality. That still doesn't make up for lack of support.
Warning! This is part rant, part something else ... and it is an extremely long post.
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!
... Yeah ... Right ...
As some may know, Microsoft have two sets of users for their money making. Customers, and Companies/Developers. They make a massive amount of money from customers over businesses. When Microsoft developed Vista, they decided to make the OS secure and user friendly. At the same time, since developers and customers are polar opposites, Microsoft royally screwed over the developers ... The following is case and point.
Blizzard's official response to installing and using WOW on Vista is that you must do one of two things.
1. Install WOW outside of the Program Files directory. Most customers are hesitant to that change as it is different from previous windows versions. Thus you lose some customers there.
2. Install as normal, but follow this 18 step instructions to allow ALL USER ACCOUNTS on the computer FULL AND COMPLETE access to the WOW folder and sub folders. This is a major security breach. And, on most Vista installations, after setting the security, vista still will not a let you do updates there!
Now, why do Vista users have special instructions while XP users do not? One word ... Microsoft!
All modern software uses an internet patching process to update their software "on the fly". This allows companies to update their software quickly, in case there is a bug or if a criminal found a weakness ... This is STANDARD practice, it's a no brainer.
Microsoft decided to go against the world, and prevent this from happening by locking down the OS. Why? Customers generate more money for the company then developers.
I recieved a new computer that came with Vista Home Premium AKA Sub Windows XP Pro. Developing on it is a nightmare. I'm wiping the computer clean, and installing XP Professional on the bugger, it's faster, safer, and more user AND developer friendly.
What about DX10 games? I only know of one that I was slightly interested in, Halo 3. But after awhile, I realized that the Halo series is the literal rock bottom of the FPS genre. People still laugh when they hear that name .. Poor Bungie.
So all and all? Mirage will support Windows XP. If you have Vista, I will provide some simple instructions on installation, but you have to be on your own. Vista is still in Alpha Testing, and is not meant for public consumption.
Which reminds me. I need to change the "forums" link on the site to "Community', and point it to http://www.miragecore.com. Spoon will be in charge of that site and forums. This will leave me to do the programming, while he takes care of the community.
Well ... welcome to the first post for my game! I am strictly keeping my development adventures on this blog, and all other game related on it's site. Most of my ramblings are technical, after all, I am a government programmer by day, and a game programmer by night. If this isn't your cup of tea ... then prepare to be bored!
The development process will follow standard practices and terms. Alpha means features being added and bug testing. Beta means bug and stress testing, while final is just that, the final version until the next round.
This game is set in a universe I created in 1994. It follows the rise and fall of technology in our current time, and the reintroduction of other forces at work. Therefore, this game is officially a "Massive" Online RPG/Strategy Game. It makes heavy use of both Magic and Technology.
This game is 2D. The only reason for this is due to the poor 3D technologies available at the time of this post. If real-time realisitc 3D engines become available to the general public, I will convert the game over to that format :)
The database backend is SQL Server 2005. This is, hands down, the most DBA & developer friendly database available. The windows game clients are 32bit until 64bit windows come out in a few years. There may be an OSX client available after launch, but never a linux client.
No main stream languages are used as such langauges are overly complexed, or are scripting languages (think JIT), therefore not safe for client side game development. The languages used may be revealed in the future :)
The releases follow the "Release Often, Release Small" rule. This will keep the game constantly updated and "fresh".
The next post should detail the first alpha release. Following the above rule, don't expect too much out of it :)