The 'MMO' Demo - V1 - Client Source Code released

[James Proctor]

I have never read anything about having a 'local server' for a MMORPG. In this framework there won't be one. If you want to set your own version of the framework up like that then go for it but it won't be officially supported. For multiplayer versions of single player games where a client acts as the server then theres a local server but for MMOs there isn't any local server.

[JMatthews]

I may have missed something, but I don't see what benefit you would get over folding this into the client itself. Why not just have the client handle communication between the server?

In order to have a client that is responsive to user input you're going to have to simulate the game state at the players desktop. You can't have the user press the fire button and wait on the round trip before you allow the avatar to start shooting.(lockstep)

Using your physics example, if you run the authorative physics at the client level you'll get hacked. If you run it at the server level you can jump off a cliff(slowly I might add) and then have to wait for the round trip before you'll begin to fall.

By separating the client and server code locally(which you'll be doing ultimately anyway), and binding them through commands, you have a scalable system that allows you to do some neat things. For example, your remote server is really just the same software a client is running, minus the display and sound layer.

[JMatthews]

I have never read anything about having a 'local server' for a MMORPG. In this framework there won't be one. If you want to set your own version of the framework up like that then go for it but it won't be officially supported. For multiplayer versions of single player games where a client acts as the server then theres a local server but for MMOs there isn't any local server.

That's fine James, although, I am certain you'll implement one eventually. It just won't be elegant because you won't be designing for it. Let me take another stab at it because I feel like I'm missing you.

Understand when I say server, I am referring to a kernel that provides a "service". A local server provides the local simulation of the remote servers gamestate.

I'm not talking about a udp or tcp server. I'm talking about a command interpreter that reads events.

Unless you simulate the gamestate locally, then you're talking about implementing a very thin client, essentially a terminal. Im confident you don't plan on sending a stream to the remote server when a user mouses over a gui element to check and see if the element has a mouse over event, and then not execute it until the remote server sends the go-ahead.

That means that will in-fact be simulating the local game state. My point was that you should have a single coupling between the client and the local simulation, and that coupling should be robust enough to handle your remote updates as well.


Other wise you'll find that what works fine for your local simulation isn't going to work at all for your authorative server.

[Nick Taylor]

So you are essentially saying that the display program and the services program should be separated, so that you have one program that displays the game, and one that handles everything else, physics, communication to server, etc.?

[JMatthews]

So you are essentially saying that the display program and the services program should be separated, so that you have one program that displays the game, and one that handles everything else, physics, communication to server, etc.?

Absolutely.

If you take a step back, a big step, you'd have the following topology.

Client-----Server.

And server can be anywhere in the world. What's the relationship? The server provides a service and the client consumes it. That's a standard browser/server relationship. Games are different because they're interactive. We can manipulate the server state in real time. So we need a means to manipulate the server.

If you zoom in, to the macro level, you'll see that client is really made of a lot of subsystems, (Kernel, OS Interface, Audio Manager, Event Manager, Process Manager) etc...

If you design your client such that you have a clean encapsulation of the client level and the game service level, with a single coupling(I call it events, you can call it whatever works for you mentally) Then your client doesn't care what service is providing the events it's consuming.


That means that it can treat a single player game like a multi-player game and be none the wiser. It's just generating events and consuming events.


At the game service level, in order to support multiplayer you add your network service. So the network service does your serialization and transport to whichever remote server is authorative.


Here's why this topology is important.

If you have a single player game and you want to add multiplayer, in this topology you add serialization and transport to your game service(along with some prediction code) and you're done. The client is still generating and consuming the same events.

In fact, you can switch to a different client and the game service will keep on trucking, you can switch to a different network service and the client will be unaware.

Because you're going to have to run a local simulation to have a responsive client, you're going to end up implementing a local service regardless. It's helpful to treat the local service like you would the remote service, and use the same coupling. That way you're only coding and maintaining one service.

[JMatthews]

I just want to be sure I understood you. I don't mean two .exe's

I mean a logical decoupling of the client and the game services.

The remote server will be a different .exe of course.

[Nick Taylor]

Yeah, I think I understand you now. This essentially allows for easy manipulation of the client and the local server with them being modular to one another.

[hitbox]

Hey James, you are doing some great work here

Can anyone shed light on why I'm having issues with missing files "getche.h" and "variableDeltaSerializer.h"
perhaps they were accidentally not checked into svn?

[James Proctor]

Hey James, you are doing some great work here

Can anyone shed light on why I'm having issues with missing files "getche.h" and "variableDeltaSerializer.h"
perhaps they were accidentally not checked into svn?

Check to see what version of RakNet you are trying to compile against. Those files should be included in the latest version of RakNet. If you aren't using the latest version then you will need to upgrade RakNet.

[James Proctor]

Also I just got to thinking and I haven't uploaded all the Server Plugins to SVN. I am doing that now. The plugins are dependent on each other so theres a order that you need to compile them in.

Compile Order:
DataStore_Plugin
User_Plugin
all the other plugins.

If you compile them in that order then they should compile no problem with the right version of RakNet.

Other things you will need:
Latest MySQL Database Server (I suggest using WAMP if your fairly new to MySQL)
MySQL Connector C++ 1.0.5

[Nick Taylor]

What version of RakNet do you need?

[hitbox]

What version of RakNet do you need?

v3.8
http://www.jenkinssoftware.com/raknet/d ... et-3.8.zip

[James Proctor]

This past weekend was very busy for me so I haven't gotten much done. Some Close family friends of my family is moving out of state today so Saturday we had them over for dinner one last time, yesterday we went over to their house to help them load their stuff into the trailer, and today we will be going over and seeing them off. After today things should gradually return to normal and I should be able to get more done. Look for further updates on here and to the framework's development site. Have a great day every one! Also if your using the framework please join our forum and get some discussion going on there. http://dev.riseofheroes.com

[James Proctor]

Ok well I am working on this framework in what little free time I have. For any one who downloaded the framework source code were you able to compile it or do I still need to work on getting it so it can compile on other computers? Also do you guys have any suggestions or ideas for it?

[MikeTC]

Ok well I am working on this framework in what little free time I have. For any one who downloaded the framework source code were you able to compile it or do I still need to work on getting it so it can compile on other computers? Also do you guys have any suggestions or ideas for it?

I downloaded the framework and the source from SVN, and I think there were some missing files, the matching cpp file for Plugin_Framework.h as one I recall. I took a few guesses as to what was supposed to be going on and wrote my own Plugin_Framework.cpp. I have managed to get it working on OSX and the plugins seem to work fine, I would anticipate a Linux release wouldn't be too much more work. I did remove the Windows specific dll declarations and made those OSX and Linux friendly. I still have a few problems here and there, but I can upload my version of the source somewhere if it would help at all.

The most annoying at the moment is that the strings in the PlayerData struct as well as the WorldObject struct get sent as blank. I don't think that is a framework issue, just a RakNet thing I haven't figured out yet. I am still quite new to this sort of stuff.

All in all it seems like a nice framework and pretty flexible.

[James Proctor]

I do not think that the Cpp files need to be included with the Plugin Framework SDK. The Plugin Framework it's self is NOT open source. That's why I don't have a SVN Repo for it.

[James Proctor]

Just to let you all know that this framework was put on hold. The source code is still available if any one wants it but development has stopped on it for atleast right now. We really just want to get a good quality MMO released so we have opted to use Unity3D and SmartFox Server for a small scale MMO like YoVille. We have a alpha webclient online at http://www.riseofheroesmmo.com/KingdomC ... lient.html If you would like to check it out please send me a PM and I will get a account created for you. We will also be having our First Alpha Build of our standalone client in the coming weeks.

[CrimsonGT]

That looks really good

[xavier]

small scale MMO

Isn't this an oxymoron?

We have a alpha webclient online at

Since you are no longer using Ogre, I'd ask that you please stop posting in these forums.

[jacmoe]

small scale MMO

Isn't this an oxymoron?

Yes.
And No.

http://scientificninja.com/blog/m-is-for-massive

The grim truth of the matter is that most hobby games will never achieve nearly enough players to actually scale and stress the system enough to be considered an MMO on the basis of that first, critical, “M.”

But then again, does it matter? There are generally two kinds of person who want to make an MMO as a hobby project: the guy with a lot of ambition and not a lot of grounding in reality who really does want to make the next World of Warcraft where you can participate in a massive online world in which you can do anything, even marry The Hulk, and the guy who really just wants to make a cute little persistant world of his own imagining that he can log in to and fool around in with his buddies. There is no hope for the former — and regardless, if they manage to get anything off the ground, it will end up being the latter kind of game anyway. The latter’s goals, though, are actually quite achievable — yes, they are misusing terminology by calling their projects MMOs, and they should be gently corrected. But there is no reason to jump down their throats, telling them how impossible their projects are and how they will never, ever have any success.

Amen to that.

And, I am going to move this topic to off-topic and I am hoping that James Proctor does not yet again change his mind to switch back to Ogre.

Not because I don't want him on these fora, but because then it would just turn into Duke Nukem Forever...
They just spent well over 12 years switching technologies...

[jacmoe]

/* moved to Ogre in practice */

[chaosavy]

Ithink this is pretty funny