Rise of Heroes MMORPGRTS

[jacmoe]

Hjortsbergs blog - a must read for all things Ember:
http://erikhjortsberg.blogspot.com/

[James Proctor]

Last I knew Worldforge had no Windows Server which I need to be able to have until we get to a point in development that we can afford a dedicated server. 2nd nothing against Worldforge but I really don't think the graphics are yet up to the standard that Nel's graphics are. Also I love the idea that Nel is a proven engine when it comes to Large scale MMOs. 250 entities can all be updated at one time allowing for very large scale combat and since RoH has a focus on GvG (Guild vs Guild) Combat I feel that is an important feature to have. All around I feel this move is the best one for the future of RoH.

[jacmoe]

Last time I checked Java was able to run on any OS..
And graphics wise: Ogre.

But, all in all: a very good move.
You are going to not regret it.

<edit>
Windows server?
Crap. Just crap. Run a decent OS for your server..
</edit>

[DanielSefton]

what I really want to do is be building a game.

Then don't try to write an MMORPG.

I learned that fact, and I'm now writing a very basic single player game.

And the best thing is: I'm going to finish it.

[James Proctor]

lol The server once we get into the beta test phase will be on a Linux server however for development I am hosting the server on my Home PC. The "Ryzom Core" Server design is very flexable to the point that some of the servers could be hosted on linux while the others were hosted on a windows server if you wanted to. The Full server for each shard is made up of 15 different types of Servers. Some of the types you have 1 per shard others like the AI Server you can have as many as you want per shard each hosting a different amount of the mobs.

Ryzom Core Features¶
Graphical User Interface¶

The GUI system allows for easy creation of user interfaces using an xml based format for layout, and features support for all the common interface controls, as well as scripting through Lua script.
Fully skinnable graphics¶

It is possible to customize the graphical look and feel of the user interface. The interface controls adapt to the size of the graphics. Textures are packed together, using the interface build tool, in a large sprite sheet, which minimizes draw calls, resulting in high performance.
Unicode font rendering¶

In order to allow for localized versions of the game in languages with varying character sets, Unicode fonts can be used. Text characters are rendered on demand in the font manager's character cache, so it is not required to build font sprite maps in advance, and your dialogue writers do not need to worry about missing characters. This also makes it possible to use any character in a font at any font size.
Resizable windows and other common controls¶

Interfaces can be created inside resizable and movable windows with a titlebar, which can also minimize the window to show only the titlebar. Transparency effects can be used to bring specific windows into focus or out of focus into the background.
All the common interface controls, such as buttons, labels, text boxes, combo boxes, checkboxes, and so on, are available.
Specialized interfaces¶

A flexible general purpuse web browser component is available, which can be used for easily making more dynamic interfaces such as forums and help pages available ingame. The web browser allows you to use most basic html tags, including images, as well as to invoke client side Lua scripts.
The interface also includes a small music player, with support for common audio formats and playlists, allows the user to play his own music in the background.
Scripting¶

All actions in the user interface can be bound to client commands and Lua scripts, through action handlers, which can be specified in the client code. Content displayed in the user interface can be dynamically linked to the client's network variable database using conditional expressions.
Dynamically reassignable keyboard shortcuts¶

Keyboard shortcuts can by dynamically assigned to the action handlers.
Networking¶

Ryzom offers a higly optimized and proven cloud-based networking architecture.
Server cloud¶

Multiple physical machines can be used together to run a single shard, spread over multiple services. Read more on the service architecture here.
Server client communication¶

The connection between client and server runs over a bit-packed, bandwidth limited, fixed time rate UDP connection, with full support for packet loss management.
Efficient large scale entity propagation¶

Up to 255 entities are propagated over the network connection in realtime under dial-up bandwidth constraints. This allows for large scale events, such as invasions and guild versus guild fights.
Shared data between server and client¶

Variable data is easily shared between the server and a client, through a tree structured network variable database, that is specified through an XML file. Entries in the database can have conditional expressions attached to them, that allow Lua scripts to be called when one or multiple variables are updated to a specific or any state. It is also possible to link these variables directly into the user interface. The entity properties are also accessible through this database.
Cached server strings¶

Static text strings are assigned a unique integer identifier, which can be used in the network communication to efficiently reference a string. The client can asynchronously request a string from the server to be displayed in the user interface as soon as the client receives this string. The database uses these identifiers wherever strings, such as player names, need to be sent to the client.
Event messages¶

All direct event messages between server and client are specified in an XML file, and sent over the network using a unique id of minimal size. The version of this message structure file is verified upon connection of a client to the server, so that a client with a different version cannot connect. Messages that are lost over the UDP connection, are automatically resent. Large messages are automatically split up into multiple messages, which are spread over multiple packets, to stay within the bandwidth constraints.
Client updates¶

TODO files verified, etc
Patch deltas¶

TODO lzma compressed, deltas, etc
Sound¶
Graphical debugging¶

The sound system can be graphically debugged from ingame, which allows you to see all the source voices which are currently playing, as well as the bounding boxes of environments, and portals for occlusion and obstruction effects.

