4 Feb 2004 elanthis   » (Journeyer)

Orkut

So, nobody has invited me to Orkut. This doesn't surprise, since I don't actually know anybody in the FOSS world, and nobody really knows me, except the people I've managed to irritate greatly (hi GNOME devs ^,^ ) and they probably don't want me anywhere near them. ;-)

On the upside, however, this means I haven't wasted any time what-so-ever on this supposedly addictive site. And, to be honest, given that I don't know anybody in FOSS, I don't think I'd have anything interesting to do in Orkut even if I was a member.

On a side note, the fact that there is a market for invitations rather strongly indicates how incredibly lame some people are. ~,^

Dragon Slave!

Bought two Slayers movies, "Slayers Next" and "Slayers Great." I'm not sure whether I like the movie character or series characters better. The movies lack Zelgadis, who simply rules, but the series lacks Naga, who also rules. (Altho I honestly believe the artists went a little over-board.)

Anyways, both films were money well spent. Only, it rather drives home the fact that I hate watching anime alone, and the only three people I really enjoy watching it with are either very far away or no longer want much to do with me.

AweMUD Affects

Ya, so I'm going to write about the affect system for AweMUD, yet again.

This has been the hardest AweMUD feature to get started on. The problem is it is just very hard to get right. Especially given how dynamic it has to be. In some of the older game engines I've written, namely the old roguelike War of the Runes, the affect system was quite simple. There were no dynamic scripts or plugins, so everything could be kept internal and very simple and clean.

That was back in my youth (no, I mean, really back in my youth - not like last year which was also in my youth...) when my C++ coding was basically just C with methods on structs, so affects were pretty much an array of affect IDs and arguments. Things like, AFFECT_DAMAGE with arguments of the DAM_FIRE constant and some number for amount. Arguments where just ints, up to 5 of them. Bloody simply.

But no, not in AweMUD, because I have this silly wish to make everything scriptable (which is good, of course). No simple enumerations of affect IDs and simple parameters. Nope. Instead, I need a class interface, and each affect must be a sub-class, and affect instances need arguments more varied and descriptive than ints, so we need to attach a vector of Affect derived objects.

Of course, because of the C++ nature, we can't cleanly just have the Entity class (which is the base of all classes of things that exist in the MUD world) keep the affect list (centralizing everything), because the Affect then wouldn't be type-safe in regards to affects that only work on, say, Characters, or Objects, or whatever.

But, adding an Affect list to each Entity sub-class is evil and wasteful. This means I either need the IAffect class to just worry about Entity types, and have the individual affects to dynamic type checking (which isn't too bad, but it means a lot of extra code in the Affect sub-classes) or a templates Affect class that derives from IAffect and just adds type-checking, which then centralizes that.

I don't really like either solution, tho. Both need a lot of "hacks" to get around the problem. Only, no matter what language this would be written in, the problem would persist, because the affects need to be written for the specific features of the Entity subclasses. ::sigh::

Scriptability

I firmly believe that apps should be extensible and scriptable.

However, there may come a time when one has gone too far. Namely, when core parts of your app are tossed out into scripts. Scripts are great for quick addons or anything that needs to be changed often, but they aren't good choices for things you expect to be relatively static, or things which are rather large and integral to the application.

Like, for example, AweMUD's combat system. Or character creation. The former was put into a script more just as proof I could. Which is a pretty damn dumb reason. The later was done to make character systems flexible but, to b honest, there's still a lot of C++ code that needs to be changed to change character internals, so what's the point?

Both would be tons easier in C++ in many ways (albeit, much harder in others - I think the ease will outweigh the pain, tho).

Getting back to Affects, then, just how dynamic do I really need to make them? Instead of just making a big dynamic affect system, what would happen with a tightly coupled simplified affect system with lots of small but specific hard-coded affects, that could then just be "assembled" together to make larger affects? Work better, perhaps?

::sigh:: If I keep trying to find the 100% best solution, this'll never get done. I just hate forging blindly ahead, as it almost never results in anything worth keeping. Maybe I just need to prototype some things out and see how they work?

Ack, I'm rambling. Time to go practice my bass. :)

Ooohh! My iBook shipped. Go me! ^_^

Latest blog entries     Older blog 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!