Eclipse Cloud

[Minikloon]


Cloud is my C++ succession to the quondam Mirage Source edit Eclipse Evolution. Eclipse Cloud offers, amongst it's astonishing features, a plugin system that lets you customize your game and offer a true unique, tailor-made experience to your players.

**__________________________**

  
**__________________________**

**Project History**

Cloud has inherited from a quite charged back-story. The idea of a plugin-based engine first emerged in my spirit while programming the [Micro Engine](http://www.touchofdeathforums.com/smf/index.php/topic,67909.0.html). I thought about how harsh is the life for starting game developers using Eclipse Engine. The initial reason of creating an Online RPG engine was for training purpose and the sources soon became saturated because of the lack of thought putted in the design. Hence the project stopped not too long after it's creation.

Self-Quote about the Micro Engine :

> “writing up code everywhere and not be organized, get lost in my own work, struggle with the server’s code organization (Not OO, D:) and then come back to work and need to read everything I did recently to start working…. It’s crap.”

The Micro Engine was quickly replaced by the ancestor of Cloud, and you can now see by yourself how the core is coming along.
**It's still in a heavy development phase.**

**__________________________**

**Quick features :**

> - Easy to use plugin system.
> - C++ means more efficient than VB6.
> - Total control over your creation without the need of editing the sources.
> - Interchangeable client.
> - Open Source like any Eclipse (And free, as in free beer!)
> - Multi-platform, runs on Linux without trouble.

**__________________________**

**Overview**

Cloud isn't written using Visual Basic 6, mind you. This means it needs to create it's own framework to work around. Since the whole thing is based around plugins, there's not many features included directly in the initial download. An Eclipse Cloud project usually turns around three major concepts : Plugins, Configs, Content. The "Core" handles those three things by itself, for the plugins to use.

Plugins are dlls loaded using the Pluma ([http://pluma-framework.sourceforge.net/](http://pluma-framework.sourceforge.net/)) library. You simply download the plugins you wish to use (Maps, skills, characters, NPCs, pets, whatever you want!) and put them in your server and client directory. That's a blast! Configurations are XML files edited by you to, as self-explaining it may sounds, configure the plugins you use. On first startup they will spawn in the right folder for you to edit. The content is the maps setup, images, GUI and texts your specific game is using.

In the long term, the engine will try to improve the workflow of creating a game with Eclipse.

**__________________________**

**Even More Teasing**

Even better, the whole client will also be interchangeable. Eclipse Cloud's basic plugins will be bundled with a basic ‘Framework’ for a general 2D ORPG. But if someone’s arsed to create a 3D client (_That’s illusive btw, sorry!_), he could use it with Cloud.

The content is directly streamed from the server to the client when the client needs that said new content. For example, if the player joins reach a map where the biome is different and thus need another tileset, it'll download the tileset just before arriving to that new biome.

The plugins have total control over the clients. They can instruct them to show IDzed sprites with a named image resource as they want. They can also take input from the clients, obviously enough. The networking part is all abstracted away from the plugin writers.

But, I'm not gonna tell out features that I didn't design properly yet. molyneux

**__________________________**

**Notes on the engine architecture**

The engine relies on a client/server solution. It follows Object-Oriented programming paradigm. Cloud is the class that represents the main application and its logic. There are two basic threads running from the main() function, the logic thread (Cloud) and the network thread. The latter is used by the logic thread to send and receive information and is also handling connections. The version of the network layer shipped with the engine is using RakNet as a network library.

There are several other singletons, besides of Cloud and the NetworkLayer.

- The ConfigHandler is a manager class that loads XML configuration files using the RapidXML library. The plugins will be able to pick up fields from the config handler to let the end-user configure the plugins without touching to the sources.

- The PluginHandler is the manager class that loads dynamic libraries (plugins) using Pluma.

- The LogManager, well, log data into a file.

_Take note that this section is a work in progress, as the Core expands._

**__________________________**

**Download**

Everything about download can be found here : [http://www.minikloon.freemmorpgmaker.com/](http://www.minikloon.freemmorpgmaker.com/)
To download specific files, remove the !!README!!.html in the url.  :embarrassed:

[Minikloon]

**The Zap Client**

Zap is an attempt to produce a flexible client with powerful customization possibilities while keeping the simplest front-end available. It's meant to be used with any Eclipse Cloud exclusively and its parts are interchangeable, including the graphics engine and sound system.

Data is directly streamed from the server and the client is also directly instructed how to behave by the server so the plugins may be kept server-side only. This simplifies the end-user work to get its plugins up and running.

[Admiral Refuge]

So, a version of Eclipse written in C++?
waits for ~~his other half~~ Stephan to reply

[krankzinnig]

Honestly I have beat you to it, but Marsh tries to pretend like I don't exist.

http://www.deferosoft.com/forums/

[MrKris]

Hm, I have seen to many of these to get exited. I hope you can pull it off. Sounds like a good engine….In the description.  I do like the logo though! :p

[mrmiguu]

I don't know why it occurred to you that the word 'Funeral' was best suitted for this engine…

[Devogen]

@MrMiguu:

> I don't know why it occurred to you that the word 'Funeral' was best suitted for this engine…

ergh yeah terrible name for an engine.

Reading the thread title, I actually thought someone had died here at eclipse and you all went to a funeral for them.

[SawQuart]

Who died?

[Kemerd]

Keep on downloading images.jpg

[MrKris]

I think this is another one of the "Eclipse is getting shut down" things. xD

[Minikloon]

> Reading the thread title, I actually thought someone had died here at eclipse and you all went to a funeral for them.

Ouch that would've been awful. No, really, the name is pretty random, I don't really care about names. ~~You can call me Small Klondike and I'll feel cool about it.~~ :P

I will not take name suggestion tho because I don't feel like redesigning the logo/text colors…

> I think this is another one of the "Eclipse is getting shut down" things. xD

Ya and I'll buy Eclipse. [/sarcasm]

blame stosh….

[krankzinnig]

Realistically how much longer do you think you guys can milk an ancient source code in a depreciated programming language.

However, just because its C++ does not make it better. People can make horrible products in any language. Take Eclipse++ for example. Its C++, but its uses DarkGDK, so where is the improvement?

To OP, relying on tons of 3rd party libraries is not going to solve the issue that Eclipse is bloated and poorly coded.

[Minikloon]

Well, this isn't a rewrite. I will not run into Eclipse's design problems, I'm not even aware of them precisely. C++ may not be the best or worst language around, but it surely beats VB6 in every sector except simplicity. Anyway I really really don't want to argue over languages, as I fear to loose the debate.

I also only really rely on SFML, which isn't bloated at all. Think about it as an OpenGL wrapper with networking capabilities and sound, or look at the website at [http://www.sfml-dev.org/](http://www.sfml-dev.org/)
Pluma is more of a necessity, and it may be strangely designed because it uses factory design, but it's easy to get used to. Otherwise I'd need to write compiler directives to keep it multi-platform.

If you have any better idea for the dependencies I shall use, it's the right time to consider changing.

[Godlord]

Despite the engine's name, there are a lot of others things that make me feel quite disappointed. I've formed up the following post by generally reading this thread's content and by reviewing the source code provided.

First of all I'd like to state that programming an engine isn't the easiest task and that it never has been, even for someone who knows what he is doing. Therefore I generally discourage anyone from programming an engine him- or herself, instead I'd encourage them to write a few games (like tetris, pong, breakout, etc.) instead to gain some experience, and then continue with bigger projects.

@Minikloon:

> The idea of a plugin-based engine first emerged in my spirit while programming the [Micro Engine](http://www.touchofdeathforums.com/smf/index.php/topic,67909.0.html). I thought about how harsh is the life for starting game developers using Eclipse Engine. The initial reason of creating an Online RPG engine was for training purpose and the sources soon became saturated because of the lack of thought putted in the design. Hence the project stopped not too long after it's creation.

A plug-in based system is generally a bad choice, and there are various reasons for that. The first being that dynamic libraries or shared objects are slow to load and cause some serious overhead: a compiler cannot optimise applications that make heavy use of dynamic libraries. On top of that, dynamic libraries, especially when used in a plug-in based system, tend to require some memory, and even worse, might fragment it badly. The second reason is the conflicts that are caused by plug-ins. Sometimes they are really hard to resolve and might lead to frustration instead.

As for design, this wasn't a wise step to make: since you are only making it more complicated than it already is.

@Minikloon:

> Plugins are dlls loaded using the Pluma ([http://pluma-framework.sourceforge.net/](http://pluma-framework.sourceforge.net/)) library. You simply download the plugins you wish to use (Maps, skills, characters, NPCs, pets, whatever you want!) and put them in your server and client directory. That's a blast! Configurations are XML files edited by you to, as self-explaining it may sounds, configure the plugins you use. On first startup they will spawn in the right folder for you to edit. The content is the maps setup, images, GUI and texts your specific game is using.
>
> In the long term, the engine will try to improve the workflow of creating a game with Eclipse.

And it will decrease performance, as I already stated before. Not to mention that when the complicity increases, the usability of this system decreases. There are clearly no benefits when you broaden your horizon.

@Minikloon:

> - C++ means more efficient than VB6

C++ generally means more complicity, less performance if done entirely wrong, and an OO-headache. If EO were to be optimised for DOD it will certainly be faster than this C++ engine.

@Minikloon:

> “writing up code everywhere and not be organized, get lost in my own work, struggle with the server’s code organization (Not OO, D:)

Servers shouldn't use object-oriented design except for entities, perhaps. A server is usually event-driven and multi-threaded, at least the proper ones.

@Minikloon:

> The second issue is related to unmanaged handling of incoming packets. The packets are passed to all the plugins and if the plugin understand the packet, it analyzes it and does it's job with it. I don't feel like it's the good way of doing things again, because it adds more work on the plugin development side. But I don't see another way of doing it yet without adding work on the game creator side.
>
> The last issue is similar to the second. The unmanaged messages must be deleted by the plugins once they're done with it. But what if two plugins need the same kind of message? Plugins aren't executed all together but iterated by a thread in the Core, that means if two plugins need the same type of message, one will never receive it.

This is a horribly slow approach, ignoring the fact that your server is poorly written.

**Code Review**:

I've got to admit that I pretty much skimmed through the code since C++ in combination with libstdcpp, STL and OOP is quite horrible to go through, but here are some quick notes I took.

The choice of SFML_Net was a poor one, since it is a low-level socket wrapper (enet or RakNet are clearly superior if you don't want to implement the networking part yourself). The use of TCP, and more so select() frightens me: your server only supports up to 63 connections on Windows, and 1023 on Linux/Mac OS X. When using TCP you should _at least_ use IOCP, epoll and/or kqueue in combination with a thread pool. What you are using is an approach that I wouldn't even use for UDP.

Using libstdcpp is a very bad choice. When designing the STL, they should only have supported certain trees like AVL-trees and red-black trees, not lists, vectors and whatever else you have. It isn't hard to implement the data types yourself, and you would usually benefit from the performance gain. Even worse is the use of std::string (there are many alternative classes that are faster, and dealing with string management yourself like done in C is going to be faster than any of those classes when done properly).

Your way of parsing the message pool's strings is something that troubles me as well. Your handler only seems to remove messages that are prefixed with '@E' and '@S', unless your add system never adds anything else.

@Minikloon:

> Well, this isn't a rewrite. I will not run into Eclipse's design problems, I'm not even aware of them precisely.

You are running into _entirely different_ design problems, factors worse than those Eclipse ever had.

@Minikloon:

> C++ may not be the best or worst language around, but it surely beats VB6 in every sector except simplicity.

C would, but C++ at the other hand might actually fail at it, depending on how poorly it is written.

@Minikloon:

> I also only really rely on SFML, which isn't bloated at all. Think about it as an OpenGL wrapper with networking capabilities and sound, or look at the website at [http://www.sfml-dev.org/](http://www.sfml-dev.org/)
>
> Pluma is more of a necessity, and it may be strangely designed because it uses factory design, but it's easy to get used to. Otherwise I'd need to write compiler directives to keep it multi-platform.

I actually prefer SDL over SFML for various reasons. SFML is merely a simple wrapper, SDL goes a few steps farther at most things. As for networking however, they are both equally horrible.

@Minikloon:

> If you have any better idea for the dependencies I shall use, it's the right time to consider changing.

I'm writing my own, for the simple reason there is nothing out there that actually fits within my requirements. The best out of all, in my opinion, is SDL however (unless you want to use WinAPI, X11, etc. directly). Except for the networking and the audio, where I'd personally use enet or RakNet, and OpenAL respectively.

As a conclusion I'd like to state that this engine needs a better design, and a lot of improvements in general.

Regards,
  Stephan.

[Minikloon]

Honestly I was starting to type a long counter-attack (Expression) message, but in the middle of things I suddenly felt like if it was useless to defend my point.

Let's just wait to see the thing in action before arguing infinitely over things I don't even have arguments against.

**Just two things.**

> Your way of parsing the message pool's strings is something that troubles me as well. Your handler only seems to remove messages that are prefixed with '@E' and '@S', unless your add system never adds anything else.

Hence the first issue I stated. The plugins are doing the work of cleaning up other message types. I'll also see if it removes unused messages yet and if it doesn't, I'll write something to take care of them. That's one buffer overflow exploit less.

> I actually prefer SDL over SFML for various reasons. SFML is merely a simple wrapper, SDL goes a few steps farther at most things. As for networking however, they are both equally horrible.

I think SFML is better for client programming, because it doesn't use a slow software renderer. Also, everything is easier with SFML.

So we both get the same conclusion :

> I'd like to state that this engine needs a better design, and a lot of improvements in general.

That's why I'm still developing it.

* * *

_Meanwhile, in Canada…_
[http://www.gamedev.net/topic/603580-so-you-want-to-be-a-real-programmer/](http://www.gamedev.net/topic/603580-so-you-want-to-be-a-real-programmer/)

[Godlord]

@Minikloon:

> Honestly, let's just wait to see the thing in action before arguing infinitely over things I don't even have arguments against.

Being a programmer who optimises a lot of code, I have to be able to predict what code does, and how long it takes to do something. Knowing my own code that for instance loads DirectX DLLs and what have you, it can take quite a while to load them. As for anything else, you can actually read why the plug-in system is deemed to be slow and horrible, especially on actual server systems where memory fragmentation and cache misses are your worst enemy.

@Minikloon:

> I think SFML is better for client programming, because it doesn't use a slow software renderer. Also, everything is easier with SFML.

The Quake ports that use SDL don't use the slow software renderer either, they use OpenGL. The new version of SDL supports new renderers (Direct3D9 and OpenGL) that are way faster. The reason why it was so slow is because it used self-written blitters, which tend to be slow (even though they are heavily optimised). Nevertheless they are useful for converting between pixel formats, which is why SDL still uses them.

@Minikloon:

> So we both get the same conclusion :
> That's why I'm still developing it.

I wouldn't have posted this thread if I were to be you, for the simple reason that when I release something, I want to be sure it is entirely finished and therefore ready for announcement or at least in a state where it is fundamentally stable.

@Minikloon:

> _Meanwhile, in Canada…_
> [http://www.gamedev.net/topic/603580-so-you-want-to-be-a-real-programmer/](http://www.gamedev.net/topic/603580-so-you-want-to-be-a-real-programmer/)

It's true that one should use the right tool for the right job: and for a server that needs to be heavily optimised, prevent memory fragmentation and a bunch of cache misses, one of the best tools would be C, perhaps with a thin flavour of Assembly.

The argument that it takes extremely long to programme in a language like C is however inaccurate. It took me four to six hours to programme a basic EO-like server in C using my own library. The problem with C is the lack of good libraries, programming approaches and philosophy, and perhaps programmers who actually know how to programme with the language.

Regards,
  Stephan.

[krankzinnig]

Stephan is very intelligent, he is not insulting you. The fact he took the time to give you THIS much crtisim is very nice of him. Honestly you over complicating this whole project. Novus, our engine, uses no dynamic libraries and uses OpenGL. You should join the effort of improving this technology rather then doing it yourself and failing. Message me on my fourms and I would be happy to point you in the right direction.

[Devogen]

@Minikloon:

> Ouch that would've been awful. No, really, the name is pretty random, I don't really care about names. ~~You can call me Small Klondike and I'll feel cool about it.~~ :P
>
> I will not take name suggestion tho because I don't feel like redesigning the logo/text colors…
> Ya and I'll buy Eclipse. [/sarcasm]
>
> blame stosh….

Well, I wont comment on the programming side, I think Stephan has pretty much everyone trumped in that regard, but if are keeping the engine name because "you dont feel like redesigning the logo colours" then you are a lazy fart.

The icon you got in 5 seconds for free off iconfinder and the rest is simple black text, if you are too lazy to re-do that, then what are we to expect from the rest of your project?

I would'nt be too inclined to use an engine the developer has a carefactor of 0 for.

[krankzinnig]

Blah, posts like yours Devo is what makes this community and most other insufferable. Perhaps he just likes the name and who fucking cares? I personally didn't think twice about the title, just curious as to why he is choosing to go the route he did. I think Devogen sounds just as bland in my opinion, but that doesn't make anything you do low quality, looks on the contrary, never would have guessed from the name. But point being, doesn't matter what its called.

Think of "World of Warcraft", that name makes me want to punch things because of how tacky it sounds. BUT, its more popular then anything any of us will ever make.

You should post on the areas that matter, and leave the name alone.

[mrmiguu]

@krankzinnig:

> Think of "World of Warcraft", that name makes me want to punch things because of how tacky it sounds. BUT, its more popular then anything any of us will ever make.

Don't forget 'Maple Story'. That name is so wack.

Now, it should be noted that an excellent engine will be built from one who pays attention to the little details. If he is too lazy to make a new logo, maybe that says something about the little details in his engine as well.

[Devogen]

@krankzinnig:

> Blah, posts like yours Devo is what makes this community and most other insufferable. Perhaps he just likes the name and who ducking cares? I personally didn't think twice about the title, just curious as to why he is choosing to go the route he did. I think Devogen sounds just as bland in my opinion, but that doesn't make anything you do low quality, looks on the contrary, never would have guessed from the name. But point being, doesn't matter what its called.
>
> Think of "World of Warcraft", that name makes me want to punch things because of how tacky it sounds. BUT, its more popular then anything any of us will ever make.
>
> You should post on the areas that matter, and leave the name alone.

Well, you are entitled to your opinion as much as I,  and I take comments like yours with a grain of salt.

Names **are** important, they are what people remember. Your forum handle for instance, very unmemorable, in fact even typing it is a pain. Mine, well mine was a combination of words and wasnt really that important, as its a business name that can basically have as many sub's trading under it under any name I wish, as long as they are registered to the parent company as a trading entity.

World of Warcraft obviously was a great choice for a name, sales figures prove it. Its abbreviated to WoW.. i mean, the word Wow used to mean something was astonishing, now it is a global reference to a video game. Starting to sink in now? I hope so.

We are talking about coverage, not whether something is a 'good' name or not. I was merely implying that the name Eclipse Funeral isnt particularly attractive for any software, let alone a game engine. The word funeral is synonymous with death, and basically things that dont live or work anymore, but hey it's his engine if he loves it, then isnt that what matters? and opinions like mine shouldnt even be considered? any good developer will look at comments and criticism, but rarely will they make major changes based on the opinions of a general few, if he did then that would just be smart on his part (in this instance)

@MrMiguu:

> Now, it should be noted that an excellent engine will be built from one who pays attention to the little details. If he is too lazy to make a new logo, maybe that says something about the little details in his engine as well.

Thats pretty much the gist of what I was saying, it doesnt hold hope for the future of it if he can't be bothered with small things like that.

[Bloodmorphed]

OKay for one the argument on this name thing is pretty stupid.

Perhaps he doesnt want to change the name of the server or re-do a "logo" because he wants to spend all his time coding?

I do agree though the name wasn't really thought out well. But why argue over it? Its his engine, granted people have opinions but an argument over a simple opinion as this doesn't change anything.

Thats being said, goodbye and goodmorning :)

[Robin]

@Bloodmorphed:

> -snip-

Because if a person is serious about a project then they actually put time in to _all_ aspects of it. If you don't care about the name of your project then chances are you're not going to finish it.

It's very consistent between all the other failed engines and re-writes we see here.

[Minikloon]

I didn't know that things I suspected to be details of the presentation would cause such a polemic. I'm sorry if I, well, offended or surprised anyone with such a name.

I renamed the thing to Eclipse Cloud, more representative of the plugin features with the current emergence of distributed virtual hosts and such.
I also went with a more colorful design.

I'll be getting a new version out of Cloud Core (v0.3) with the content and configurations features. I'll also look into Stephen's comments in regard of the maximum number of connections Windows can handle using TCP and selector using an old plugin I wrote to simulate the Micro Engine (Added to the thread for download).

[Helpmeplz]

Well it is a presentation what did you expect. :p Now doesn't that name sound way better.