new revision control system

So the majority of my attention today was devoted to moving from using subversion as my revision control system, to instead using git. I’ve used git a few times before in the past, for other projects, so I had a fair idea what I wanted to do, but nevertheless git has some disfunctionalities that took me a little while to remember how to work around.

Some decisions were made by the developers of git (and I’m sure for very good reasons) that make it difficult to commit changes from one repository to another, in the traditional sense. In a certain fashion, it makes sense. Git is designed for a large web of developers to be able to work on their local repositories, and then when their code hits a certain level of maturity, other devs can pull those changes into their own repositories. And indeed, git works exceptionally well for this. Unfortunately it just makes for an extra pain in the ass when you, personally, have two systems and you do your work on one and you want your changes to appear on the other. If firewalls and NATs didn’t exist it wouldn’t be a problem, but they do. And my “development” system resides behind a firewall and doesn’t allow incoming ssh, while my server does allow it. Anyways, gist of it is, it took me awhile to remember how to make ‘git push’ work in the fashion in which you’d expect.

With that done, I set about modernizing the build chain. In the past all the building was done with a very primitive, hand-written Makefile. It did the job just fine, but I wanted to at least put a proper build chain in place, should I ever decide to share the code with anyone (someone signs on as a co-dev, etc).

That about sums up my efforts of the last day or two. There’ve been quite a few minor adjustments to the code, but nothing drastic. My SSH library, libmoosshsrv, has taken a few steps closer to being publicly releasable. I’m still not confident enough that it’s crypto-secure to pull the trigger on that yet, but it at least implements everything the RFC states is required, and most of the things that are recommended. However, the more I’ve thought about it, the more I think the library would actually be much less useful for other devs than most people seem to think. Conventional single-player roguelikes are served quite well by having a set-up similar to crawl.akrasiac.org, where you log in with some public credentials (joshua/joshua, if you like movie references), and your login shell is set to be the roguelike executable. The only systems that would gain any significant amount of benefit from libmoosshsrv would likely be multi-player roguelikes, or perhaps single-player roguelikes with interactions between games. There don’t seem to be very many of those projects around.

at long last, a proper enchantment system

In keeping with my efforts to take prior hacked-together, code-ugly mechanics and revamp or replace them with proper, flexible, extensible systems (such as the scroll->spell magic system transition), I took the time yesterday to replace the existing mechanics for item magical enchantments/resistances, and replace it. I also went through and did something that I’ve been wanting to do for awhile, which was to make it so items stashed in a shop are invisible to everyone except the person who stashed them.

The New Enchantment System

Previously, items were given exactly one magical enchantment (or resistance, in the case of armor). For an enchantment, the amount of enchantment damage granted by the item was fixed by the type of damage it was. Striking was 4 points of damage, Ice and Fire were 6, Lightning 8, Poison 10. Resistances were more flexible, as armor could give resistance to a particular type of magic in 10% increments. It was also implemented in a very ugly fashion behind-the-scenes, overloading item fields that were used for other things in different item types. It was horrible to work with. So, I’ve replaced it with a system whereby any item can have up to 4 enchantments, each with a different type and amount. Similarly, any item can have up to 4 resistances as well.

rebalancing and re-architecting

Not much of interest to players has transpired recently, but nonetheless I’ve been quite busy with the code. The big thing that’s happened lately is restructuring the way monster groups are handled on the back end. As I mentioned recently, there’s now an AI Director inside twilight that handles spawning pseudo-random groups of monsters in appropriate places. I said at the time that I wanted to get the conventional monster groups integrated into this framework, since it provides some pretty significant resource-savings by only having the monsters spawned when there’s actually a player nearby. Today I did this. I also integrated an Analysis module into the codebase to allow me to visually verify power curves and balancing.

libmoosshsrv

Christmas-Eve and Christmas are both wonderful days, because once you’ve got all the traditions out of the way, you’re presented with an opportunity to lock yourself away and code without interruption, under the guise of playing with your new toys. Or something like that.

Anyways, between yesterday and today I sat down and rewrote much of my SSH server code. It’s now much more standards-compliant, and overall robust. I’m not sure it’s to a point where I’m ready to release it yet, but it’s getting there, so the hope is that in not-too-long I’ll be able to release a free ssh server library that roguelike devs can just plug into their roguelikes fairly easily. There are some unsettling things about this that are probably largely uninteresting, but it is worth noting that my biggest hesitation is not wanting to introduce an insecure SSH library that foolhardy devs will use for things that really do need the extra security that stronger cryptography can provide.

