Anything?

[Cisyouc]

8 buttons (a la EQ's memmed spells bar)

Pardon?
I believe thats 9 now.

[Windcatcher]

As a practical matter I think the only way this could proceed in reasonable amount of time would be to start (and I stress start) with something that was an EQ client clone and then could grow to something more generic. The constraint is really the server, not the client: writing a client would be a something of a bit-by-bit, trial-and-error process: code a little functionality, test it on the server, fix it, try again, and then move on to the next bit. Rinse and repeat. At this time the only server that exists where the code is available for testing is EQEmu itself.

To grow beyond EQEmu, the server needs to send packets that communicate information about the game system itself: what kinds of abilities do players have: are there levels, or are there skills? If so, what are they? If there are deities or starting towns, what are they? If players have spells, how many can they memorize? Are there spell categories? I'm sure there is a lot more to be sent, but this is the type of game system information that would let a client/server combination (and make no mistake they have to be in sync) grow to something beyond EQ.

I also think OpenEQ bit off too much at the start. I think a more practical approach would be to write a client that is fixed to a particular server rev, and then fork that rev. Then people could begin the business of growing cilent and server beyond the scope of the EQ game system (i.e. making them more generic). It would be something of an iterative process.

I don't like the idea of using SOE's content, but barring a massive effort to create content I don't see any other way than gradually migrating away. We can create our own zones with OpenZone (and I'd still like to see a zone repository somewhere), and I've been delving into the item fragments to see if OpenZone can be improved so we can make our own item files as well (there are some issues regarding placement on the character model -- they vary based on whether it's a weapon, shield, book, etc.) If there are 2D artists here who can draw item or spell icons, those would be one or two less things that a client would need to use from EQ files (there aren't that many spell icons, so perhaps that would be a good place to start). That would only leave mob models...I've also been delving into Anim8tor to see if I can possibly import them with OpenZone (with some clearly defined constraints).

[RangerDown]

Pardon?
I believe thats 9 now.

Then the server would tell the client 9 :P Or even, the server could tell it 8 until he got the ability for his 9th and then start telling it 9.

As for textures for armor, mobs, and even geography -- could this client have some graphic cache subfolders -- possibly one for each different game it would be used for (it would creates them as you tell it about a new game) and let the serverop patch graphic files down to it. Rather than take on the responsibility of making textures, let the game designer do it. Yeah, maybe include a handful of stock ones to ease the burden on somebody that wants to do a server but has trouble drawing stick figures much less realistic monsters (like certain rangers I know :P) but construct the engine so it will look for the models and textures in the subfolder.

[Windcatcher]

I think this might be necessary anyway even if the client was for the EQ game system only, since different custom servers could have different content, like zones. There needs to be a way for a server to tell the client "hey, I'm called server xxxxxx and you should look for any custom content with my identifier". The client could look in that xxxxxx subfolder first when loading any content before falling back to its defaults.

[jbb]

My thoughts a not to even attempt to build a single generic client but use common base code to make it very much easier to build different clients.

All clients will need the following subsystems:
A renderer which can take render a vertex buffer in a particular way.
A rendering queue which will organise what to render and the order to draw it.
An input controller which organised platform dependent clicks and button presses into useful events.
An entity controller which handles movement and animation of models.
A world controller which handles loading and representation of the world.
A physics system for handling movement prediction and collision detection.
A user interface system for drawing overlay windows and routing input.
A sound subsystem for playing music and sounds.
A network subsystem for comminicating with the server.

I'm thinking that much of this code can be made generic and which will be used by game specific code to make a specific client.

First lets make a generic 3d multiplayer world which isn't a game, it just lets you move your cube around a 3d heightmap world (because it's easy to generate) and talk to other cubes. That would need a lot of the basic infrastructure to be made but need little game logic. Then use the basic code for that to build a real game.

I think the enemy is trying to do too much and never achieving anything so lets start very simple and make something which can be built on to make something good.

Going to think about this for a few days now...