and here is some more info about the server types:


Service Architecture¶
Terminology¶

* Server: We often use this word to refer to physical server.
* Shard: This is an instance of the Ryzom universe. Currently, we have 3 shards, one for the French community, one for the German one and the last one for people who speak English. All shards are independent and there's almost no link between shards.
* Service: A service is an executable, that is running on Servers. For example, we have a service that manage the AI. We can create heterogeneous shards with some Windows server and GNU/Linux server where some service will run on the Windows and other on the GNU/Linux.

The architecture is completely modular. In 2004, a Ryzom shard ran on 8 servers and now with the power of new computer we can run the same shard on a unique server.
Ryzom Services¶

Here is a list of what the services do in Ryzom:

* AES (Admin Executor Service) : There's one AES per physical server. It manages the shard by launching other services on the server, kill them, get some information about the services.
* AS (Admin Service) : There's one AS that coordinate all AES. It's the central point to get/send command to AES.
* AIS (AI Service) : We can have one or more AIS per shard. The goal of this service is to handle the AI in Ryzom. An AIS is responsible for a geographic area. For example, in Ryzom, we have 6 AIS, one per continent.
* BMS (Backup Manager Service) : There's 2 BMS (a master and a slave) for all the shards. They manage the saving/loading of data like player characters, guilds... Data are saved in the hard disk using specific file format.
* EGS (Entities Game Service) : One per shard. It manages all players state, game play rules, missions, items, guilds, ... It's a central point service.
* GPMS (Global Position Manager Service) : One per shard. It knows where all entities (players, ai) are and check collision.
* IOS (Input Output Service) : One per shard. Manage all chats, texts, localizations...
* NS (Naming Service) : One per shard. It's a low level service that coordinate all other services. It knows which services are launched, on which port, it's like a yellow page.
* WS (Welcome Service) : One per shard. Used in the login process, this service check and route the player to the good FES.
* TS (Tick Service) : One per shard. A simple service that manage the game time and sync all services.
* MS (Mirror Service) : One per server. A service that use shared memory and communication to sync data across servers so all services can access quickly to all necessary information.
* SU (Shard Unifier Service) : One. Manage the things that are not related to a specific shard. For example, teleporting a player from a shard to another shard. Also manage the login of players.
* FES (Front End Service) : One or more per shard. It's the interface with the Ryzom client. It handles the messages and route them to the necessary service. If you have 2 FES on a shard, clients connection will be spread equally on both service.
* SBS (Session Browser Service) : Same number as FES. It manages sessions (mainly used by the Ring).
* PDSS (Persistent Data Service) : Create some archive to backup regularly the stored files that contains player character information and also be able to extract some information to do some stats or tests.

[jacmoe]

No one has muttered one word about NEL/Ryzom being bad. To the contrary.

(Good copy and paste skills, James. )

[James Proctor]

lol I know no one said it was bad just saying what it's features are! lol One other thing it's GUI System is CEGUI!

[wilson77]

Wow. There is a huge difference in your screenies between the original Ogre rendered ones and the new MMO Engine renderd ones isnt there ?

The new ones are looking really really nice. It really is quite obvious how much the new engine is going to help with your project from those shots(once you get some custom media in there). Of course you still have a long way to go and alot of work to do, but at least now, as you say, you can concentrate on building the game rather than the engine. I have to say I think you have made a good choice aswell, building the engine from scratch in code isnt something that you really wanted to do, and using a ready-made engine takes that entire process away. At most, you will be modifying the existing Ryzom source to do what you want, which is alot easier than writing something from scratch to do what you want.

Good Luck, I'm quite interested in seeing where this project heads.

[Azgur]

Wow. There is a huge difference in your screenies between the original Ogre rendered ones and the new MMO Engine renderd ones isnt there ?

Not to rain on anyone's parade.. but those screenshots are the example area and assets that come with the ryzom source.
It looks like that out of the box.
We have no idea yet how it will look when James puts in his own assets and effects.

[wilson77]

I realise the assets in the screenies are from the Ryzom asset repo, which is why I mentioned in the next line of my post in brackets about getting custom media in there.

My comment wasnt to do with actual assets and how they look, but more in noticing the differences between the original engine(using ogre to render and unfinished) and the Ryzom engine(custom dx10 rendering and alot more complete). I will definately be interested to see some custom media in there, as that will be the real teller to what the look of the project is going to be in the end. But, you can really notice the difference in the new renderer from the old one. Its just a shame, in my opinion anyway, that the new choice isnt Ogre based - yet .

[Jabberwocky]

But, you can really notice the difference in the new renderer from the old one.

I'd say the difference is 100% due to the artwork, and not the renderer. If you're seeing something I'm not (like any kind of DirectX 10 specific functionality going on), feel free to point it out.

[DanielSefton]

But, you can really notice the difference in the new renderer from the old one.

I'd say the difference is 100% due to the artwork, and not the renderer. If you're seeing something I'm not (like any kind of DirectX 10 specific functionality going on), feel free to point it out.