As an unfortunate consequence of all the mucking about I did in the code, things got munged up to a point where the OpenSSL DSA code would segfault while trying to sign the SSH packet HMACs with the existing twilight DSS signature. For whatever reason, just letting it generate a new signature resolved that. I don’t understand it, it shouldn’t happen, but I also spent hours debugging it from several angles and consistently found that it was a problem in OpenSSL that I couldn’t really control. The upshot of all this is that the signature has changed and your SSH client is going to bitch, whine, moan, and perhaps refuse to connect unless you purge the old signature out of its cache. Sorry.

Once I’ve done a few last code audits to ensure that I’m confident that libmoosshsrv is RFC-compliant, I’ll probably throw the tarball together, write up some quick documentation, and release it.

magic gets the treatment

So between yesterday and today I found/made the time to go in and hammer most of the utility spells that wizards and necromancers have into the new “skill” system. This means that no longer do wizards have to farm up healing/ice scrolls, and necromancers don’t have to get their fire/lightning scrolls. Instead, they buy these spells from the Priest of Caladan and the Tutor of Aether in the first town, near the Master Swordsman where warriors buy their skills. This is very beneficial from the perspective of giving quick access to spells, and also provides me with a way to get rid of the nasty scroll-gathering process. I took some liberties transitioning the magics from scrolls into spells, so there might be some balance changes, but I think I’ll get all that sorted out in time.

Thoughts for the Future

Next on the agenda will be making prestige-class skills be a bonus skill on top of your normal skills. I also need to expand the spell selection a little bit. Right now there isn’t any spell representative of Striking anymore. This should be a really positive move for magic though, and I’m glad I finally made the time to do it.

All this being said, I’ve had a nasty hunch all throughout the process of hammering magic into the skill system that I was forgetting some little caveat, so don’t be surprised if things are a little buggy for awhile.

when I get bored things happen

I got really really bored yesterday and today, so I finally sat down and figured out how I wanted to incorporate more interactivity into warrior combat. And after I did that, I coded it all up. So now you can talk to a Master Swordsman in the very first town you spawn in, and if you hand him enough money he’ll teach you various skills that you can use in combat. You use skills in a way that’s sort of similar to World of Warcraft. You’ve got 4 skill slots that you can fill with skills, and then you select your active skill with a hotkey. The next time you attack, that skill gets triggered and has its effect, then it has a “recharge” span of time. While it’s recharging you can hit one of your other skill hotkeys to change your active skill.

Right now there aren’t all that many skills (9 different skills with 5 tiers of each), but I want to get a basis for how valuable/powerful skills should be before I get all crazy-creative. They do make combat more interesting, for sure, and it gives you a couple of different ways to play the game. If you’re really hardcore then you manage your movement, and your active skills. This takes a lot of concentration and precision, so it’s kinda tough to do. If you’re not that hardcore you can just turn auto-attack on and only manage your skills. I anticipate that this is how most people will play the game, and it’s a lot more approachable. I suppose you could also just set your active skill before battle and then only control your movement, but that doesn’t seem either as fun or as effective as either of the other two approaches.

One really important thing that I want to stress is that for awhile now, you’ve had the ability to edit and change your keybinds. I don’t think this is advertised well enough in-game, but it’s really helpful to be able to put your hotkeys where you like them, especially for skills. I really hate where the scroll hotkeys are, since so many terminal emulators don’t handle the F-keys very well. Unfortunately it’s hard to come up with a dozen sensible hotkeys elsewhere on the keyboard. Perhaps a 3 key system (prev, next, activate) would work, but I’m not sure.

On the note of stuff in the game that isn’t advertised, I’m really feeling like I need to put everything I know about the game down in some sort of comprehensive wiki, cuz I feel a lot like many of the features in the game aren’t easily-accessible. For example, the PvE, PvP, and “campaign” dungeons probably don’t get much traffic, just because people don’t stumble across them enough.

In addition to the skill stuff, I noticed that some class/prestigeclass combinations didn’t make sense, such as a warrior who’s a firemage. That’s just silly. So I went back and restricted certain prestigeclasses to certain base classes. Right now the only prestige class that everyone can be is Summoner.

it’s up now

So, as promised, I’ve sorted out the bugs in the new code, and have committed it to the public server. I’m not sure it’s quite dynamic enough yet, I may need to up the number of roving bands of nomads and the races that can be nomadic and that stuff. The static groups that stay where they’re spawned are pretty cool though, even if not always placed the best. One of the really neat things about this new feature, from the code side, is that I went through the trouble it took to get the groups to be dynamically managed. That means, when no player is within reasonable distance of them, all the monsters belonging to them get slain, and then they get spawned in when players get close. So I can have pretty much as many groups as I want, and they aren’t a resource drain, cuz they only exist when they’re actually doing interesting stuff. It’s tempting to try re-structuring the old-style (hand-created) monster groups into being dynamically managed too, but I don’t think it’s important enough to devote the time to right now.

