Major Design Overhaul
 

GXTi, Yodason, and I have been working on redesigning everything about OpenEQ from the ground up lately. We've been working on the xwf file format a lot, and have come up with something _very_ different in many ways.

We've completely gone away from the design of a traditional 3d file format. Entities (any static mesh) are stored in seperate files that are simply modified XWFs. Everything else is stored in the DB allowing complete abstraction. We also have come up with a system allowing users to completely change the world by different means, which can then be regenerated by GM intervention or by automatic regeneration over time. For instance, a person can go to a castle and beat down the walls and a GM can go in and change it back, or it will automatically come back over time.
This also means that content is largely streaming... we can also do transparent zoning.
In addition to that, it means that almost all the zone design can be done completely from the client by GMs... aside from the base mesh stuff.

Aside from this, we also are completely redesigning the actual client itself. Yodason and I have been redesigning the code base. We have decided to use C++ (much to my chagrin) with the one limitation that the C++ STL will not be used (it was the only way I would have anything to do with it lol)
We have been thinking through this, and I'll probably post IRC logs sometime soon.

I'd really like the community's support while we're going through these changes... it feels like my baby is going through puberty... :P

Any input is welcome :)

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)

Hmm, well that' s certainly ambitious.

Good luck :)

That's very exciting to hear, I hope everything goes smoothly with the transition.

all I have to say is wet dream...

I'm going to assume that was a compliment and say thanks heheh

Athough these changes sound great I have a couple of concerns with a couple of them. The streaming zone information seems like it would be a large drain on bandwidth. Sure it would be cool, but I dont think it would be necessary in most instances. Also I think that you guys are trying to add too many features too soon. Having goals are good, but I think you guys are trying to accomplish too much at once. IMHO having an open source client with a similiar feature set as the current client is much more important than trying to build the next generation MMORPG. Not trying to discourage you, just saying that this sounds like it will take you much longer than the previous goal of a working client similiar to eqlive.

Well, we should be able to get the bandwidth drain _far_ down, since we'll be caching a lot of stuff, and then performing modifications on that mesh from there, as well as caching textures.

Also, since we're not using EQ anymore, there's really no reason to duplicate the EQ client's features... gives us a lot more freedom :)

I think we'll be well off as long as we design it well enough to begin with... we're taking our time this time around :)

The advantage of doing things this way is that we are not a slave to existing eq features. This saves time, ofcourse, but the stuff we are preposing is going to take more time.. Don't be too sure on the bandwith problems, as Daeken said. Caching can certainly eliminate many problems, as can selectivley updating only certain verticies.. etc. Although, it remains to be seen if this is feisable at all on 56k (but thats not a design goal.. just a nice thing).

Interesting...if you can tackle the bandwidth issue, it actually sounds somewhat simple and elegant, since the client doesn't have to deal with locally-stored content (or at least not to the same degree). I say, take your time and see what you can design...my only concern is that from OpenZone's perspective that the design be somewhat stable before I start putting in the capabilities you need, so I'm not trying to hit a moving target.

I await what you produce with eager anticipation :D

I always thought that just doing even a basic eq "clone" client was probably rather too ambitious for a very small of people working part time... I would worry that you've expanded the scope a lot now, and you'll have to do a lot of server work and create all new content too.

While I certainyl wish you every sucess with this, I think you'll still be working on it in a year, assuming you can keep a focus for that long. I think a "tech demo" is easy but making a finished game is a lot harder.

Have you thought about using an existing rendering engine like www.ogre3d.org ? It might reduce the scope of the work to something a bit more manageable, and you'd have the benefit of an engine that's probably had a lot more work put in than you'd have time to do.

I have, but daeken didn't want to use ogre. I don't think anyone is denying its possible this could take a year. But just because it takes a year doesn't mean it shouldn't be done.

Of course not... It's just that projects of this kind often have difficultly maintaining focus for that long unless they have very clear aims and milestones at the start.

The first thing I thought of was this could make player houses and structures a possiblity. The basic foundation already works with the server code... All a house is is a giant container. Currently, on Emu if you drop items into the world, they will stay even on server reset. It was the ability to actually change the zone from in-game that has been the problem.
As for the bandwidth of streaming the graphical info, it can certainly be kept low, especially if there is some sort of cache setup client side. SWG streams structure data and even in the largest player city I only cap out at 6KBps while loading everything. After that, I drop to about 1KBps or below until a new structure gets loaded, or I enter combat, etc.

Player houses and structures was a very large part of the reasoning for this design (and not in swg style fashion, but in design the buildling fashion).

All of this doesnt sound good for me, and this remember a discussion i had with Yodason like 3 weeks ago. Why ? Because of how we will have to build zones, yes i admit, breaking walls is fun (The first 10min), but if you must use an inside OpenEQ editor to make zones ... i start to be worried, because we all know it will be a pain in the ass, and like OZ, no one (even myself) will use it.

RTPatcher is thx.