Anything?

[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...