the joy of rotozoom()

A quick update: I've been working on a new routine to display tiles, with support for animated sprites. Instead of the epitomal @, you are a pair of footprints wanderig around. There are some dogs pawing about, as well, and the system currently supports critters up to 4 hexes big (mounts and pachyderms, I reckon). Further down the road, I'm opting for some kind of speech system with speech bubbles, and probably typographic sound effects (comic book onomatopoeia like "clank" and "boom").

All animations can be switched off in the configuration menu, of course. Even then, I've a nice system where you can switch between resolution levels (and, theoretically, tile sets) at a whim, to support both small and big screens. All very much thanks to pygame's smoothscale() and rotozoom() functions.

The next release is probably going to be all about a desert biotope, with pseudo-random species of animals and plants. I've been moving a lot of the content over in data files, to make it easier to add new stuff. The very template-like desert dog that's currently in the game, is contained in the following lines in the data files:

cri small dog # "cri" means "critter", as in "define new critter"
inherit "critter" # get some basic stats
nom ["a","big chihuahua","chihuahuas",""]
max_health (2,1)
tags ["animal"]
causes ['self-preservation','zombi moves'] # define behavious
hands "bite" # natural attack
size 2 # two hexes big
tile ((2,2),(2,2),(2,2),(2,2)) # refers to four (identical) paw sprites
end # end entry for critter "small dog"

# the following three entries make up a very simple "reptile brain" AI plugin:
cause self-preservation # "cause" = preferences/ethos of being
bias [(('harm',0,0,'self',0),('aggravate','agent'))] # hate attackers
states['relaxing'] ["zombi wander"] # when relaxing, just walk randomly
states['attacking'] ['zombi attack'] # need to be able to fight
end
state zombi wander # the "relaxing" state of the critter
actions [(30,("relaxing",0),("finish",0))] # 30% find other pastime
actions [(10,("wait",0),("finish",0))] # 10% stand still
actions [(100,("wander",0),("finish",0))] # 100% walk randomly
bias [((0,'foe',0,0,0),('attacking','agent'))] # attack foes on sight
end
state zombi attack # attacking state
actions [(100,("is_dead","q"),("return",0))] # if quarry q is dead, exit state
actions [(100,('ally','q'),('return',0))] # is q is an ally, exit state
actions [(1,('nil',0),('return',0))] # 1% P of randomly exiting state
actions [(40 ,('approach','q'),('finish',0))] # 40% try to approach quarry
actions [(100,('attack','q'),('finish',0))] # 100% try to attack quarry
actions [(100,('approach','q'),('finish',0)), (100,('wander',0),('finish',0)) # backup strategy: charge!
end

As you can see from such snippets, I'm not aiming for this to be expandable by anyone except me ;) but there is support for "modules" in the game, so you can theoretically mix and match packages of content. In the long run, one could release expansion packs, maybe stuff like a "steampunk mod" or an "undead apocalypse mod", for people who are into that kind of weird west, and the players could choose to include or exclude the various modules at their leisure (I would love a "postapocalypitic cowgirls/Burroughs/Genet queerporn mod", mesself).

Dreaming about long term goals such as this, is of course a very important part of RL development. I think I'll celebrate the next release with a meatier blog post detailing my sterling Slow Application Development (SAD) Method. In the meantime, interested parties can get your snapshot release here (python sources).

The next big thing to do, is to systemize how random elements are picked, so that I can start adding more content; the encounter tables, so to speak. I'm going to use the kind of rhizomatic data entries examplified above, but they need lines beginning with something like "frequency". There needs to be a module or object to make sense of cases like how, if an oasis appears in the desert, it might possibly contain the tent of a travelling salesboy (but probably not a nest of poison ugguks, which you'd be more likely to encounter underground), and in that tent (possibly) of box of posessions, amongst which (possibly) a handgun which (possibly) only holds four bullets, but scores deadly shots with a 1/6 accuracy (just possibly).

The devil, of course, is in the details, that is to say the content. The anatomy of a critical hit, and of the revolver itself, not to mention the salesboy and his tent, the oasis, the desert … With small steps I might be able to slowly populate the current waste land and build a world of biotopes subtle and sprawling, struggling centres of civilization, and a gruesome, mysterious subterranea.

