vbGORE is an open source, free MMORPG engine developed in Visual Basic 6 that has been in heavy development for over a year. It supports multiple connections with great speed with support over as many servers as you want. The server offers a lot of security from countless lines of packet integrity checking to streaming packet encryption, using a MySQL database to hold information. The client uses DirectX 8 to offer powerful 2d graphic support and manipulation with effects from alphablending, lighting and rotations to even a custom particle engine. vbGORE includes a fully playable demo game with spells to cast, quests to beat and NPCs to slay so you can see everything vbGORE has to offer. Main site: http://www.vbgore.com/ Download: http://www.vbgore.com/Downloads Screenshots: http://www.vbgore.com/Screenshots_From_1.0.x Forums: http://www.vbgore.com/forums/ More game information: http://www.vbgore.com/What_is_vbGORE [Edited by - Spodi on July 22, 2007 9:15:34 PM]

Greetings Visage,

The server load distribution is done by setting which servers run which maps. When a player changes maps, a verification is done to make sure they are still on the correct server. If they aren't, the client is told to disconnect then reconnect to the new server (this is all done behind-the-scenes, so the only thing the user notices is a slightly longer map switching). While the user is changing maps, the server saves their data to the global MySQL database that all servers get their information from. When the user connects to the new server, the new server just grabs their information out of the database and they become the handler. The old server just unloads all information about them.

The servers are allowed to communicate between each other, too. They will send packets to one another if a player sends mail or a private message to a player on another server, for example.

The whole "multiple server" system still requires heavy testing to make sure it works correctly, but from all I have tested it seems to work fine.

The language support is done by using a list of system messages, each in different languages. To prevent heavy packet loads, the server sends common messages by ID instead of by the message itself, so that way something like "The requested player is not online" goes from about 37 bytes (34 + packet header + string header + color) to 2 bytes (packet header + message ID). The client will first check the language specified by typing the /language (/lang for short) command. If the message exists in that language, it will use it, but if not, it will fall back on English. So as you can see, NPCs names are still English, and quest information will still be presented in English (unless moved to the client, which would use the same system described above basically, but risk expose the quest information to the user), but system messages are translated. It works for NPC's chatting, too, which is also done pretty much the same as above, but in a lot more sophisticated format.

I'm not exactly sure what you are referring to when you said, "Have you developed a method for actual game creation". Care to rephrase that for me? ;)

Yeah, a lot of it is purely code-based. This is mostly because I find scripting would be a combination of slower and more limiting then directly coding, along with harder to write. With VB6, you got the IDE with its syntax and powerful error handling, but with a lot of scripting languages, it'd simply just crash if there was any error. Of course, theres some powerful scripting languages, but then still, you have to learn two languages instead of one. I'm definitely not anything close to a pro at scripting theory and writing, but I have never found much help for it in open source projects like this.

Thats a cool article on the language - I'll check it out! I'm not too worried about small grammar errors in cross-language support, though. As long as the people can figure out what the message means then I'm happy. ;)

The distribution system can handle as many maps per server as it needs. By default, its set up all maps go to one server. The load balancing is pure manual - no automatic checks. One reason for this is that load balancing itself takes a bit of a load to do itself, so I doubt I'd be able to do it very well any time soon without more work then it is worth.

That would be a cool idea, though, having one server pick up if the other drops. Though, I can't see an efficient way of that working. The other server would have to maintain a lot of the same memory as the server that crashed, which would require a lot of communication between the two.

Thanks for the feedback! :)

I noticed your networking technology is based upon the Winsock API - please tell me you didn't use select()? :\

No Select(), I use WSAAsyncSelect(). I'm not as knowledgeable with the Winsock API as I would like to be, so I wouldn't be surprised if the socket isn't superb, but I believe it is written quite well. You can view the code in the \Code\GOREsock\ folder for the socket control.

Edit: You can now view it online here at http://www.vbgore.com/code/100/Code/GOREsock/

[Edited by - Spodi on May 13, 2007 6:43:30 PM]

Thanks Dumptruck! Any resolution is supported, but one constant resolution must be used for all clients and recognized by the server, so either 800x600 or 1024x768 (if you don't mind cutting out some lower-end computers) is recommended.

As for modifying the interface... it could be a lot better designed, and I hope to some time in the future. Theres an article that will help lead you through adding new windows to the interface, though, which can be found at: http://www.vbgore.com/Adding_windows