14 December 2015

how to make a windows exe in linux with python and wine

Kat loves Mouse as Windows Linux
Since a few releases back, I've been able to pack the Windows executables of LoSt natively in Linux, with no need to dual-boot any longer. For my own reference, and to the benefit of other unhappy dual-booters who might be searching for a more sustainable solution, I figured I'd outline the steps I had to take to make this magic happen.

I'm using Wine to make the exe with Pyinstaller. In addition to these, you'll have to install some tools to Wine's folder c_drive, in particular: Python, Pywin32, setuptools, and MS Visual C++. I'm using the pygame module myself, so that had to be put on there as well. Obviously, you want to download the tools which are compatible with Windows, and with the version of Python you're using. Use wine to install everything. Depending on the file extension, use the following commands to install all the components:
wine filename.exe
wine msiexec /i filename.msi
wine python

Due to the fact that Windows isn't case sensitive, Pyinstaller may be throwing the following warning at you: "WARNING: file already exists but should not: C:\Users\<name>\AppData\Local\Temp\_MEI34922\Include\pyconfig.h" You can bypass this by editing the file, situated somewhere like: ~/.wine/drive_c/Python27/Lib/site-packages/PyInstaller-2.1-py2.7.egg/PyInstaller/ Search for the function named "append" and change the line:
if tpl[2] == "BINARY:"
if tpl[2] in ["BINARY","DATA"]:

At this point, you should be good to go. Once you've went through these steps once, whenever you need to chug out an exe, just cd to the directory where your main script is situated, and type:
wine pyinstaller --onefile

This will put the executable in a folder named dist. You can safely rename this file and delete the build folder along with all python scripts before distributing your application.

A final note: Depending on your program, you may need to make small changes to the script to make everything work. In my own case, I'm using os.chdir() to access data files, starting from a "code" directory which I conveniently delete before distributing the exe. I worked around this by adding the following line at the top of my "" script before running pyinstaller:
Happy hunting!

As always,

11 December 2015

Released: LoSt v.9 «Broken Windows»

spread the glorious news!
Version 9 is out. Links to the archives are the same as ever:
Windows (exe)
Linux (deb)
Sources (python)

This version mostly fixes some bugs and adds a few more things to do. Now you can blow up stuff with dynamite and shoot stray cats with elephant guns. Here's the changelog:
  • Bug: Game would sometimes crash when unloading gun in hand
  • Bug: Chainhook critical hits could cause a crash
  • Bug: Chainhooks could drag victims over/onto obstacles
  • Bug: Crash when actions executed without a proper target/tool
  • Bug: Spirit stone displayed false tile when carried
  • Bug: Items would sometimes be generated in water
  • Bug: Windows version warned about duplicate files
  • Bug: Holy site animals would sometimes get "prickly plant" AI
  • Props and features: Dynamite, rubble, smithereens, sledge hammer, elephant gun, sniper rifle, gun slits, windows
  • Place template: pillbox bunkers
  • Game: Inventory items can grant flags/intrinsics
  • Game: Stackable inventory items
  • Game: Simplified day/night cycle
  • Game: Carrying heavy items encumbers the player
  • Game: Demolishing house walls
  • Game: Beings can trigger actions upon destruction/death
  • Game: Worked on corpses and rubble
  • Kits: Each animal species gets a random disposition (ornery, shy, docile)
  • Kits: (Some) animal families now have set special abilities (cats sprint, dogs charge, horns penetrate, bears deal more damage, etc.)
  • UI: Placement of text log now configurable to center, top or bottom
  • UI: Status line in menu displays timer for temporary flags
  • UI: Menu displays current place and time
  • UI: File structure for prop tiles now much more orderly
  • UI: Testing out another style for prop tiles
  • System: Game now keeps a log file
  • System: Config and save files now track release version, tries to repair obsolete options 

