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.

I disagree, guildhouses, and purchasable property, that would be awesome )

You do not need a new engine to make purchasable properties, because EQEmu already allow to place object in a zone, just make a house, castle as an object, and one NPC can place it at the coords ...

Those objects you can walk right through (bag on the ground). and you could still only place set "stock" houses then. As opposed to designing it by each and every wall, etc.

Remember we did have the discussion, Khan, that however I did it, I would make sure it was level designer friendly (I seem to remember a discussion one possible way might be to use maxscript.) The much more broader picture I had of this was a world where you can influence the world; this simply is not possible in a static geometry.

-- Yodason.

(yes, part of the post did dissapear, deal with it.)

I remembered that you were asking about GUI toolkits for OpenGL, and I ran across this by chance on Slashdot...

http://www.cs.unc.edu/~rademach/glui/

I was looking at FLTK as well as this... both seem pretty nice.

FLTK is nice, pretty simple to make.

You wont walk through a wall that is placed ingame using EQ. Try this if you dont understand:

Use an object viewer to view all the objects for OOT. A few of them are walls (some are even houses). Add those objects to your door table for OOT and then zone in and go to the coords of where you placed the objects. They act like a normal wall. The same is true for the houses you can spawn by simply adding them to your doors table. I know because I did it on a server I was running. You can easily build stuff using the current engine, the only limitation is that there isnt very many objects that are appropriate for the task. If more were added or an addon like OpenZone could be used in game, you wouldnt need to redesign the engine.

The likely reason you can walk through a bag is because it probably isn't checked in the collision-checking code. The same is for tree leaves; all that's needed is a flag for checking/not checking collisions. As long as an object is placed appropriately in the BSP tree/octree, it can be checked for the purpose of collision avoidance. The only issue is polygon count: adding too many polygons in a small area can cause lag.

OMG stay away from glui...
it is the biggest, bugiest piece of poo i have used in a long time...

just my 2c on this one.

Yodason, all i have to say is, dynamic content (dynamic meshes) is nice, but see around you, fact is, few people is able to make static content (static meshes) using OpenZone, and fewer will be able to make dynamic content.

I dont say i dont want dynamic engine, but i think atm, basis of OpenEQ should be priority (something stable, using EQ files). Like, if you create a new soda, you will study the market to see if peoples will drink it .... if you make new game client, you will study the market to see if players will use it ... mkay ....

Im disapointed that I won't have a client for EQ that I can customize to include lots of new features but if my machine can run it I will most definatly be using it.

I agree with KhaN. Make something stable first (using EQ files), something that actually works and then go from there. You'll need those easy advancements to not lose the fun of working.