Anything?

[jbb]

Any progress on this?
I'm still interested in seeing what you've done

[daeken_bb]

There's not been any progress at all lately... I've been working on some other projects (mainly working with Jon Johansen ("DVD Jon") to reverse-engineer apple's lossless codec)

Nobody but GXTi and myself has really worked on it lately at all unfortunately.

[jbb]

That seems a shame.
I had some slight problems with this project, but still think the world needs a free mmorpg client.
Maybe I'll start one.

[Ghost Fire]

Please do JBB

[KhaN]

Maybe I'll start one.

If you code Delphi, PM me~

[jbb]

Hmm. If openEQ is at all alive someone should work on it again But if it is dead someone should do *something*.

I don't really use Delphi.

I'm not going to work on an EQ replacement client for reasons I already talked about. But I would be happy to work on a generic client of some kind and if it happened to be able to use EQ level data optionally I could probably live with that. The main problem is getting test data. My 3d modelling skills extends as far as making a textured cube and that's about it, although I suppose I could learn. I downloaded blender and never did anything with it. That's why I started being interested in this in the first place - I just wanted a source of test 3d data and EQ seemed a good source.

I'm thinking that using Ogre3D would save an enormous amount of work, although it might save the *fun* part of the work leaving all the tedious bit behind. And it might be as hard to learn and add necessary code to that than it would be to write more focussed code that just does exactly what is needed.

I'm thinking I might down what I consider the absolute smallest set of requirements for a very basic mmorpg client are and have a think about whether it's a project I could find enough time to work on. There is no point otherwise. I think OpenEQ had a scope which was too large for the number of people and the time they had available. I think starting small would be best. Making a version 1.0 which isn't a viable game in any way but which gets the basics in place for a version 2.0 which is more like a game seems the way to go to me. The main problem is keeping interested for long enough to finish anything. Having small goals, but a lot of them seems to be the way to go with that.

[RangerDown]

I think you've got the right idea for a generic client. That's something I've wanted to see for a long time now and I think something the MMRPG genre needs to get away from the eq_clone rut it's in right now -- mainly cuz it'll give the genre some competition from people who'll make a game as a labor of love without regard to whether they make a dime off it.

Keep the client generic yet flexible, perhaps letting the server communicate what parts of the UI it needs for that particular game as the player enters world. IE, as the player is entering world the server could say that it has a main hotbar of up to 12 buttons, a sub hotbar of 8 buttons (a la EQ's memmed spells bar), a pet window, it has *these* chat channels available: /say, /group, /friend, /guild, /shout... and so on.

I'd talk more about this but I gotta get to work.

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