Older blog entries for elanthis (starting at number 184)

Sub-Rooms

Anyone who's played a MUD or text-based adventure game is familiar with the concept of a "room." Each location in the game that you can visit is classically represented by a room. A room includes things like a title, a description, the list of objects in the room, a list of exits leading to other rooms, and so on. Travelling about one of these games is accomplised by using the exits (often using directional commands like "north" or "se") and moving from room to room.

Of course, as many people also know, this is very limiting and unrealistic. You cannot easily see what is happening in an adjacent room. You can't move around in a large room. You're pretty much in the room, or not in the room, and that's it. Some games allow you to look in/at/through exits to see what is the adjoining room. Some actions, such as yelling, might cause your voice to propogate through to the adjoining rooms. All in all, however, the situation isn't very nice.

Some games have experimented with coordinate based systems. There are two main variations on this; one that continues to use rooms, and one that does not. The room based solutions seek to solve one problem: moving around in large rooms. In these systems, you still move from room to room by exits, and each room is still its own separate container. You are able to position yourself in the room, which mostly becomes useful for combat. Some of the more advanced implementations allow for more intricate behaviour based on coordinate location, such as varying object descriptions based on which part of the room you're in or limiting interaction with objects if you are too far away.

The second coordinate method is much more free form. Rooms are done away with, and instead "areas" are defined using geometric equations (most often a point and radius). When you are within range of an object its area description is added to what you "see." The description will often change as you close in, getting more and more detail. For example, a forest might add "The trees at the edge of the forest are small compared to the towering giants seen deeper in the dark wood." to the description printed with the "look" command when you are just barely within its radius. A waterfall might add "The faint sound of rushing water from a distant waterfall can just be made out." to the description. And so on.

The second system has some very interesting possibilities. The world can be described in a way which in a much looser format while still providing very indepth descriptions. Especially when more complex geometry is used to describe the world and effects like blocking visuals, directional descriptions, and so on are put into place. The system can easily be combined with a room-based system when very precise and controlled movement is needed, such as in a dungeon or other indoor area. The main problem comes from the incredibly amount of detail and work that needs to be put into each area to make it work properly. The descriptions need to match various distances, direction ("You hear the waterfall to the east" vs "You hear the waterfall to the southwest"), blocked visuals, etc. You are, in essence, creating a 3D engine, but instead of just describing the object as a model, you need to write out full descriptions for all the different ways the object could be "rendered." It's a lot of work.

Additionally, coordinate based systems suffer from both a lack of fine grained control and complexity. You still need a room based solution to lay out indoor areas or dungeons, as otherwise you would need a complex 3D representation of the indoor area and an advanced text description generator. ("A passage opens to the north, leading along a torchlit hallway. The faintt outline of a door can be seen at the end of the dimly lit passage." How do you get a good, indepth, varied description like that out of even a detailed 3D representation of a room?) Movement either becomes very inprecise (the "north" command moves some fixed units towards north) or requires very complex commands to specify the direction and distance, or raw coordinates, to move to. The player is then also required to know their coordinates and understand what those mean in relation to their destination.

The solution I'm in favor of, which I'm not aware of having been used yet, is to continue using rooms, but break them into smaller units which are heavily interconnected. I'm dubbing them sub-rooms.

The idea is very simple. Each sub-room works exactly like a traditional room. You are either in it, or not. The room contains a title, a description, a list of objects, and a list of exits. The big difference is in the exits. The exits not only describe ways to leave the current room and enter the next, but also a wide variety of flags which specify how events in one room propogate to the next and what can by default be seen or interacted with in adjoining rooms.

My favorite example is a large room broken into several pieces. There is the main floor of the room, a stairway running along the north wall with a balcony at the top. There is a door on the balcony and a door under the balcony, both of which lead into hallways. Players in any part of the room can hear things which occur in another part of the room. However, players on the balcony cannot see anything under the balcony, nor can players under the balcony see anything on the balcony.

