Other Software?
  • I've checked out some of the cool stuff WorldForge has - Ember, Cyphesis - and I'm impressed. I'm curious, though, why WorldForge has written its own software instead of using other projects that are out there. I guess there are reasons for this, so if anyone can explain things, I'd appreciate it.

    I'm thinking about, for example, the Nevrax library (currently handled by OpenNeL), which is a base platform for MMORPGs. In theory WorldForge could have built on top of this.

    Other - more recent - developments are the open-sourcing of the Second Life client, and the RealXtend vliewer built from it, and the related OpenSim server.

    On a more specific note, I see that Ember uses Ogre3D. I'm curious however why it doesn't build upon a more complete game engine rather than just a 3D rendering system like Ogre3D. For example, the Nebula Project.

    Are most of these projects not used because they are too new? If so, are there any plans for WorldForge to adopt/collaborate/etc. any of these technologies? I'm also curious, aside from this specific question, what WorldForge people think about these other projects, where WorldForge stands in relation to them, etc.
  • Hi, as you correctly guess many of these technologies are quite new and weren't around when Worldforge started.
    This applies to Nevrax and SL for example.

    Ragarding Ember: Ogre is as you say only a 3d engine, and not a game engine, in contrast to the Nebula Project or Crystalspace. The reason we use Ogre is mainly that the "game" part is already handled by many of the other libraries within the Worldforge stack, such as Eris and Mercator. The actual game world is then handled by the cyphesis server which is completely detached from any client technology. While it would be possible to use a more complete game engine in place of Ogre, a lot of the functionality in it would either never have been used, or would have to be greatly modified to fit the Worldforge game world.

    Worldforge is characterized by the great disconnection between the server and the clients. We have a lot of different clients, some just command line (cycmd), some 2d (Silence) and some 3d (Ember, Sear). All of these can connect and interact with the same world. The main reason for this is the Atlas protocol, and how it's not attached to any specific server and client type. It's very much like html where you also have many types of clients connecting to many types of servers.
    Any of the large game frameworks with network support are however more tightly bound in their server and client setup (the Nebula Project client connects to the Nebula Project server and so on). So if we were to use any of those we would need to remove all of the networking and server interaction code and replace it with stuff that talks Atlas. And then much of the benefits from using a complete game engine in the first place evaporates.

    It should be noted also that Worldforge is quite modular and all of our libraries and protocols are built in such ways that they easily can be used by other projects. So if any other project would use part of the Worldforge infrastructure we will only welcome it. One of our stated goals is to provide the building blocks and tools for letting people create worlds, and if they can do that by only using parts of the Worldforge stack we would encourage it.
    One thing that I've seen some people having issues with is however that our libraries are licensed under GPL in contrast to LGPL. While I don't see a problem with that, if your project is GPL it's GPL all the way through anyway, I can understand if other people are more wary.
  • Thanks for the detailed response. Makes sense.

    I'm working in a project that will need, as part of it, a client not much unlike Ember. So there is a chance we'll utilize Ember, which would of course mean that our client will be GPLed, which I personally welcome (I'm a dedicated Linux person myself). However, others in the project are less enthused by the GPL, and lean towards other solutions so I'm not sure what we'll end up doing.

    I'll be evaluating Ember more closely, as I think it's the most promising basis on which to build our client. It appears to run better and have nicer-written code than e.g. the RealXtend client, and aside from that one all the other alternatives are basically to take a game engine and write a client 'from scratch' - which, even with the best of engines, would presumably not be a trivial task (as you probably know much better than me).
  • Thanks for the kind words. Ember has always been designed with the kind of situation you describe in mind: where it would be used as a basis for another client/world.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID