QuickStart Engine

Guys,

I want to start a new open-source project, of an MORPG framework (=client+server+database application kit) based on QuickStart Engine to help people building multiplayer online role playing games for XNA.

Is it a good idea ?
Any name suggestion ? I was thinking of quickrun , quickrpg, quickstartrpg...

Thanks all

At such an early stage of engine development, it's practically impossible to say how well an MORPG system would fit over QuickStart.

Well for us, QS would be used just for the rendering layer on client side.
The rpg framework would be a library for the server and one for the client side. Both would contain core components , particularly a command processor , which would translate commands received from the server or from the client into calls to different manager's functions (session manager, chat manager, character manager, combat manager, etc).

As most of the gameplay code would run on server, and the client application would only act as a view (+ sometimes controller) and would send commands (messages) to the server-side models (business entities). Server would respond and client would update its rendering.

Using this approach, we perfectly can design and implement a client-server framework now and integrate it with QS later. We can use a basic 2D app as mock client app, keeping a light interface in our library to be able to fit it easily to QS.

What do you think ?

Before the move from Codeplex, I was using the QSE to hack together a client for an FPS MMO. The project has been postponed indefinately since I was almost the only one submitting code, and I'm now doing a 2 year post grad degree, however, I do have a couple of insights which might help you out.

This is the first time I've looked at QSE since around xmas, so forgive me if i'm not up to date on any recent changes.

From what I was working on, the graphical side is suitable for an MMO, no questions really, and the modularisation of the component stuff is also very suitable.

The main problem I forsaw was that all the work on physics will be completely different from what an MMO needs.

MMOs need determinate physics on both client and server. They both process the physics, but at different speeds. Client does it every frame so the players move smoothly, server calculates depending on latency/bandwidth, and forces non compliant clients to readjust to be inline with the server if they get out of synch. If you just calculate physics on the server, the game can't run at 30fps. If you let the client run it's own physics you open the door to serious synch issues and exploits. The fact you have to run both, and couple them means you effectively will need to completely re-write all the physics in the QSE.

One of the other (but more minor) problems with the networking is that the component system creates problems associating various entities with networking. The networking doesn't have direct access to the entities, so you end up passing multiple messages through layers to reach the right places. This in itself isn't a problem, but could end up slowing things down and increasing complexity. You can overcome this, but you ideally don't want to be modifying any code in the QSE itself, as whenever a new patch is released things end up being broken (This goes for the physics integration too).

For what I was doing, it was great...I was only using it as a way to test out my server code, so hacking bits into QSE wasn't going to be a long term problem.

Ultimately tho, an MMO framwork is going to live and die based on its netcode, not its graphics engine. This is why we intended to ultimately write our own client...it would have been far easier for us to build graphics code ontop of MMO netcode than it would be to build MMO netcode ontop of a graphics engine. Very likely one of the main reasons commercial MMOs don't tend to use middleware is because of the proprietry nature of the underlying netcode, and the difficulties integrating with it.

I can't say wheter QSE will be worth building on for your project, and I'm not up to date with any of the networking or physics work which may have happened in the past 4 months. It looks like you have come to almost the same conclusions I had when you say it will be 'just for the rendering layer'. You need to evaluate how long it will take to write a new rendering layer, compared to how long it will take to integrate an existing one with your work.

Good point... I'll think about it...
Meanwhile, the project is open to discussion on
http://jukumu.freeforums.org

why name JuKuMu?

Well I am interested in such a project.
Especially since I have my own implementation of a MORPG server(+DB layer (MS SQL Server or SQL Express) + lidgren library for networking) and its time to write the 2nd reincarnation from scratch.
My client used the Irrlicht .NET wrapper and the build in Irrlichts Collision system (just simple gravity + collision detection + camera collision. Nothing fancy but more than enough for a RPG).
And yes repositioning the client controlled characters was a @#$! but if the engine allows repositioning of models at will (render and physics entities) this is not a big deal.


BTW this thread is rather old, anyone still here?

I've made a fix for physics entities not allowing position changes. Hopefully I'll get that posted soon. In fact I may get it up on the codeplex site before sourceforge.