Movement in this situation continues to work as it classically does. "go under balcony", "climb stairs", "out", etc. Player interactions, however, can be much more complex. In a classic MUD, either the entire room is a single area, or the balcony is a separate room requiring special commands to see down to the floor and listen to anything occuring there. In this model, a player could run up the stairs, comment to his friends, and then go through the doorway. The sounds of battle occuring in the hallway would drift to the ears of people in the room. Players could leap off the balcony onto the floor below. A player could crawl onto the balcony above and listen to a private conversation going on in the room below. And so on.

This system would actually be very easy to implement. As mentioned above, many of the changes are on the exits themselves. You'd just add a number of properties to each exit specifying whether to display people in the adjoining sub-room, whether speech should carry through, and so on. The rest of the changes would be to carry through the actions. If you say something, check each exit in your sub-room and, if they specify for speech to carry through, print out what is said to the connected room. The room description code (for "look" and similar) would be updated to display characters in adjoining rooms if the exit specifies it to be so. ("You are on the balcony. Jay is also here. You see Rob on the floor below.") Finally, the object lookup code (used to find the player object when you type in a command with "jay" for example) would then be updated to search adjoining rooms as well.

That fairly well sums up the sub-room idea. Combining it with features that exist, but are rare, in classical MUDs, such as basing an exit's status on the status of an object in the room, would allow for very indepth areas. Imagine being able to jump on a table in a fight. Or being able to kick the table out from under someone in a fight. Pretty nifty stuff.