I agree with that -- all it is is some fog, a skybox and some low polygon textures, models and particles. If that art was used in Ogre, it would look the same if not better.

Lets compare:

Nel:

Ogre:

Nel:

Ogre:

Ogre:


And I don't even have any real art

[Azatoth]

Since it's the Worldforge media which was used in his previous attempt, and to which the Ryzom art is being compared I feel that I have to say something.
(And also since he himself says "nothing against Worldforge but I really don't think the graphics are yet up to the standard that Nel's graphics are".)

Worldforge provides high poly models and high resolution textures. Most of our textures are at least 1024x1024px format(some are in 2048x2048px). Most of the Ryzom textures are of 256x256 size, with only a few in 1024x1024 format (a breakdown). For most of our materials we also provide diffuse, specular and normal maps. For some meshes we also provide ambient occlusion maps.
In addition, we provide source files for all of our assets, both textures and meshes. Ryzom only provides end result png textures.
We also provide multiple shaders which uses these textures, arranged with schemes which allow on-the-fly switching between different feature sets (as shown in this video).

All of this is provided as FOSS. It can be browsed using our Wombat tool and downloaded using Subversion.

The inability of James to use this huge repository to present something good looking has more to do with his engine and his placement of assets (mainly the latter), rather than any deficiencies in either Ogre or the Worldforge art.
Some slightly better use of the material can be found at the Ember photo stream.

[a_releg]

while i agree about the art and graphics, if NEL framework works for him in the server sense, then it is still a good choice. A lot of the barriers in making mmo's is in the networking and scaling side.
James, in the end, it is your project, whether you decide to use ogre or not. If it makes it smoother to use Nel, then it is a good choice and you did a lot of thinking before you came to this conclusion and stick with your guns.
All of us here are ogre fans, but it is not our project. Good luck to you and hope to see your game out there along with the rest of us here in ogre land.

[Rhynedahll]

I am sorry to have to let you guys know that we are no longer using Ogre3D at least for now.

Have you considered the possibility of releasing your Ogre3d project as open source?

If its functionality is far enough along, it might assist others working toward the same goals.

[janpec]

I dont think that Ogre graphic is actually better than Ryzoms. But that is just my opinion.

[Kyle_Katarn]

I dont think that Ogre graphic is actually better than Ryzoms. But that is just my opinion.

It's really up to the developer for that. From all of the quality projects I see here, Ogre can have some damn fine graphics, and really nice effects. Ogre doesn't define the graphical quality, the graphics artist does.

[James Proctor]

Well We are back. After talking it over with our Lead Programmer we have decided that Ryzom Core just isn't ready to be used in another game. We now have a team of 4 programmers and we will be working on creating Rise of Heroes using the Player Demo as oarting point. I deleted the old engine so this will be a complete rewrite starting with just the code from the Player Demo.

[jacmoe]

Worldforge?
Using the Ember client?

It is powered by Ogre, you know..
I'd hate to see you reinvent wheels you don't have to.
I already gave you links to it.

[James Proctor]

Like I have said before I would use WorldForge but the only server they have is for Linux. I need a Windows Server for right now where I am hosting the server on my PC. Also we are going to be designing it for our specific needs instead of as a general MMO Framework. Some Code will be able to be reused later on in other games but for the most part its being designed specifically for Rise of Heroes.

[jacmoe]

Cyphesis could probably be compiled on Windows..

But ..

So, there are no server for Windows?
Gendalfas

Re: Need help with install
by alriddoch on Saturday 25th of April, 2009 9:22 am

No.
alriddoch

Re: Need help with install
by Gendalfas on Saturday 25th of April, 2009 9:37 am

Will we see Windows Xp version soon?
What should Win users do?
Gendalfas

Re: Need help with install
by alriddoch on Saturday 25th of April, 2009 7:34 pm

"Win user" is not a race or religion. Anyone can run Linux for free on a spare machine or using free virtual machine software. We target Linux because it is much easier to write powerful, scalable software for Linux than for windows, and Windows development is more expensive.

WTF?
That's spelling out Lazy Linux Zealot to me.
How hard can it be to make cross platform libraries and tools?

But, what's wrong with running a Linux server, James ?
Almost all serious servers are in fact running on some kind of *nix.

[James Proctor]

If I had a Spare Computer I could use to host the server then it wouldn't be hard but right now I only have my main computer which is running Windows Vista.

[jacmoe]

WMware or similar to the rescue.
VirtualBox is nice, but so is CoLinux -> http://www.colinux.org/
If you only want to try it out.
Since it's a server, it's very easy to run it from a Windows desktop (because you don't need any X server).
Cyphesis does build on Windows, but it's performance is bad compared to when it's running on Linux.

I promise not to bug you again about Worldforge - but it would indeed be a shame if you didn't try it out.

<edit>
Yes, you can run a server in CoLinux and connect to it from Windows as if CoLinux was another machine:

a virtual network was implemented between the Linux and the Windows that runs it. If you run a MySQL database on the Linux, there's no problem accessing it via TCP/IP from the Windows. From the host's standpoint, coLinux is just another computer on the network.

Alright, I'll stop!