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

[James Proctor]

The MMO Demo is a altered version of the 'Player' Demo. I was going to call it the Player Demo 3 but didn't want to in case the Player Demo does come out with a 3rd version.

The 'MMO' Demo V1 includes all of the features of the Player Demo v2 with the addition of very basic Combat. The Server also uses my Raknet Plugin Framework.

This Demo uses 3 Plugins:

Com_Plugin - Communication Plugin for World chat
User_Plugin - Controls all of the other functionality that comes in the Player Demo 2 (User management, Movement, ect) as well as stat control.

Stats can be added or updated with the following code: User_Plugin::getSingleton()->getPlayer(DefenderID)->setStat("Health",defendersHealth);

I know the debate about using singletons but the Plugin Framework only loads each dll once so there can only be one copy of a Plugin at a time so I figured using singletons here would be the perfect solution to allowing plugins to interact with each other.

Combat_Plugin - Controls all combat related stuff

So far graphically nothing has changed from the Player Demo 2 so for screenshots you can look at the Player Demo 2.

I am interested in hearing what people would like to see in the demo for features and I will try to add as much as I can. If you would like to create Plugins for the demo then I have released the Plugin Framework under the BSD License and you can download it from http://dev.riseofheroesmmo.com/Engine/R ... rk_SDK.rar

This demo will be used as a proof of concept for the Plugin Framework. I will be releasing a binary version of the demo in a couple hours.

[jacmoe]

Screenshots - or I'll move this topic out.
Screenshots - or it didn't happen.

[James Proctor]

As soon as I release the Binary demo I will post screenshots with it. It will be with in the next hour.

[James Proctor]

MMO Demo v1 - Standalone Demo

Binary Demo:
http://dev.riseofheroesmmo.com/MMODemo/MMO.rar

Source Demo:
Will be released at a later date after I get some feedback on the binary version.

Directions:

1. Run 'Server.exe'.
2. Run 'Client.exe'.
3. Login with any nickname.
4. Move around the world by clicking on the terrain.
5. Talk by interacting with the textbox and 'Say' button.
6. Take a screenshot with 'F1'.
7. Toggle wireframe mode with 'F2'.
8. Target a Player by clicking on the Player.
9. Attack the Target by pressing A. Attacking with out a Target will crash the server.
10. Exit the demo with 'Esc'.

*NOTES*

Combat - The Combat plugin at this point is very basic. The Equation for Combat is as follows:

AttackerStrength/DefendersDefense*AttackerMod
20/10*5 = 10

[Azgur]

What kind of user-limit and scaling of hardware does this demo have?

[James Proctor]

Not really sure. I haven't done any testing of it yet to find that out. That is one of the things I would like to have tested as proving my Concept for the Plugin Framework.

Right now the Server allows 15 connections but that can be increased in the Server.cfg file located in the Server folder.

[James Proctor]

What kind of user-limit and scaling of hardware does this demo have?

I just created a test client to see how many connections I could have (the test client was non-graphical). I got up to 500 connections using about 50% CPU.