[#] Comments

Crash

Hmm, the Novell iManager login is failing for me with a Java crash and traceback. Which means I can't do jack crap in terms of administration, since the only tool I have is the web-based manager. Darnit.

[#] Comments

So I Feel Dumb

My boss recently upgraded the eDirectory installation used for things like dial-in authentication on his server. His upgrade managed to break searching for user records by cn. I.e., an LDAP query like (cn=smiddle) would fail, although it shouldn't have. During the 5 hours it took to fix this, though, I somehow managed to forget how exactly LDAP worked, because I managed to convince myself that the query (cn=smiddle,ou=Civic,o=CTY) would work. That is the object's DN; a query like that however doesn't search for the object at the DN, it searches for an object with a cn of smiddle,ou=Civic,o=CTY which of course isn't right.

So it took 5 hours to fix the eDirectory server. Then another day and half for me to realize that yes, the server's fixed, and no, I'm trying to do things the wrong way. ::sigh::

So now I'm just waiting for the ridicule on the help forums where I posted these big long examples of how "the server's still broken" where people go, "hey dumbass, you're doing it wrong!" On the upside, I'm doing it right now, and everything works, and hopefully I never have to think about LDAP again for a while. ;-)

[#] Comments

XComposite

Fedora Core 3 has the new X.org R6.8 release in. Which is cool, because that includes the new XComposite extension, along with other various nifty features everyone and their mother has no doubt read all about by now.

FC3 does not currently have xcompmgr, but that's not a big deal; I grabbed a copy of its single source file from freedesktop.org's ViewCVS installation and hand compiled it (seriously, a piece of cake) and got it working.

Unfortunately, metacity also has its own compositor, which is compiled in by default on FC3, which has no way to disable it, and which is buggier than a manure cart in June. The only way I can enable the composite extension and get both good looking shadows and performance that doesn't suck like a cheerleader on prom night is to use a different WM than metacity and use xcompmgr. Of course, there are no other WMs for GNOME installed on my machine, and using GNOME with twm is just gross. (I know twm is supposed to be minimalistic, but at least EWMH support would be nice...)

Anyways, the performance with xcompmgr is excellent, and the shadows look nice. Metacity already has some tricks when using the compositor (like windows become a little translucent when you move them), but the performance problems with its compositor completely preclude its usage. Hopefully the metacity compositor bugs are worked out and it learns to work as well as xcompmgr, or an option is added to turn off the metacity compositor (but keep the composite-based effects, if possible). Obviously I'd prefer the former. Although the later would be good for people wanting to experiment with new compositor ideas and also wanting to run GNOME.

The next step will be getting the compositor to play right with GL, if it doesn't already. Imagine if metacity could pull tricks like composite two workspaces to GL textures during workspace switching and pull off some freaky-type 3D effects while doing so. Or change the visual bell to instead make the whole desktop ripple like a reflection in a pond after dropping a pebble in the middle.

Nautilus could perhaps also make good use of composite. Currently, it draws an entire window for the desktop. This is so that it can sanely handle grabbing mouse events on the desktop and draw the icons. WMs can already grab mouse events for the desktop, and if each icon was instead drawn as its own window with the compositor making it merge automatically and nicely with the desktop, one could run other programs solely on the desktop itself; things like apps which slowly morph the background over time and so on. Could be a lot of fun.

The truly amazing things will be when people start figuring out how to use these new extensions not just for eye candy and performance, but for actual new useful features that were just too impractical to implement before. Shadows and translucency and 3D effects and so on are pretty, but they don't let you actually do anything useful you couldn't do before. Despite what some big monopolies might claim, one of Open Source's (and Free Software's, of course) biggest strength is its innovation.

[#] Comments

Late Night

Will be staying late tonight to finish the server transition. We installed the RHEL server on a piece of hardware not intended for it, because we didn't know how well it would work out and we couldn't bring the actual Debian server down during the week. Tonight, though, I'll be staying late, wiping out the Debian server and transfering the OS over from the temporary server.

Not exactly sure how I'll tackle that yet. I'm planning on using the RHEL install dics to setup the RAID array, then hopefully use the rescue CD to transfer a big huge tar'd up image from the temp server, and unpack it onto the correct server. Hopefully that works.

If not, I'll have to do another clean install of RHEL, then copy over the custom built and downloaded packages from the temp server, then copy over the configuration. Too much room to forget something there, though, especially given that the software configuration on the temp server is already done.

[#] Comments

Farewell

Libby is heading back to Seattle early next week. Monday night was probably the last time I'll see her until Christmas or later. ::sigh:: We went to Benihana's, which is a simply superb Japanese restaurant. The chefs prepare the food at your table, making for both a nice meal and decent entertainment. The food is top notch. Best fillet mignon I've ever had, bar none. Love it.

Not really sure how well I'll hold up with her leaving, though. She's only been here for a little over a month, and it already feels natural for her to be around again. Might have to do with the fact that every single weekend we've spent in each other's company, for the most part, not to mention a good number of nights and lunches during the week days. It's just finally starting to sink in, though, that I'm not going to see her again in a very, very long time.

I don't want her to leave, and I especially don't want her to go back to Him. Who would, right? ;-) But she loves Seattle, she loves Him, and that's what makes her happy - I really don't have much right or room to complain. Doesn't mean I can't be sad about it, though, right?

On a slight upside, I might finally be able to get back in touch with Katie. She had, so far as I thought, tried fairly hard to avoid me for ~6 months. According to Libby, no, she thought I was avoiding her. Grr. Libby will, hopefully, set her straight as they'll be spending the weekend together, and perhaps she and I can start hanging out again. Which will be good, as Katie is a very nifty-type person; one of the few people I've met that I can stay around for more than 30 minutes without getting annoyed at. ;-) That makes, what, three people I can say that for?

[#] Comments

Flexibility vs Sanity

AweMUD has had, for a long time, a goal of being very flexible. Code changes were to be kept to a minimum, scripts should be able to over-ride everything, and new C++ code should be able to be added with a minimum of tweaking to the internal engine.

I'm slowly moving away from this approach, however. For one, flexibility can make the code an absolute bitch to work on. Being able to code huge swaths of the core functionality in scripts isn't necessarily a good thing; script languages aren't designed for application programming, they're designed for glue and simple logic, and that's where they should stay.

Take, for example, the pending actions stuff in AweMUD. The current code I'm working on makes an IAction type that every action derives from. Every action put on a character is thus an object. The advantages? First, you can easily add a new action by just creating a new subclass. The subclasses can carry all sorts of additional information with them (any sort of state they need) without needing to extend any other code.

The disadvantages? Every action requires a new object allocation and creation and eventual deletion, even simple actions need a whole class written to handle it, and the code gets spread all over the place.

Is the flexible method really the sanest method?

[#] Comments

Amber Chronicles

So I have, last night, finished the Amber Chronicles by Roger Zelazny.

This books are fucking awesome. No, seriously. If you read any fantasy series, read this one. I absolutely love it.

Only, there is a slight problem. See, there are ten books. Two sets of five. The tenth book does not complete the story, however.

Reading reviews online, you'll see a lot of complaints about this fact. The story doesn't just have loose ends. It flat out isn't finished. A lot of reviews give the author flak for ending the series so poorly. As if it was his intent.

There was a rather big space of time between the writing of the two sets of five books. It's pretty damn obvious that Mr. Zelazny had intended to write at least another set of five books. Had intended. Mr. Zelazny has, unfortunately, passed away. The series will never be finished; at least, not by his masterful hand.

Another author has started a new series, a trilogy, which is a prequel to the original ten Amber books. There are also some Amber short stories authored by Mr. Zelazny himself. Nothing yet, however, which continues the excellent story to its ultimate conclusion.

I can't tell you how depressed finishing the books as made me. Not because they are bad. But because they are true excellence, in my opinion, and having no more of them to read makes me very sad. Not even the kind of sadness that comes with finishing a book by Robert Jordan or another living author; at least with those, you know the story will continue, eventually. With Amber, it's just done. Even if another author started writing Amber books, I doubt they'd be capable of kind of writing which Mr. Zelazny employed.

I've yet to read the Dawn of Amber prequel trilogy. The reviews aren't too hot. And not for the same reasons as the poor reviews of the Amber chronicles; other Amber fans seem to dislike the prequel series. The third of the trilogy is not yet out, however, so it very well may save the trilogy. I'll have to read them myself to see, of course.

[#] Comments

Bye Debian

Yay! Finally getting rid of the Debian server at work. I don't really want to get too far into the details of why that makes me so happy. Suffice it to say that the quality of the Debian OS has diminished vastly. My guess as to why is far too many packages, far too many packagers, and no clear technology goal; just the mostly useless (in terms of getting real life work done) "pure and Free" goal.

If they broke Debian into a Core and an Extras (similar to how Fedora would work if they actually got off their rears and finished the contributor infrastructure), concentrated on frequent releases of the Core and an unversioned Extras, I think things would be fine.

But, in the meantime, the number of bugs of Debian, the fact that you are required to use testing or unstable to have modern usable software, and the fact that the resulting system is barely trustable, has resulted in me switching to RHEL (CentOS, actually, as one or two low-end servers just isn't worth the price Red Hat is asking). Which isn't a bad thing - I like RHEL.

[#] Comments

Personal DAV Server

I want a personal DAV server.

What I mean is, basically, something like Samba, but for WebDAV. Apache needs to run as root to do this appropriately, and that's both gross and stupid. A personal DAV server would be a lot simpler. This is how I would architect it, had I any knowledge of DAV.

First, a main process would sit and listen for requests. When it gets one, it would authenticate it. It can even do cool things like use cookies and stuff to manage user sessions for extra speed and efficiency. Once it knows which user is accessing it, it would see if there is already a process for that user to handle the request. If so, it would pass the request along to the sub-process (possibly just transferring the fd itself over a UNIX domain socket). Otherwise, it would start a user process, and *then* pass it along.

The user process then would be in charge of serving the request. This process would be running as the user in question, so there is no possibility of accessing something the user usually couldn't. Additionally features could be added, like forcing the connection to root at the user's home dir (using either a virtual root, which would allow symlinks out; DAV can't create symlinks, so this is safe except for users with shell access, and there's no reason to lock down DAV for users you give shell access to) or by actually chrooting the process (which would work fine, as it needs no external tools).

It may not be the most scalable solution, but it should be pretty secure, and works for the environment I'm personally most concerned about - my home network. I could set this up on my file server and have quick and easy access to all my files from UNIX, OS X, or Windows machines. It would Rule(tm).

[#] Comments

175 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!