Is it right to have left left for right?
I've also been taking the visual style in a more abstract direction. The changes do reflect my experimenting towards a vague plan I have for the visual design of the game. Frankly, it'll also be easier to add content once I don't have to hand draw/steal tiles for each new prop. I'm hoping to get some visual snazz whilst maintaining the flexibility and low maintenance of traditional Roguelike displays. Let's see where it may end. Here's a picture showing some simple examples: To the left, props as they were displayed in version 8. To the right, how I'm displaying the same objects now. Similar items use similar icons, only differently colored. So even encountering a new object, you'd be able to instantly classify it as a whip, bomb, medicine, etc.

Barring any glaring bugs, this'll probably be the last release of the year.

In any case, I'm sorry for spamming you with release notes. The next entry will surely be some piece of text pertaining to game design. I hope to turn my attention towards NPCs now, evolving the AI a bit and adding some more content and features.

As always,

1 December 2015

Released: LoSt v.8 «Still Life»

I decided to release the game in its current state, This is version 8, titled «Still Life». Hopefully, someone might have interest in trying it, just to stifle their own curiosity, and perhaps to leave a comment or two.

Get your fresh bloodshed here:
Windows executable
Python sources

(Linux users: Apologies for delayed Deb package this time. I'll put it up shortly; in the meantime, Linux and Mac users can quite easily run the game from source, by following the readme inside the archive.)

Save files are not backwards compatible. This even goes for the configuration file, so if you're reinstalling LoSt, your safest bet is just to delete your old configuration folder (named ".LoSt" and contained in your home directory).

«Still Life» is very much a pre-alpha release. Compared to the last version, which featured a dungeon and a win condition, I've rolled back to something even less reminiscent of a real game! Let's hope the one step backwards precedes a leap onwards … Highlights of «Still Life» include randomized species of plants and animals, basic overworld generation, and snazzier graphics (with configurable resolution and animation options).

There have been a lot of changes behind the scenes, which will make it easier to add more content to the game from now on. I guess the basic setting will take shape within a release or two, and hope to start working on humans in the next release. Implementing NPCs will entail getting more or the basic engine in place, including speech, trade and bounties (quests).

Comments welcome

I'd be happy for any comments, even (especially) if it's just that someone didn't get the game to work or didn't understand how to play it. At the current point, I'm curious as to how people find the interface and combat system, both of which are quite unconventional.

Ideas and requests for content and features will be given high priority, as a carrot for those interested in the further development of LoSt. At the current point, the game is a bit lacking in theme. There are not many objects to find, and practically no lore. Also, the random animal species doesn't yet yield really memorable creatures. I'm sure the animals will get some more personality once text descriptions are added, but I'll also need some inspired ideas for how to take this feature a bit further. In general, I'm looking forward to getting the setting more or less in place. So if anyone want to see telescopes implemented before lassos, or would love to play a travelling quack in the next release, make your voice heard, and I'll try to accomodate.

As always, Minotauros

6 November 2015


I think making a Roguelike is one of the best forms of procrastination imaginable. For one thing, it feels a hell of a lot more productive than playing RLs.

Meanwhile, I haven't been coding a lot on LoSt the last couple of weeks. Too busy with work and real life, which ironically turn into forms of procrastination in themselves, seen from the perspective of developing a RL game!

It's all part of the Slow Application Development methodology1. Which is to say LoSt is continuing its slow death march towards abandonment. Random animal generation is soon done, after which I might turn to random plant species, or some other part of world generation. The next release is planned as a (bare-bones) presentation of the overworld, and might theoretically come in a few weeks or months.

Anyway, I just wanted to divert your attention to my latest, awesome RL-themed procrastination project, namely: a fanfic comic about Caves of Qud. Each page represents about an hour of complete idleness, so it's not as bad as it may seem :P

As always,

1 I'll be sure to write a meaty blogpost about the S.A.D. methodology one of these days.

8 October 2015

fearsome critters

I'm working on random animal species for LoSt. I figured this is a good place to start, before adding (randomized) NPCs, which will be a lot more complex. The basic engine has been tested with a quite bland "foo beast" and a "monstrum biformis". The foo beast gets a very simple random name and shape that each member inherits, whilst each individual monstrum biformis is a unique mixture of two animal parts. I might keep these genotypes in the game, just for the hell of it, although they'll have to be refined and renamed (in particular the monstrum biformis, which I don't even know how to decline in plural).

Genotypes are distinguished at least by their morphology (including health and main attack form), habitat (how and where it's encountered), and behaviour (simple AI plug-ins like "flock mentality" and "self-preservation" apply goals and tactics), as well as special quirks (stuff like poison, spinnerets and tunneling fall under this category). Just working with these four basic parameters makes a wide range of beasts possible: Consider that if I hobbled together ten templates for each of them, the engine would support 10 000 different kinds of animals.

However, it also becomes clear that a completely random bestiary won't work. The results would too often be ridiculously unbalanced, or simply uninteresting. There must be some method to the madness, and it's worth considering which functions encounters serve in the first place.

1. They might provide a challenge to the player: Encounters which are aggressive or otherwise have to be overcome create a tension in the game. We're making a Roguelike here, so the player should always be wary of suddenly coming under attack. Even if not generated hostile, NPCs and neutral entities can provide challenges in the form of missions, puzzles and other tasks.

2. They might advance the character: The basic form of this in most Roguelikes and rpgs is killing the next guy to steal his cash or other stuff. Another classic RL trope is experience points. There'll be no xp in LoSt, nor will dumb beast go about carrying various treasures. (But there might come some survivalist mechanics that include hunting later on.) Again, neutral/friendly critters can also advance the character. Shopkeepers ("travelling saleskids" in LoSt) spring to mind, as do missions with rewards.

3. They should provide mood or story: Not least, and this goes for friendly as well as malicious critters, they should speak to the mood and setting of the game. Whether pilfering booze off a mad prospector, barely escaping a crazed bear, saving a small reptile from the claws of a feral cat, or just observing a flock of birds taking off from a far away field, the player should experience that the animals and persons s/he encounters form a greater whole, some kind of game world.

There's a lot to consider here, especially when expanding a randomized system. The first two points directly point to gameplay aspects, and must be balanced in relation to each other. But they also tie in with the third point: If a game world contains only vile predators, the engine has failed on all points – the game would probably be too hard, and in addition such a setting makes no sense (what would they eat, apart from the player?). The same goes for a world with nothing but docile prey – which might bore the player in so many ways, unless (who knows?) a freak accident transforms our Roguelike, for a single session, into some kind of pastoral simulator.

In that sense, consistency of mood and story is useful as a kind of measuring stick to get an intuitive feel for whether the game world is properly balanced. But for LoSt, it's no less important in and of itself. Frankly, I'd rather make a game with an evocative game world than one that is superbly balanced. And I certainly hope in the long run to implement some features and content that will borderline on procedurally generated literature, randomizing things like dialogue, monologue (including folk songs), monster memory, item descriptions and mission details.

Some words about the actual design: On the technical side, I have defined a bunch of critter templates and traits that can be combined to spawn actual beings (I call these data templates kits). Most of these kits describe very simple qualities, like "beaked", "small" and "avian", which combined gives the outline of some random bird. A slightly bigger bird, like a buzzard, could be specified as "medium" and attacking with an improved beak. And of course there is room for things like giant dogs with antlers and airborne mini-aligators!

What I'm doing at the moment, is bundling kits together into bigger packages and specifying templates which are more picky about which kits they choose. This enables me to steer what kinds of animals are generated, whilst still retaining a degree of randomness. For instance, the basic kit "flocking bird I" inherits subkits like "small avian template" (basic morphology, including attack and defense stats) and "flock mentality" (currently a very crude set of behaviours, just trying to approach as well as defend critters of the same species). This basic kit can be patched with further traits (specifying for instance that the species sports a special attack, or that it's a flightless fowl). Another basic template I have in place is called "royal predator I". It is always a solitary beast with good combat stats and a penchant for attacking critters tagged as "prey" (which in turn are programmed to flee anything tagged as a "predator"). Other than that, the royal predator can turn out a mammal, a reptile, or even a giant bird.

During world generation, each climate type randomly generates its encounter table by spawning a few species types. Again, the tables are weighted: A certain climate might demand to get one predator, one prey, one carrion eater, and one completely random animal. The system should be smart enough to be able to pick for instance "flocking bird I" as its carrion eater, and then patch it with the appropriate kits to make it go after corpses and eat them. I'll also have to implement filters to make sure that the same species template isn't picked over and over again. I'm considering emulating something like decks of cards – lists containing one or more references to each appropriate kit, removing referances as they are picked and used.

Be that as it may, I'm currently less concerned with balancing than just getting the engine to spit out some interesting beasts. I'm of course reviewing Borges' entry on American cryptozoology in The Book of Imaginary Beings, and trying to dig up some other sources of inspiration. One thing that is becoming clear to me, is that I need to differentiate between the different groups/families of species. Right now, there is little difference between a giant lizard and a cow, except for slightly different attack forms. Making each type more distinct will not only make the bestiary more varied, but will also strengthen the kind of learning curve that is typically associated with Roguelikes. I don't really want a game where experienced players share a standardized knowledge of "which resistances to stack up on" before engaging which critters. But it'd add some depth and predictability if certain patterns are true for every game. Maybe cats are inherently fast and reptiles inherently tough, for instance. That way, a knowledgeable player will be prepared to draw some information just from seeing a critter for the first time, and yet not be sure what to expect from every new playthrough. A world full of raging bulls will probably require different tactics to handle than one stalked by man-eating lizards. And the mark of an experienced player would be that s/he's able to deduce facts about the generated world, and react accordingly.

As the bestiary starts falling into place, I'll be picking up my old plant life generator and migrate it from python sources into files containing kit definitions. At which point we're looking at an upcoming release to see if I can harvest some comments on the basic workings of the biotope generator. Never mind if it's going to be badly balanced and utterly crazy – there will be due time to reflect and refine later on.

As always,

28 September 2015

measurements of the known world

I want the setting to be highly random every time you play. Questlines, species of animals and plants, important places, they should all be procedurally generated – at least to a certain extent.  It's impossible not to work with some templates. Say you want random places – you have to stop the randomness at some point and set fixed parameters. If I want settlements to crop up in the game, it's not going to happen unless I make some blueprints with blanks to fill in, and a balanced "world blueprint" to put at least a few villages in addition to other places of interest. The same goes for animals: I can't just blindly generate a bunch of random species and put them on the map. There must be a balance of predators, prey, pets, and atmospheric population of The Land.

Every now and then, some fresh developer announces that he (mostly guys do this, yeh :P) is writing a RL where a totally unique world and plot will be generated each time. Content like trade, reputation and other intelligent behaviour will supposedly just procedurally occur from the sublimely wrought code that binds it all together. I think what we (counting myself amongst this throng of vapourware developers) fail to realize, is this basic principle, that you have to actually implement all the content that goes in the game. Sure, you can patch it together so that interesting combinations will occur procedurally, but there is a reason why so few RLs (if any?) exist that really take this to the next level. A conventional truth is that procedural generation can be used to alleviate manual labour by pregenerating stuff like landscapes, that would otherwise have to be coded by someone. This may be true for genres like FPSs and development models used in big business, but in RL development, the opposite seems to be true: Rather than handcrafting less content than the player is going to see in any one game, you'll end up having to make more, by orders of magnitude.

If there is something like a story in any given RL game, I think it's the setting. Exploration of the game's universe doesn't happen linearly, but rather fractured up by features like permadeath and randomness. I actually believe this to be a key to random stories in RL games: Granted, you'll find yourself implementing stuff like procedural dialogue and questlines, but the actual sense of the work will be in something perhaps much less grand: just the kind of random stories that have always been extolled on RL forums. So much for holy grails and silver bullets.

As I stated, I want the map to be randomly generated, but I'm not aiming for a huge world. My current testing version generates a landscape encircling a diameter of about 400 hexes, surrounded by endless desert. Rather than each playthrough taking place on an entirely different planet, I'm envisioning different regions in one and the same world. For one thing, it'll make a lot more sense if later I implement ghosts, or even the option for retired characters to show up as NPCs in later games. It also means I can write quite specific lore to reflect a single world/culture, and possibly conceive of one or more overarching plots, possibly even win conditions. (And yet, why bother with win conditions; doesn't an unwinnable game world highlight the very strengths of the RL genre?)

I will of course allow myself to vary parameters in the setting if I think it can be used to advance gameplay or the story itself. The Land is situated on the frontier of a continent loosely based on historic America, during a period of colonization by settlers and officials of «the old world». One could randomize the ruling form of the old world, for instance: Is it an empire or monarchy, or a federation or a group of rivaling states? That might not be worth the effort, actually. But it might be interesting if for instance the religious fractions were partly randomized. In one game priests and mystics hailing to the prevalent religion(s) might be wandering monks and nuns, in another they could set up temples in villages or near natural sources and holy sites. And I've been thinking about having the old world represented by a random currency in each game.

Old world money, however, would probably just function as trade goods. The popular currency used in The Land is always lead bullets. Slugs function as coins as well as ammunition, so in The Land, the saying that one person's life is worth one bullet, is no metaphor; it's the actual rate. It's a harsh land. Slavery may be more or less predominant in different playthroughs, but it will always be an issue
in the game world. But I guess there may be some sort of hope. Should I flesh out the theme of slavery into a main plotline, one conflict would surely have to be the fight for the abolishment of slavery! The law is still fluent in The Land, dictated by the varying influences of various power fractions. Fractions might include commercial companies and military forces from the old world, opposed to forces for political independence, ranging from semi-autonomous settlements to secret societies, but also powerbases ambiguous to this dichotomy, like the church or different sects/cults, local commercial interests and gangsters fighting it out between themselves while simultaneously trying to stave off the man, who wants all of their heads on a platter.

Some fractions might be pure berserker types when faced with the players, such as desperadoes, highwaymen, and parts of the natural world. For now, I have more than my hands full just getting all systems to work and writing the bare bones of a weird western setting, but naturally I would love to add an indigenous culture, with its own bases of power and playable careers. In the current public version, there is already the skeleton of a career system, starting the player out with a random career out of many. I'll soon pick and flesh out a few careers, and then add more as I go along. Careers might represent power fractions in themselves, and I hope to use them as stepping stones to describe the setting. I'm pretty sure The Land will feature lots of conspiracies, so it might make sense to have some of the careers represent something akin to guilds or networks. There may be a fellowship of the railway station masters, or a code of conduct taken by certain gunslingers and avengers, etc. The career you choose at the beginning of the game will represent your background, so it should be fully possible to start out as a lyncher, but then pursue the skills and ethos of a witch hunter or an agitator. Starting careers should open up something like a skill tree, however, and maybe possible starting missions. As development progresses, specialized skills can be assigned to specialized careers, in addition to being learnable in the game.

At the moment, I'm debugging and finalizing the basic world building engine, whilst simultaneously using it as an opportunity to add some content. For instance, I've been having some trouble with places/encounters containing subencounters (say, a pampas, containing a house, containing a critter). To test and tweak, what better way than writing up a few places that use this exact mechanism. The next release seems to be in sight. And if you think I've been ranting my way through this blog post, you should probably have stopped reading a long time ago.

As always,

20 September 2015

Shaping up

I've been hacking away some at LoSt (even if I borrowed my motto from Beckett's early prose piece The End: «I did not work every day.») – adding more infrastructure for loading and randomizing content, as well as a basic landscape/climate generator and encounter system (if still pretty crude, it'll do for our testing purposes).

This means I'm facing a period of adding some content, which is always fun. Especially as most of the game is generated from data files now, meaning I'll be able to quickly add and test different kinds of items and critters/people with particular behaviors.

I'm recycling a lot from abandoned projects, so I can move quickly enough, even if «I did not work every day».

I reckon the next release will feature a wasteland with some houses and human encounters, as well as plants and animals (randomly generated species, of course).

Speech and experience/time are probably next on the todo list, after which I'll be able to concentrate more and more on adding content.

Compared to coding, adding content is easier from a technical point of view, but it can be much harder to design and balance. (Not to mention that I'm still ironing out system basics like whether or not to use explicit facing).

As always,

17 June 2015

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
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
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!

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,

19 March 2015

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.