By the way, rescaling the sprites can also be used to get a nifty overview map, although it would be risky to navigate around that, once I get some dangerous encounters up and going in the desert. On the long todo-list is a "travel mode" which zooms out to a larger map view. But here and now, it's more pressing to fix various issues with map generation, some of which become apparent from this very screenshot.

As always,
Minotauros

On the fence

How time flies when development is at a standstill. LoSt can be said to be en route, though; in concordance with the Slow Application Development (SAD) methodology that "we" (that is to say, I) have proudly developed in-house, I'm zealously adhering to the doctrine of "release sometime, release sometimes".

Being busy with other things still leaves me headroom to ponder some issues I'll be tackling in LoSt (this being quite possibly the only redeeming quality of the SAD methodology). I'm not so far away from having most basic functionalities in place, but I still need to make some big decisions. For instance, I'm still on the fence regarding whether I should keep content in data files or put them straight in the source code. In my single big computer game project so far (Squirm RL) I kept "everything" in data files, and I loved how easy it was to add new effects, items, quests, and monsters. On the flip side, I had to stay within the boundaries of the "natural laws" that ruled the game world, and whenever I needed to step outside of these boundaries, I had to mess around with the parser itself, as well as dive into stuff like the main loop and basic event handling. (Let's hope this is the last time I squeeze in a Squirm postmortem on this blog)

For LoSt, it might have been a good idea to use a scripting language. But since I'm writing the darn thing in Python, anyway, that would basically amount to bundling content in with the source code. I think that may be the way to go, just to get maximum flexibility. For instance, I'm planning to have most animal species randomly generated for each world seed. It'll probably be easier to balance and maintain such a fluctuating bestiary as a separate module, rather than implementing a half-assed "catch-all" data syntax.

I already did some work on this, quite early in the process, and came up with a simple plant generator, which spits out basic info on six species of plants, balanced against each other so you won't get a  world with only poisonous plants, or no flora except grasses. A sample run gives something this result:

Bluebread (a small bush, bearing fruit, with a poisonous stem, and capable of walking by uprooting itself), nodding olive (a huge cactus, labeled a tree, with branches that can be used to make rope), sugarelder lilac (a tree with medicinal roots and flowers containing an antidote to poison), bane-grass lily (a toxic grass, however with edible flowers, and roots that can be made into rope), medusapod needle (a flowering grass tagged as "hexweed" and "species delicacy"), and crow's nest foxbrush (a big bush with medicinal berries, and which also is capable of walking).

It'll take some work of the imagination to expand this simple mock-up to include a whole biotope. I'll probably have the generator start out with some kind of "template ecology" where the blanks are filled in, to make sure of stuff like at least having some plants and herbivores at the bottom of the food chain, but more importantly to enforce such as affects gameplay: For instance, there should always be some ferocious animals for the player to fear, but not too many of them; and I certainly want horses or some kind of equestrian beast to appear in every world; and depending on how the game ends up balanced, I need to make sure that resources like food and medicine are distributed in appropriate quantities.

I imagine it a bit like laying out the cards in a fixed pattern for a game of solitaire, or when consulting the Tarot. Except the cards themselves may contain new blank slots, to be filled with yet new cards drawn from the deck. Thus, a "card" containing the template for a small predator will contain some basic stats, but also ask the engine for more "cards" to flesh out the details: whether it's a mammal or a reptile, how it lives and hunts, as well as more unique traits (eg. particularly fast or strong, or poisonous, or easy/hard to tame as a pet).

This, again, raises the question of how to draw random elements when constructing and populating the game world. I may hold on to the "deck of cards"-analogy, making each alternative less likely to show up twice in a row. That would make it easier to restrict for example the probability of every single species in a world being poisonous (although even that may be left at least theoretically possible). And a "deck of cards", periodically reshuffled, may be a better way to assure balanced random drops over time, than simply rolling a die and consulting a table of results.

At the moment, I'm happy enough to ponder this a bit more before getting back in the thick of coding.

