Requirements for openeq

[jbb]

When I was working on my own renderer I stared to figure out the formal requirements for a mmorpg client like this.

I only got as far as writing down a list of needs in an unstructured form. It's just a list of things that the client would need to do, and in no way a requirements document, but it *is* the information that would be needed for a proper set of requirements.

I think that openeq needs some requirements documenting to give it some focus and to define the scope of exactly what work needs to be done so I'll contribute this list as a possible starting point.

I've edited it a bit to make it more relevent to openeq than to my own renderer and it's in rtf format as produced by ms wordpad but hopefull it will be of some use.

If I can get some feedback on what's good and bad about this list of needs and what's missing I'll then work on a proper set of requirements.

Even if nobody pays any attention to it and just gets on with coding I think it's useful as a summary of what work needs to be done (and to show just how many things there are!)

It's here http://www.fx2100.com/doc1.rtf

[MOG]

I like the summary. Maybe you could break it down into phases or tasks so people could help program different parts.
My one complaint: "It must be capable of rendering using opengl and directx9 on all platforms where they are supported." Why?
There is no advantage to doing this. It will duplicate the effort of creating a renderer. As far as I myself can see, only OpenGL and SDL should even be considered.

Also, it might be easy to convert EQemu's server networking code to client.
If you are thinking of doing "Your own renderer", consider using Ogre.


MOG

[daeken_bb]

This is a fantastic idea, and a good start.

I think what I'd like to do is set up a wiki at our domain (openeq.org) and start a functionality list there. If neccesary, we can lock it to everyone but developers (we'd allow anyone to get an account as long as they show they're decently responsible (e.g. don't have a bad record on the forums here)) but hopefully we wouldn't have any problems.

I think what we need to do is split up the list by group (e.g. is it networking, UI, renderer, file loader, etc) and then by priority.

On the wiki, each element of the list should have a page of its own discussing what it is, why we need it (this should only be neccesary for certain things, as I don't think we need to discuss why we need a 3d engine or file loaders ;) ), what is neccesary to complete it, which part of the codebase it's in, and what steps have been taken towards completing it.

If done properly, this will greatly help development.

[jbb]

There is no advantage to doing this. It will duplicate the effort of creating a renderer. As far as I myself can see, only OpenGL and SDL should even be considered.
Remember this was based on the things I wanted for my own project and extended a bit to make it relevent to openeq.

One valid reason is that on windows machines direct3d support tends to be of a significantly better better quality that opengl support particularly with certain types of graphics card. Potential users are much more likely to have a working direct3d9 on their system than a working opengl without having to update their drivers.

Besides, it's not hard to have an abstract rendering interface tomake it possible even if only opengl is ever implemented.

[jbb]

I need to stress that this was only a list of perceived needs for the system. Anything can go in there at any level and may well be rejected or postponed as a requirement for any particulal version of the "product". It's just to help think about that it should do.

I'll write some more about how this should be turned into a proper list of features and possibly use cases - and why it 's a good idea to do so later on.

Ugh, I'm turning this into a clone of my day job except on a more interesting product :) But I think some planning of what the requirements actually are is probably even more important in a project likt this that a commercial project as it's considerably more easy to lose sight of your goals in a project like this and get sidetracked on something that seems interesting while fogretting the things that are needed to make a sucessfull "product"

[jbb]

Also, it might be easy to convert EQemu's server networking code to client.
If you are thinking of doing "Your own renderer", consider using Ogre.

I think the server's network code may or may not be relevent. It's trying to solve a different problem where it has to support many connections. We only have to support one. I have my own thoughts on the subject.

Personally I would have used Ogre too. It does everything we'd need and I personally think that it's is an outstanding example of how to write and design good object oriented c++ code.
But also writting the renderer is half the fun of the project, and nobody is going to work on a free project that isn't fun. Also Daeken has written all the code so far and he didn't want to use Ogre so what can you do :)

Oh, and yes a wiki is a great idea. Do you have the resources to set one up, or do you want me to do one?

[daeken_bb]

Oh, and yes a wiki is a great idea. Do you have the resources to set one up, or do you want me to do one?

I should be able to manage it, but I may have to ask you to. Depends on whether my friend ASleep's server is still having space issues ;)

[MOG]

Why not set it up at sourceforge? DOLServer has a good wiki there, you could get one like it.




MOG

[daeken_bb]

Why not set it up at sourceforge? DOLServer has a good wiki there, you could get one like it.




MOG

Sourceforge is slow, unstable, and you can't use mod_rewrite on it. The binaryphp wiki is hosted there and we have had many problems with it.

I talked with ASleep, and the replacement for Linda (the current server) will be up after Christmas. Dual 2.4Ghz Xeon, 2GB ram, 500GB space (SATA) :)
Not only will the wiki be on it, but we'll be doing our cross-compiles on it :D