As a small bonus on top of this, I also added a little feature by adding the concept of racial foes to the race definitions. It doesn’t really change much in the game, but if AIs see each other and are “foe” races (an angel and a demon, for instance), they will fight each other, even though they’re both “monsters.”  About the only time you’ll ever see this is if a couple migrating groups of monsters that are foes happen to cross paths, but if a player happens to see it, they should appreciate it I think.

improved dynamics

It should surprise no-one that I’ve been extremely busy with work and school lately, but nevertheless, I have not forgotten about Twilight. I was daydreaming at work during a slow day, and for some reason Left 4 Dead and Twilight crossed my mind at about the same time. I’ve never played L4D, but I’ve heard/read something to the effect that the designers wanted the game to function as a sort of director, in an action movie, where the players are the stars, or some such. Once that occurred to me, some old comments that some #rgrd-ian had made bubbled back into my memory. That particular individual was waxing eloquent about wanting full dynamic ecosystems in their roguelike, or something like that.

To my mind, that’s just silly. Go play DF. However, it did occur to me that I could have an AI analyze the game world, pick out particularly suitable locations for inhabitations of particular race types (based on what sort of terrain those races like), and automagically spawn a group of monsters there. It could even have these groups of monsters migrate from one suitable location to another. So I wrote an AI that does exactly that. It’s not quite as polished and fancy as I originally envisioned, but it certainly adds to the randomness of encounters with monsters (in race, level, and location). As an outgrowth of this, I don’t have to spend all my time adding meaningless monster groups to the map. I can just make the map, add the meaningful (for story purposes or atmosphere or whatever) monster groups, and let the AI worry about the rest.

I haven’t updated the public TwilightMMORL server yet, both because I’m having some issues with my host, and also because I’m not 100% convinced the code is stable yet. However, at some point in the not-very-distant future, it will be updated, and I think things will become a lot more dynamic and interesting all around.

Better chat

I still exist! School and other projects have kept me busy, but I do still think about twilight from time to time. Today I was surprised to find someone else online at the same time as I was, when I went in to putz around a bit. The result of that was that I finally put the modicum of effort it required into improving the chat screen. It handles really long messages now, it has timestamps, and is all around better. Doesn’t sound like much I suppose, but it’s certainly an improvement.
I also (in days long past) implemented the handicapping feature I mused about previously. It works best when you’re dealing with stuff within 50% of your level, because of the way damage scales. You take proportionally more damage according to your handicap, which means if you severely handicap yourself, you can start taking 60+ damage, which takes you through the warning levels rather quickly. Should make it easier to play with friends though, and also to replay instances.

Thoughts for the Future

Remain mostly the same as last time. More/better magic, and maybe some stuff similar to how Powers work in D&D 4th edition, to make combat less button-mashy.

keybinds, AI fanciness, and a bugfix or two

So yesterday Gaeel took it upon himself to drop into #twilightmmorl on QuakeNet and mention a few improvements to me. Specifically, he asked for configurable key bindings (because he uses an azerty keyboard), and an AI that fans out to attack rather than stacking up in a huge line. So I thought these were both great ideas, and implemented them.

The keybinding thing is something I’d thought about several times before and just didn’t care enough at the time to do, but I figured that since I had nothing better to do, I’d add it. It took a small amount of work, but now you can rebind most of the game commands. Unfortunately, you can’t use every key. Special keys like the arrow keys or function keys, etc, have multi-byte keycodes, so they’re not well-suited for being bound to, the way I’m currently doing things. I don’t see that as a large problem though.

As far as tweaking the AI goes, I just made it do something similar to when they AI finds a world feature in the way: it just picks a random direction to move in. This only kicks in for monsters with xlvl >= 30, but it’s a good idea, and makes the AI look a small amount less stupid. On the other hand, it makes the later-game fights a bit more challenging for the sloppy, but I don’t think it skews things too badly.

Thoughts for the Future

Ideas for the future include (as always) more instance dungeons, and also a way to voluntarily handicap yourself such that your level 60 character can be somewhat challenged by level 20 monsters. This would allow people to play with their fully-leveled characters, but assist their friends who may not have leveled as far. Since teamwork is what makes twilight the most fun, this would have a positive effect I think.