In related news, I'm about to send off a pile of stuff for work, which might mean I'll manage to make space for some LoSt development in the next months – although I may have to scramble for a new big project, to accumulate the resources I need for that long-awaited frontal attack on the evergrowing stack of bills.

Thinking Out Loud

Development of LoSt is seeing another burst of activity, be it long or short. On the top of my old todo list was to get a decent "AI" (or, call it, action determination system) up and going for NPCs and enemies, so that's where I'm at now.

A golden rule to keep in mind when developing NPC/critter behavior is that the actors need to be "thinking out loud" to a certain extent. It's easy for a developer to fall in love with a system where there's a lot of hidden stuff going on, stuff the player simply won't notice. In many situations, simple hacks are better than complex algorithms. Making changes in the code will also have more predictable results if you're using simple rules (a fixed probability to flee/fight as opposed to a function that takes into consideration factors like relative health and strength of the opponent).

Truly believable characters may come off as bland; a fictional person is much more easy to make memorable if defined by traits underlined to an almost absurd degree (consider the monomaniac ramblings of Captain Abab or The Red Queen in Alice; the archetypical nice naughtiness of someone like Little My (in the Moonmin books) or Pippi Longstockings; the sincere stupidity of Sancho Panza. Examples that might hit closer to home include the conspicuous inclination of pixies/leprechauns in traditional Rogue-games, or how that pesky puppy in ADOM ceaselessly gets into fights with ogres and worse).

I'm basing my "AI" system of how I did it in my abandoned Roguelike Squirm. Each actor is always in a certain state, which dictates the actor's behavior (eg. "hungry-at-home" state: if there is food on the table, eat it, else go to "cook-and-put-food-on-table" state). The personality of any actor is really contained in the sum of states that actor is capable of being in, as well as (what I call) the "bias switches" used to switch the state of the actor, depending on what it observes on the map. It is a quite flexible system for tactical behavior (switching between different attacking/defending states, so that some goon might keep her distance, seeking cover and firing a gun, maybe turning to run if she gets hit herself, whilst man-eating big-dogs might hunt in packs, aiming to surround their victim and go for the throat) as well as functional or even choreographic (going to the doctor if you've been shot in the leg; frequenting the railway station to proclaim the villainies of villains and handing out cash bounties to said villains' vanquishers; heading to the saloon with a loaded gun to settle all your debts once and for all).

The whole thing borrows heavily from Bear's Roguelike Intelligence articles on Roguebasin. Andrew Doull's essays about developing Unangband was also a huge inspiration back at the time I was developing Squirm.

Right now I'm just testing it with a desert stray dog, quite ineptly identified by the game as "a dog, holding teeth". It starts out in a "wander" state, which just loops endlessly, with the dog always walking in a random direction. Its sole cause in this world is self-preservation: if someone (presumably the player, being the only other living thing in this infinite desert) inflicts damage upon it, it fights to the death.

I might test this further with some more desert life (I have a prototype for randomly generated plant species lying around), but I'll soon be delving back into the lead mines to develop the slave break scenario a bit more. It's a pretty fruitful scenario to use for early development. It involves some fighting, possible even between two groups (slaves and owners, if it turns into a real uprising), which is good to get a lot of technicalities in place. There will also definitely be some talking, and I hope to develop at least the slave community as an interesting part of the setting/theme, with their own rumors and rituals, staying pretty small while hinting at larger issues.

As always,
Minotauros

The Story So Far

A while ago, I started to tinker with a computer game named Land of Strangers. The game is a Roguelike set in a fantasy world inspired by various fictions about cowboys and cowgirls. It's still in the very early phases of development, but can already by downloaded (as a Windows executable, a software package for Debian/Ubuntu Linux, or as source code (written in python)).

Louise Ortiz, travelling salesgirl, soon to be dead (screenshot from LoSt v. 7)

This blog was established to write about LoSt (although I might make the odd excursion into stray topics, I'll try to stay on the case). For the sake of archival completeness, here is a final link, to a forum thread which I've been using to rant about LoSt: http://forums.roguetemple.com/index.php?topic=3221.0

The summer is going to be awfully quiet, but I'm guessing we can expect a new release early next fall. It will focus on making the supporting cast a little smarter.

As always,
Minotauros