The funniest thing about my new design here is that it is actually the most technologically-advanced setup I’ve used within Textpattern. I wrote my own Last.FM integration plugin for the banner at the top, which uses the Last.FM API to refresh the most recent artist listened to on my account.
I think TextDrive is caching my PHP calls, so it seems to update only when I do something to change the site, or possibly if a comment is posted. But, regardless, it’s working really well.
As our written word actually becomes less fluent than its accompanying conversational form, “lol” has actually become an unspoken non-utterance, akin to “um” or even the somewhat retrograde “like.”
We have even destroyed its representative acronym-ship, with what I would estimate as the vast majority of its usage accompanying events not involving laughter, especially “out loud.”
I propose two alternatives:
“haha,” which brings in the laughter motif without implying a full-out belly-laugh, especially out loud.
“CIC,” a new acronym pronounced “kick,” which stands for “chuckle in cranium.”
I’m really eating up the ability to see where a character went when they left the room. This actually illustrates what’s so great about MUD programming: you add little simple features into the system and they vastly increase the enjoyability of the game.
SigmaCon 2008 was a rip-roaring success, with likely the most memorable moment being the somewhat awkward exit from Starbucks to avoid the contact enthusiasm drummed up in a previously-unknown fellow coffee or tea drinker.
One might think such contagious enthusiasm would be reserved for conventions involving Apple product announcements, or at the least games with graphics; but nay, even in the realm of throwback text-based network role-playing we were able to garner some unsolicited opinions regarding the control of in-game economics, specifically inflation.
Such is the coffee shop atmosphere.
I would contend that our order (player classes like “Fighter”) system is fully solidified in concept, with basic combat design nearly completed. The implementation should not be too difficult or complicated, and I’m definitely looking forward to adding combat.py to the handlers module directory.
But for now it’s on to the orders and statistics system. This is much, much, much easier than I thought it would be originally.
Commenting on my own blog seems a little sad, so I’m just going to split off a new entry.
Meta did what I was hoping for, through taking the provocative stance I took: he smote down my oversimplified argument and gave me good reasons to avoid blowing off magic as simply special-case extensions of the abilities and weapon skills systems.
Complete truth be told, I have never played a magic-user as a primary character in a single game ever. I need help!
I’m enjoying the conceptual stretch of the magic and engagement system. I see a lot of my stance/balance systems only applying to melee-range combat. Engagement adds so much to game mechanic realism (avoiding the conceptual dissonance of bow & arrow usage in hand-to-hand range).
I am largely ignorant of a common, quality implementation of engagement.
Does the aggressor (i.e., the guy who types “kill X”) get to determine the initial fighting range?
What is required to adjust the combat range? Is it a roll on agility? Something else?
Is there a mechanic to switch weapons quickly, or is this handled automatically with characters permitted to equip both a range weapon and a melee weapon?
How is a knife handled versus a spear?
Is fleeing from battle handled range-by-range, or is a successful “flee” absolute and immediate?
As far as the magic goes, I think the most compelling argument is the diversity of “offensive” spells, with debuffing and buffing being viable companions to a “burn” or “freeze” type of effect. I saw the whole system being made up of various forms of burning and freezing. This would make magic a trivial gadget in the game.
I love the idea of “charging up” MP rather than some static concept of mana or some other depleting scarce resource that is slow to recharge (or never recharge). I’ve always wanted to see a combat magic system in which a total amount of “available force” is allocated across spells and enchantments, with the caster retaining the ability to withdraw one effect to replace it with another.
How practical? No experience to say.
By the way, I’m all about responsible synthesis and alchemy (have I ever seen this implemented to my liking?), so I definitely see a skill-set for this. Perhaps in the way of blending in scarce resources to produce stat bonuses on weapons, and such.
