Sean Middleditch » 2005 » July
Update: Phillip informed me that supporting Apache or init configuration is not a goal of D-Conf. Reviewing the public D-Conf documentation confirms this. That misconception seems to have been based on unofficial comments during earlier portions of D-Conf’s design proposal. The rest of my criticisms of D-Conf’s design still stand. Please read http://www.x-tend.be/…/000076.html and http://www.pvanhoof.be/dconf_detail.png for more details on the D-Conf design.
I’d still say that the current “official” D-Conf proposal is complete crack. Your diagram shows this - it is *so* much more complex than any piece of configuration software needs to be!
As I tried to tell people back when the original D-Conf discussions started on xdg-list:
D-Conf should be NOTHING except a D-BUS API. That’s it.
D-Conf should have NO concept of plugins or backends, you get that by free by using D-BUS, just replace the daemon and you get a new backend implementation.
Daemonless mode is pointless, every desktop app needs a daemon to get desktop behavior, and trying to get init or Apache or Sendmail or whatever to use D-Conf is a waste of time; you are assuming Apache wants or needs a new configuration framework with absolutely no proof. You’re just designing complexity into the system because it sounds cool or seems like it might be a good idea, possibly, maybe.
You have tried to design the entire back-end storage implementation as if it were an enterprise-level server for 100,000 clients before you even have the API down. The first version of D-Conf, and the ONLY version you should even be TRYING to think about right now, should have a rickety little C daemon that writes keys to files, reads them back, and sends events when they change. Tiny little simple program that you could probably write in under 2k lines of code. Don’t try to put in a bazillion threads and caches and concurrency and replication and so on until you actually have a good reason to. It doesn’t help that you’re designing the daemon to be a system daemon instead of a user daemon - for the desktop, there is no need for the daemon to handle multiple users. Even if you do someday want a system-wide daemon, you don’t need it while you’re developing the D-Conf API, so just drop that entirely and worry about re-writing the daemon if and when you have a real actual need for it.
D-Cong *is* crack, because it is over-engineered. It’s attempting to solve every single possible configuration problem ever conceived before it’s even capable of solving the simplistic of configuration problems. Implement something very, very simple for 1.0, and then move on to more large-scale efforts for 2.0, but *only* if you really need it - if Apache doesn’t come to YOU asking for support for Apache’s needs, don’t go trying to design D-Conf to support Apache.
As stated previously, I’ve been having a lot of fun lately playing the two GBA Fire Emblem games.
One thing I particularly like about the series is how it limits save/load cheating. Every single move you make is saved. You can only load games either at the beginning of a chapter or where ever you last left off. That makes it impossible to reload an earlier version of a mission if you make a mistake. You can restart the entire mission, but on many missions that’s a lot of pain, and in all honesty pretty boring. I’d like to see it where you can’t restart the mission at all. Or perhaps you can restart the mission only if you completely lose - if you just lose a unit or miss an item or something, you can’t restart.
I’ve been thinking about what I would have done differently had I made the games. This isn’t much of a surprise, given that’s how I got into programming to begin with. I’ve also been thinking about the new Game Cube Fire Emblem game out in two months, and the features it will bring to the table.
First, I really like the class/level system in Fire Emblem. Very simple, provides lots of improvement opportunities (38 level-ups for most units, 47 for a few others), and a variety through class branching (two for most units, 4 for a few others). The game mechanics are very simple and easy to grasp.
However, being the achiever/explorer type in gaming, I’d prefer more opportunities for character growth. I’d honestly add another level of class upgrades to all units, sort of like the three “trainees” in Sacred Stones. That would be 47 (or maybe 57) levels for all units, and two class branches to choose from.
I would remove the upgrade tokens from the game. I don’t think they really serve much purpose. Most players will always wait until level 20 to upgrade their unit, and I don’t really see *that* much of a shortage of upgrade tokens; I’d argue that the only reason you have a shortage is because you often have too many extra units.
I’ve also thought about adding yet one more class choice - upon reaching 20th level in the final class progression of a unit, the unit gets to branch to a “perfect class.” This class does not gain any further levels, but grants a new ability and some stat boosts. The mage knight might have perfect class options of either a class that can use swords or a class that can use bows, for example.
The rest of the changes I’d make would all be story/game-play based. There would be far, far more branches in the quest. In the two GBA entries, you had the occassional optional side-quest and two main story branches. I’d have a larger number of branches (4-8) and a good number (15-20) of optional side-branches. Example story branches might be something like, “should we attack the enemy nation head-on and quell their evil while our ally restores peace here, or should we campaign against the bandits and mercenary gangs ravaging our country’s villages and let our ally attack the enemy nation?”
The side-quests available should depend a lot more on the units you have and their actions during missions. Perhaps only if Jerad the archer attacks the bandit leader will a side-quest open - Jerad knew the leader and in their taunting, the leader refers to some item of interest from Jerad’s past that opens up the side-quest.
I’d also have the enemy and friendly units be a bit more pro-active in dialog. In the current games, it is always up to the player to talk to a friendly unit, for example. Friendly units should, if they have cause, seek out the player. Or the player’s units. The same goes for enemy units. Perhaps the bandit leader recognizes Jerad in the fray, and if he closes in with Jerad and talks to him, Jerad joins his side. Killing the bandit leader before this happens will prevent that from occuring. On that same mission, however, there would still need to be a good cause to have Jerad on the map (say, only he can convert one of the other enemy units over to your side).
I’d also limit the number of units you can have in your army at a time, and a allow the dismissal of units. In both my save games on the GBA entries, i have a large number of units, with about half of them being unused and low-level. There’s no point to levelling them up because they won’t be any better than the good unit I already have. Instead of having 30 units to choose from, the player should be forced to keep a smaller number of units in the 10-14 range. Just to make the story more interesting, I’d go so far as to say that the player can’t just dismiss any unit, but instead is forced to pick between certain pairs. Say, Jerad and the mage Hanred don’t get along as they served in opposing armies a decade ago, so if attempt to recuit Hanred, Jerad offers opposition and you have to choose which one stays. The consequence might even impact later missions as the one you dismiss might end up being an enemy. Plus, the side quests available will depend on which units you have, so if you dismiss Jared then you can never get any of the Jared-initiated side quests.
The AI would also need some work. The GBA games understandably don’t have a lot of AI capability. The Game Cube entry will hopefully have far better AI. I’d hope to see an AI with a real understanding of tactics and goals. i.e., using choke-points for an advantage, putting high-defense units in front of ranged units, sending the swordsman toward the axe users and cavalry towards the infantry, and so on.
I’d also add more randomization. If you play through the game twice, it should seem at least a little different each time around. Maybe the same basic types of units (this mission has 8 swordsman and 4 cavalry) but with their positions mixed up a bit, or with some units being randomly chosen from different types (40% change of being an axe user and 60% of being cavalry) and so on.
The final thing, adding on to the previous entry, would be a random campaign mode. No real plot, no main characters, no side-quests or interaction or anything like that. Just 20 random linear missions with a basic underlying theme (invade enemy territory and defeat leader, wipe out roamind bands of enemies, defend homeland, whatever). You’d pick 4-6 basic level 1 units to start your army with, and have the opportunity to recruit more randomly generated units over the coarse of the missions (say, one map may have a village which, if entered, present a new unit that joins, which could be anything from a mage to a cavalier, with theri level based on the average level being, say, half the average level of the current army).
I think it would be dead simple to write an Open Source Fire Emblem style of game. The games are just *so* simple at their core.
Last weekened was KANAR, although I only went for a grand total of two and a half hours. Friday was my grandmother’s birthday, and even if it wasn’t, I just plain didn’t feel like going. I went on Saturday only because I ‘lost’ a toin coss between going to KANAR and getting drunk. Stupid coin.
I’ve heard that this last event was one of the best ever. I don’t even feel sad that I missed it. I just really, really don’t care about KANAR right now. I think it may have something to do with how I’m feeling in general thanks to a certain someone; I really don’t want to socialize or do anything other than lounge around half cogent playing video games.
Speaking of which, I finally got a copy of Symphony of the Night. Unfortunately, I found out the hard way that even though it plays in a Playstation 2 just fine, it for whatever reason can’t see a PS2 memory card, although supposedly it will see a PS1 card in the same slot. No idea what’s up with that (other than just bad hardware abstraction, I guess). Ah well. The game looks pretty neat.
Also been playing the new GBA SP Fire Emblem game. I never finished the first GBA SP entry in the series; will probably do that after I finish the current one. I really like how the level/class system works; it would be horrific in a role-playing game, but it’s great for an adventure/action/strategy game. I might just reuse that system in some future endeavor of mine.
In other news, Libby leaves back to Seattle tomorrow. Not sure when. Suffice to say, I definitely won’t be seeing her again, at least not this year. I’m rather torn on that, too - on one hand, I already miss her terribly, and on the other hand, I’m extremely upset and disappointed with her right now. In an attempt to take my mind off things, I decided to give eHarmony a try; gods know Libby’s not the only girl of her class in the world, and maybe this online thing will help me find someone better. So far I’ve had one person contact me to “begin discussion,” but I need to pay to respond, and I flat out don’t have the money. Especially not after dropping $100 a few days prior on video games and books. ^^; Next pay check I’ll consider buying an eHarmony subscription. It’s mad expensive, though - $50/month or $100/tri-monthly. Ouch.
I’m heading to Florida at the end of August, apparently. I don’t *want* to, but I am. Family decided it. They seem to think that the best thing to take my mind off of you-know-who is to spend several days being a tourist (I hate doing touristy-type things) and constantly being around my family, who I can barely stand normally. Yay me.
Saddest note of all - I’m out of the good rum and I’m too lazy to go buy more. :-/
It’s ballooned to about 1.5k lines, and there’s still a number of things I need to implement. So much for my dream of keeping it under 1k. I really doubt that it’ll ever top 3k, though.
There are three main features yet to be implemented. The first is MCCP support. The second is ZMP support. The final is the rest of the telnet necessities; the protocol is parsed and generated correctly, but everything besides raw text input is ignored.
I got bored at work today and decided to, instead of working on AweMUD, start playing with JavaScript and SQLite.
I’ve had this idea in my head for a week or three now on building a MUD kernel for developing JavaScript-based MUDs. JavaScript is a very capable language. It really just needs bindings to I/O to be able to build a complete MUD on its own. I decided to go a *little* further and provide the following features:
* Telnet protocol handling
* Timers
* Main loop driver
* SQL-based storage
And that’s pretty much it. The entire codebase is under 600 lines at the moment, although it’s only about 60% complete. I still need to write the telnet handling code (which on its own could be several hundred lines), the timer code (this is *very* simple, not a big deal) and provide bindings to SQLite for JavaScript (also not a big deal, I just never did it before so it’ll time a little time learning how).
Had I already been experienced in using the SpiderMonkey API, I probably would have had the project 90% done by the end of today. Ah well. I’m still fairly happy with the features it has so far. One of the better ones, that even AweMUD lacks, is how it handles listening sockets.
A JavaScript API allows the scripts to register a name, interface, and port for listening. The interface can be any IP address (even IPv6) or node-name, and that becomes the interface that the listening socket is bound to. AweMUD always binds to the 0.0.0.0 and :: interfaces. Second, you can make *many* listening sockets, so you could listen to 192.168.1.1 and 192.168.1.3 but not 192.168.1.2 (assuming all were valid IPs for the host). Even more control than AweMUD has. Finally, the name of the listening socket (which doesn’t have to be unique) is based in to the connection callback. This allows scripts to alter their behaviour based on how the client connected. For example, all administrator features might require that the user has admin privileges *and* that the client connected over the loopback interface.
The only other feature I *might* want to add eventually is an HTTP server and client w/ very simple XML DOM support. The HTTP server would allow building an admin interface or just a simple RPC interface. The HTTP client support would be used for RPC stuff. For example, you might have a website for your MUD on have a form for updating player account information; this could use AJAX to invoke a method on the MUD server using HTTP/XML (either XML-RPC or a custom format). Alternatively, the player account information might be stored outside of the MUD (such as a MySQL database) and the MUD could use the HTTP client support to connect to an Apache/P* interface to the database to verify passwords and retrieve/update account details. There are plenty of other possible uses for this stuff as well.
I’d like that feature in AweMUD, too. For AweMUD I’d probably limit it stricly to XML-RPC, though, because I don’t want to have to do a bunch of DOM manipulation in C++. *::shudder::*
So, not necessarily by choice, I saw the new WIlly Wonka movie a few nights ago.
Ugh.
My issues with the movie are numerous. The most severe flaw with the movie was that it completely lost *all* of the magic of the first. Willy Wonka and his Chocolate Factory were, in the original, strange and wonderful places out of any child’s dream. In the new movie, it’s just a place filled with special effects. Even the oompa-loompas loose their mystery in the new film.
Second, the movie removes all need to think in any way. When the kids other than Charlie are shown on TV, the grand parents feel the need to describe how horrid the children are. Isn’t that apparant on its own? Or the gamer-kid explains to Wonka why some of his ideas are scientifically unsound in detail, as if we couldn’t tell on our own that science had nothing to do with the wonders Wonka was working. (Say *that* ten times fast…) Another example of this is when the squirrels are checking the brat’s head, Wonka has to explain what they’re doing; this should be obvious given that they just explained it two minutes prior!
Third, the new movie’s focus was almost entirely on Willy Wonka himself, *not* on Charlie Bucket. In the original, the story was about a boy in poverty who dreamed of a better life for himself and his family, and who found that life in the chocolate factory - Willy Wonka was just a supporting cast, a plot device. In the new movie, you aren’t made to feel for Charlie at all (the way his poverty is displayed is more humorous than sad) and instead are made to feel sorry for Willy Wonka and his broken childhood.
Finally, I don’t care how cool Johny Depp may be, he will never - *NEVER* - replace Gene Wilder as Willy Wonka.
My truck is fully paid off.
Wee. ^_^
That’s $8,000 I’ve managed to sink into the car over the last six months. Well, my parents sunk a couple grand into that as well, much to my consternation, but what am I supposed to do about it, eh? Anyways, no more truck payment, *ever*. My only bill in the world now is my insurance payment. Soon school loans are going to rack up, though.
I am so broke. I have <$500 to my name right now. I guess I have a *fully paid off Ranger* to make up for it, though. Yeah!
So I closed all the Sourceforge-based mailing lists for AweMUD. The biggest problem was the horrendous management options. I was constantly getting bombarded with “unapproved sender” mails from spam. So dumb. For most of the lists, I just told users to move to the forums. For a couple of the lists, I’m now using Google Groups.
I’d also like to bring the bug tracker off-line. It’s not really being used - the project is too small and has too few users. The forum would be just as usable of a place to track that kind of stuff; just mark action bug-report and feature-request threads as sticky. The serious developer in me rather prefers having the bug tracker, though.
I’m a big fan of the Slayers anime, and have been interested in picking up the mangas now that they’re being released in English. I order the first book of each of the three series Slayers Special, Slayers Super Demon Mega-Explosion, and Slayers Medieval Mayhem. I also ordered Van Von Hunter volume 1 while I was at it. I also considered buying the first of the Slayers novels - yes, Slayers was originally a novel series before it became a manga and anime series. Being poor, though, I had to cut something out, and I decided to work on my manga collection a little more before buying yet more books.
I’m also happy to report that I wasn’t the least bit hung over today. Totally wasted last night, no hang over today. That might not mean much though - the first time I drained a whole bottle of rum I didn’t even get a buzz, and last night I was _gone_. So next time I get drunk (sadly, I do believe there will be a next time, because drunkness has its advantages which I need to partake in lately) I could very well end up with a hang-over the next day.
Today, though, just half a bottle of parrot bay. Yum. Need to try to Bacardi (sp?) - say a commercial on TV (eek, advertising *actually works*, despite its irritating evilness!) for their cocanut rum. I think that stuff is a lot more expensive than the Captain, though.
I need to get some of my buddies that drink all over here and try one of the anime drinking games. I found some ideas for doing Slayers as a drinking game (two shots everytime Xellos says, “It’s a secret!”), the Love Hina game was fun, and I’m sure we could turn any other comical anime into an easy drinking game. I also half-concocted D&D drinking rules.
Every player rolls a d8 to see what their condition is. Might be something like “fail a saving throw,” “cause damage,” “take damage,” etc. Only applied to things that happen to their PCs, not any henchmen or summons or anything. When they do their condition, they take a drink, and roll again. The DM uses a different system, since otherwise he’d end up drinking eight times as much as the players. The DM rolls a die to select a player - when that player is takes a drink, the DM also takes a drink. Thus his drinks should average out to about the same as the rest of the players. I’ll have to write these rules down and give them a shot.
We also came up with some half-written field-battle rules for our D&D game since we’re in a war setting right now. I didn’t want to use D&D minis rules because, for one, they are small unit battles and we’re playing large-scale war, and two, I don’t have any of the appropriate minis and the rules are too complex. Instead, I draw out a hex grid on the white board and draw in terrain. The armies then place units; we just write in the units on the white board grid. For example, on hex might have an enemy army with Archers x3 and Cavalry x2. Now each side takes a turn (no initiative except in very small battles). One or more units in each square may either attack or move. Archers can only attack adjacent hex. Infantry can only attack in the current hex. Cavalry can only attack in the current square, but they can also move and attack (and get a combat bonus when doing so). Some units can attack both close-range and attack adjacent hexes, like mages. The attacking side and the defending side each roll a d20 and add their combat modifier. The combat modifier is equal to their number of units plus their terrain advantages plus any special bonuses (like cavalry’s charge bonus, or elves’ bonus when fighting in the woods). If the attacker matches or beats the defenders roll, the defender loses one randomly selected unit. However, if the attacker’s roll is beaten by the defender, the attacker loses a random unit. This only counts if the defender can attack back - archers attacking infrantry don’t have to worry about losing units in return. In some cases, there are two different combat numbers - say you shoot at a group of three archer units and four infrantry units - the defenders get a +7 on their combat roll to see if they are beaten, but only use a +3 to that roll to determine if they caused damage back on their attackers. The terrain has height levels for advantage, and structures grant advantages, and so on. All in all, it’s *very* simple to play by and *very* fun if you like strategy and battles. We also have some simplistic rules for moving the PCs into the battle as units and switching between mass-battle mode and standard D&D melee mode. Pretty cool.
Being the evil lazy bastard that I am, I started making updates to Scriptix instead of working on Scriptix2.
Aside from API updates, there are some langauge changes.
For one, you now have to declare variables using the var keyword:
var foo = 1;
var bar;
Pretty simple. The second big change is that I’ve changed the dereference operator from . to ->. I’m not sure if I like this one, to be honest, so it may change back before I commit the changes.
var foo = object->get_id();
I was planning on using the . operator for string concatenation (instead of using +). However, if I manage to get static typing into Scriptix 1, there won’t be a need for two operators for this other than cleanliness. I could also just use another operator like %, &, or so on. Hmm… let’s compare:
adj + name;
adj . name;
adj & name;
adj % name;
adj @ name;
adj ~ name;
adj | name;
I like the first two best. The second option, using ., is like PHP, which is a language I use a lot. The rest of the options just look alien to me, probably because I don’t regularly use any languages that have operators like those for string concatenation.
The current plan is actually to fold Scriptix into AweMUD. There is no real benefit from having the codebases be separate, and there is a lot of pain and missed opportunities for integration, so I might as well just do it.
I’d want to clean up the Scriptix code a bit to be more AweMUD-style and cleanup the headers a good deal. Then just move the code over and fix up the build. Should make downloading/compiling AweMUD a lot easier, too. I might even go so far as to include a copy of the Boehm GC with AweMUD to make things even easier. Finally, with the merger, I could start using some other mini-libraries like PStrings without having to worry about bloating the build requirements any further by just folding them in.