CPU Specs:
2.3 gighurtz CPU (something like that but not completely sure. In any case the Computer is a 2 year old $400 walmart special so it's not all that great.)
3 gigs ram
Cable Internet connection 5mb down and 1mb up

[Rhynedahll]

Is there a particular reason that you are holding back on the source?

[James Proctor]

Right now I have Dependencies scattered through out my computer. I need to Organize the project into a single folder and then the source will be added to sourceforge. I had wanted to release the RakNet Plugin Framework under the GPL but Rak'Kar said he wasn't sure the GPL was compatible with RakNet's Indie license and I don't have the money for the legal fees to get advice about it so the Source will include the Plugin Framework SDK not the full source. However the full source for the client, Server application, and all the Plugins will be included. There will be the source for a very basic Example plugin that has just enough to be loaded by the Plugin Framework that you can use as the base for your plugins.

[James Proctor]

251 Clients Connected:

[Lord LoriK]

Sounds good so far. Are you simulating something like player movement of many of them at the same time to check the bandwidth and CPU usage under those conditions, or they're just standing still?

[James Proctor]

They all move around. They all send their movement packets pretty much at the same time. When they do there is some lag if I try to send a movement packet my self but it doesn't take to long for the server to handle it.

[James Proctor]

In the next few days I will be releasing the source code. This really is not a demo. It's more of a framework for creating Multi-player games hopefully to the scale needed for MMOs. As such there are things that will be needed such as a working mySQL server. Right now I am working on the Data Storage Plugin. It's the plugin responsible for working with the mySQL database (or whatever type of database you choose to use it will require a fairly major rewrite for any other types of database). While a player is connected it's data is stored in the Server's Memory. When the Player signs out the data is sent to the DataStore Plugin (DataStore_Plugin.dll) and is added to a que awaiting to be saved. The que is cycled through every so often and the data in the que saved to the database. The Que is then cleared and the cycle restarts. There will be different ques for each type of data that needs to be saved and they will be saved at different times so that everything isn't trying to save all at once.

[James Proctor]

I am now able to load objects from the mySQL Database. I currently have 9 objects in the database that are sent to the client when you first login.

Here is a screenshot showing the progress:

[stealth977]

James:

what kind of object management are you using? Component based? Do you have a working game engine?

[James Proctor]

James:

what kind of object management are you using? Component based? Do you have a working game engine?

I spent last night starting to design the Entity Manager. The Entity Manager will be using Raknet's Replica Manager 3 for managing the entities and keeping everything updated across the network.

There will be a Entity Base class which will handle all of the most basic functions. Then every game object will be broken up into 3 types of entities:

Static Entities - Entities that will remain in place through out the lifetime of the game.

Buildings
Trees
Rocks
Barrels
Crates
Clutter Objects
Grass

Movable Entity - Entities that will move around in the game world

Players
Pets
Mobs
Bosses
Vechiles (including Mounts)

Dynamic Entity - Entities with changing stats or that change the stats of other Entities.

Items
Weapons
Armor
Crafting Items
Quest Items

Base Entity Class - Raknet Methods for creating and destorying objects.

I am currently playing around with Replica Manager 3 trying to figure everything out and then I will continue with the development of the Server Side entity manager. The Client side Entity manager will have to be worked on as well at some point soon.

[wdenslow]

Fantastic job man. This is going to be a great framework. I envy your skill!

[Lord LoriK]

Are you considering some sort of client-side cache for static entities? I know that some OS MMO(-like) projects don't do that and suffer a lot from the bandwidth usage spikes caused by clients logging in a complex area.

[stealth977]

1 - Although i do not have much experience with Online game design, i do agree with Lord Lorik, actually it would be wiser to zonify the area and check for checksums before loading stuff from the server, for all the static stuff... (checksums would guarantee that the client side object data is not altered, also if it is not, would prevent them to be resent to the client)

2 - I asked my last question because, i always wanted to make a client/server version of Ogitor, where the editor would behave a bridge to server and modify the scene running on the server, realtime... So there may be a possibility for such a cooperation, like having an active server of your test world and Ogitor having the ability to connect to it and edit it realtime with the opportunity of having multiple clients editing the world at the same time...

[James Proctor]

1 - Although i do not have much experience with Online game design, i do agree with Lord Lorik, actually it would be wiser to zonify the area and check for checksums before loading stuff from the server, for all the static stuff... (checksums would guarantee that the client side object data is not altered, also if it is not, would prevent them to be resent to the client)

2 - I asked my last question because, i always wanted to make a client/server version of Ogitor, where the editor would behave a bridge to server and modify the scene running on the server, realtime... So there may be a possibility for such a cooperation, like having an active server of your test world and Ogitor having the ability to connect to it and edit it realtime with the opportunity of having multiple clients editing the world at the same time...

One of the things I had planned for my old engine was using Ogitor as the world editor and extending it with network support and a mySQL exporter for exporting the objects directly to the database. I would love to see a Hero type World Editor where you could have multiple people working together at Designing the world. Once we get to the point that we can start working on that type of stuff I would love to work with you guys to see that happen. At this point though I am facing a problem of having to completely redesign the client in order to use the entity Manager I have been working on. For some strange unknown reason it refuses to work with the Player Demo 2's client. I have a small test client however that it works fine with for the most part.

[Nick Taylor]

I was just going to mention that that feature would be like HeroEngine. That would be a great feature for Ogitor, and you might also want to look at their video for it, as there are other features that would also be a great advantage to Ogitor.

[Brutal]

This is looking fantastic. When I started using Ogre about 8 months ago I just took to changing around the Player Demo to get the feel of things. I managed to get the new terrain from 1.7 added to it, added a sound manager, and started trying to add physics but got confused (starting with Havok might have been a bad idea for a newbie). I kind of gave up as it was a mess, but I learned a lot from it. I really look forward to you releasing the source for this, as I would like to start doing the same thing, and maybe get somewhere this time lol.

I really like the idea of the MySQL database and what not. I have a dual quad server colocated, so if you want to do any big tests or anything like that let me know. The machine has sat empty for a year so I would be happy to contribute.

Do you have any ETA on source release and do you have any problem with us posting code changes/additions to this thread once you do to perhaps contribute to expanding the project?

[James Proctor]

No I would not have a problem at all with people posting changes or additions to it here. In fact I would love to get a full library of Server Plugins available for people to use and/or change to their needs. The Plugins implement Server side features such as Guilds, Combat, Voice Communication, ect.

I have already released the Plugin SDK for creating plugins if your interested in starting with that. In fact I have made some changes to the Plugin Framework so I should get a updated SDK released here soon.

Also if would help to speed things up if I could get some help on client development. Being the only programmer right now things are going kind of slow.

Just for an example of how I create the plugins here is the very basic Combat plugin:

header:

Code: Select all

class COMBAT_PLUGIN_API Combat_Plugin : public Server_Plugin {
	std::string pluginName;
	RakPeerInterface *server;
	User_Plugin *user;
public:
	//Methods Inherited from Server_Plugin.
	//returns the name of the concrete plugin
	const std::string& getName() const;  
	//Install is called when the Plugin is first loaded. Actions here should not be dependent on other plugins.
	void install(); 
	//Initialise is called once all the plugins have been loaded. Here you would place any action that is dependent on other plugins.
	void initialise(); 
	//Shutdown should clean up any thing that is dependent on other Plugins.
	void shutdown();     
	//Uninstall is the final method for shutting down the Plugin.
	void uninstall();
	//Updates the plugin each frame.
	void Update(float deltaTime);
	//This is the method for handling Packets. It's up to you how you call this.
	//One suggestion is to have a Message ID SERVER_PLUGIN that calls this when recieved.
	PluginResult handlePacket(Packet *packet);
	//Sets the instence of the RakPeerInterface to use for sending packets
	void setRakPeerInterface(RakPeerInterface *peer);

	//Singleton Methods
	//static Combat_Plugin* getSingleton();
	Combat_Plugin();
	~Combat_Plugin();

	static Combat_Plugin* getSingleton()
	{	
		static Combat_Plugin *singleton;
		if(singleton == 0)	
		{	
			singleton = new Combat_Plugin();	
		}  	
		return singleton;
	}

private:
	Combat_Plugin(const Combat_Plugin*);                 // Prevent copy-construction 
	Combat_Plugin* operator=(const Combat_Plugin*);      // Prevent assignment

	void Attack(int AttackerID, int DefenderID);
	void AttackPacket(Packet *packet);
	int doAttack(int attack,int defense,int mod);
	void AttackSuccess(int Health, int Attack, unsigned short DefenderID, unsigned short AttackerID);
};

and source:

Code: Select all

Combat_Plugin::Combat_Plugin()
{
	pluginName = "Combat_Plugin";	
	PF_Version = 0.1;
}

Combat_Plugin::~Combat_Plugin()
{
}

const std::string& Combat_Plugin::getName() const
{
	return pluginName;
}

void Combat_Plugin::install()
{
}

void Combat_Plugin::initialise()
{
	user = User_Plugin::getSingleton();
}

void Combat_Plugin::shutdown()
{
}

void Combat_Plugin::uninstall()
{
}

void Combat_Plugin::Update(float deltaTime)
{
}

PluginResult Combat_Plugin::handlePacket(Packet *packet)
{
	// The first byte of the packet's data is always the packet ID		
	unsigned char packetID = packet->data[0];
		
	// If the packet is timestamped, skip over the timestamp bytes to get our real packet ID		
	if(packetID == ID_TIMESTAMP)		
		packetID = packet->data[sizeof(unsigned char) + sizeof(RakNetTime)];
		
	// Handle the packet based on its ID		
	switch(packetID)		
	{			
	case CLIENT_ATTACK:
		AttackPacket(packet);
		return STOP_PROCESSING_AND_DEALLOCATE;
		break;
	}
	return CONTINUE_PROCESSING;
}

void Combat_Plugin::setRakPeerInterface(RakPeerInterface *peer)
{
	server = peer;
}

void Combat_Plugin::Attack(int AttackerID, int DefenderID)
{
	Player *attacker = user->getPlayer(AttackerID);
	Player *defender = user->getPlayer(DefenderID);

	int attackerStrength = attacker->getStat("Strength");
	int defenderDefense = defender->getStat("Defense");
	int attackerMod = 5;
	int defendersHealth = defender->getStat("Health");
	int attack;
	attack = doAttack(attackerStrength,defenderDefense,attackerMod);
	defendersHealth = defendersHealth - attack;
	user->getPlayer(DefenderID)->setStat("Health",defendersHealth);
	AttackSuccess(defendersHealth,attack, DefenderID, AttackerID);
	if(defendersHealth <= 0)
	{
		std::cout << "Player Died \n";
		user->getPlayer(DefenderID)->setStat("Health",100);
	}
}

void Combat_Plugin::AttackSuccess(int Health, int Attack, unsigned short DefenderID, unsigned short AttackerID)
{
	AttackStruct attack;
	attack.AttackAmount = Attack;
	attack.AttackerID = AttackerID;
	attack.DefenderHealth = Health;
	attack.DefenderID = DefenderID;

	RakNet::BitStream AttackSuccess;	
	AttackSuccess.Write((unsigned char)COMBAT_ATTACKSUCCESS);	
	AttackSuccess.Write((char*)&attack, sizeof(AttackStruct));	
	
	server->Send(&AttackSuccess, HIGH_PRIORITY, RELIABLE, 0, UNASSIGNED_SYSTEM_ADDRESS, true);
}

int Combat_Plugin::doAttack(int attack, int defense, int mod)
{
	return (attack)/(defense)*(mod);
}

void Combat_Plugin::AttackPacket(Packet *packet)
{
	unsigned short attackerID, defenderID;
	// Create a BitStream from the packet to parse the data
	RakNet::BitStream clientAttack(packet->data, packet->length, false);

	// Ignore the packet ID
	clientAttack.IgnoreBits(sizeof(unsigned char)*8);
	clientAttack.Read(attackerID);
	clientAttack.Read(defenderID);

	Attack(attackerID,defenderID);
}

extern "C"
{
	// Plugin factory function
	__declspec(dllexport) Server_Plugin* Create_Plugin()
	{
		//allocate a new object and return it
		return Combat_Plugin::getSingleton();
	}

	// Plugin cleanup function
	__declspec(dllexport) void Release_Plugin (Server_Plugin *p_plugin)
	{
	}
}

[Brutal]

Very nice, I will try and pull out my old code for the sound manager later tonight, and start working on a Sound System plugin. I used FMOD originally, but since you need a liscense for it, I will look into alternatives like OpenAL or something similar. The original I wrote basically just handled everything sound related, such as instances of sounds, play/stop/etc. so that might not be a bad place to start.

[James Proctor]

There is no Plugin System for Client related programming yet unless you were to use Ogre3D's built in Plugin framework. The Plugin framework I am creating is meant for Server side Plugins. Technically it could be used on the client but it isn't designed to be used with Ogre3D so it would have to be changed in order to get the Scene Manager, root, ect into the plugins.

I think for client side plugins it would be easier to just use the one with Ogre since thats designed for Ogre.