2 April 2018

March is the coolest month

(At least it's been pretty friggin' cold up here.) March has also been a rather slow month for LoSt. I'm chugging away at the short term todo list, and have been sinking some hours into a system for passing time and learning from your experience. I'm not too concerned about balancing character development or making any final decisions at the moment, just getting a prototype for the kind of system I have been envisioning.

The system merges current skills and perks into one pool of special abilities (shticks), mostly for simplicity's sake. I have to make some small changes to character creation to reflect this. Once that's in place, I should have all features that are necessary for the planned #12 release. I anticipate April to bring bug squashing as well as authoring content, to make use of the various additions since the last release.

3 March 2018

Making time

Last month, I wrote about reimplementing wounds, and some of the changes that prompted. This month, I've mainly been working on time systems.

Sometimes, incremental changes to a project come in a surprising order, at least to an inexperienced developer like me. For instance: LoSt is designed with a simple interface in mind, and has no separate commands to use objects in different ways, like so many genre classics, with their mappings for "q"uaffing and "z"apping and whatnot (and to be fair – these interfaces are difficult to learn, but quite snappy once you do). LoSt's interface, instead, requires you to always wield an item before you can use it. Problems arose with props like cigars and syringes (consumables, really like those "q"uaffables and "z"appables of yore). The fact that they couldn't be used directly from the backpack meant it took too long to use them to be worth it in most situations.

I try to circumvent the problem by making inventory handling not taking any time. This change ups the tempo and gives the player more options, so I'm generally happy about it. It does change the value of some skills and props, like pistolknives (whose main selling point was that they could be used for melee or ranged combat). One scummy tactic that became apparent with the new system, was to keep a stack of loaded guns in your pack and fire them in succession, to save the time of cocking between each shot. So be it. To penalize the behavior, I instead added the rule that moving a cocked gun around in your inventory has a small chance of the gun going off. I don't know how realistic this is in terms of gun engineering (as a European pacifist, my personal relation to guns is limited ;) Should it be grossly inaccurate, I guess my last defense would be that LoSt plays out in a fantasy world, where many small things are different, so there, and in any case, nothing is funnier than shooting yourself in the foot, and I do think the system retains the sense of the basic motif: the rhythm of drawing, cocking, and firing a gun.

On the topic of short time spans: One thing that has baffled some players of LoSt, is the turn order. One reason is undoubtedly that a bug caused the system to behave weirdly, which I've finally gotten around to fix. But the system itself is a bit unusual for a crpg, and not really well documented. I'm taking steps to fix this, to make it easier to understand what's going on. If I can solicit some feedback for the next release, I'll hopefully manage to finalize the rules for combat some time soon-ish ;)

Rest for the wicked

One important feature that's missing in #11, is healing. This month, I've been implementing the bare bones, by adding the option to rest for a prolonged time and going back to full health, so it's now officially in. At the time of writing, the local saloon is the only resting hub, but other options will come later. Before that, I'm facing a chunk of work just to get the basic mechanics in place.

In addition to healing, the passage of time is planned to include systems for advancing the player character, as well as story lines/world events. The basic idea is to make resting a big deal, something that affects strategy. You currently pay for healing by paying rent for your room, but I'd like to further underline the importance of time by letting (potentially) "something happen" when the player rests. The nature of the changes imposed on the game world should reflect the player's recent behavior. Character development will include modifying reputation and the opportunity to gain new shticks. Furthering the "world story" will, I think, pertain mostly to world factions and bounties/quests (this last bit not planned for #12, so I honestly try to disregard it for the time being).

Modifying reputation: The engine already has a pretty detailed conduct tracker. For instance, if you massacred everyone at the saloon, you will have a lot of hostile karma in relation to the villagers. I think I might just try to take this data and generate reputation procedurally. If I manage to do it right, it should be more flexible and unpredictable than simply stating, "doing X modifies your standing with faction Y by N points". Although there should be systems for such corner cases, as well. The "proto-bounty" I'm working on now, which involves capturing a specific, named criminal, is a good example and a testing ground for this. Resolving the conflict by collecting the bounty on said criminal's head in Arken, flags the player with a special achievement, which amongst other things should be weighed extra when reputation is calculated between missions. In short, I must start out with a simple and open ended system, that I can expand on later.

Getting shticks: My current vision of how this should be implemented, involves quite a bit of foot work, and I'm still not sure if it's going to be any good. I hope to get in a kind of prototype for the next release. What I'm envisioning is basically for the engine to pick three options for the player and let them choose one. But I had an idea to make the interface less gamey by presenting the options as flavor text. Instead of: "You rest at the saloon for two weeks. 1) Get pistol shtick, 2) Get science shtick, 3) Increase local reputation", it could say something like: "You spend two weeks recovering from your wounds at the saloon in Arken Town. You eat a lot of soup, but at the end of the stay, you start to get back on your feet. 1) Go target practicing in the wilds, 2) Read a book, 3) Hang out with the locals" The place you're resting, and special NPCs stationed as the player's neighbors, should affect the available options, as well as the pseudo-randomized outcome of choosing each option. The end-result as I'm envisioning it, would be a bit like choose-your-own-adventure books, where the outcome is not given. So you won't get to cherry pick the shtick you want, but are allowed to nudge the system. If you opt to practice gunmanship, you might get a random pistoleering shtick, or a reputation bonus related to guns, or if you've used a particular pistol a lot on your latest mission, that particular gun may turn into an "artifact" with a random prefix. Likewise, "spending time with the locals" could have many outcomes, from a simple reputation boost, to learning certain rumors/plot hooks for new quests, or maybe your plan backfires and the villagers end up lynching you (especially if their bias towards you is negative in the first place, of course). It's a system that certainly has its hurdles and slopes, but I believe it has potential.

Story advancement: As noted, this lies even further in future, since I'd rather release #12 in not too long to get a better idea of how the current changes work out on their own. Suffice to say, everything will be tangled together with world factions, their relations and current objectives. Some questlines and bounties may have time limits and random outcomes, depending on player agency. Using my protobounty with the wanted-poster in Arken Town as an example, there might be a window of opportunity to get the bandit. The actual plot could be tested by querying the game world for the bandit's status. Maybe, at the end of each week, there is a chance of the bandit making a move. World events could be almost as Markov chains, with possible continuations depending on the actor's state. For a fugitive criminal, follow-ups could include a raid on a certain place, or fleeing the game world, or switching base to a small fortress somewhere on the map. From the new situation, the options would change again – if the bandit settles in a fortress, it probably means they're not "fugitive" any longer (although they are still wanted by the law), so the option to flee the Land might go away. It will probably have to be more involved than Markov chains, maybe more like a behavior tree. The different states should be abstract enough to be applicable to differently flavored scenarios. For instance, there are many kinds of shootouts and raid scenarios, which share a lot of similarities, especially on a tactical level. You basically drop a bunch of units in a hostile place and give them a certain objective (free the prisoner, find the macguffin, kill the enemy), and if then the player comes walking along, the units will become active and havoc ensue. I think it would be possible with a system where each faction and NPC of interest can have pretty simple flags regarding their narrative status and relations to other factions. The "fugitive/persecutor" conflict is archetypical, and will have a similar narrative dynamic if the story is about a political figure in exile/hiding, or someone fleeing the wrath of a mafia boss. As I'm working now on the ramifications of capturing the bandit in the protobounty, it should be possible to leverage the same rules to make it possible for the player to do stuff like joining the bandit's side by offering them the head of someone they are out to get. How you build reputation will inform who are more likely to chat to you about their lore and objectives and even actively hire you, and who are likely to attack you on sight. And yet, reputation needn't be an end in itself, in any technical term. There could be objectives generated on the map that are better performed incognito or require other maneuvers, like finding a hidden treasure.

Oh, the dreams one has. If only I could make time.

As always,

2 February 2018

LoSt this month

“How’s it look to you?” Bill said. He was handling the reins, sitting tall and handsome, nodding at voices when somebody called to him from the street. The word of who it was in the wagon got through town before Charley and Bill made a hundred yards. 
“Like something out of the Bible,” Charley said.
“What part of the Bible?” Bill said, when they were alone again. 
“Where God got angry,” Charley said.
   —Pete Dexter, Deadwood
Full speed ahead!

Last year saw some sporadic updates under the header of "LoSt this week". They weren't exactly the most ambitious posts on this blog, but still a way to document progress, at least. I figured I'd try a model of more reliable monthly updates this year. We'll see how reliable I manage to keep'em.

Back to the Meat

January saw some slow, steady development. Most notably, perhaps, I've reimplemented wounds in accordance with some old plans. I'm now testing with a flat counter à la hit points, although I call it "grit" rather than hp. The player will probably start with about 9-12 grit (a bit more than your average neighbor, owing to the natural determination and character that sets a wannabe frontier hero apart). Grit is marked out when an actor gets wounded. Currently, there are markers for bruises and grievous wounds. Wounds are semi-permanent, and typically only heal between missions, whilst Bruises regenerate every turn that is passed without taking any action or receiving any damage.

That's the gist of it, but I'm still ironing out the details and making related changes. The idea is to make bruises "inexpensive" (in that there is no food clock), so the player can freely gambit their grit in any local situation – if they feel confident on winning the fight. Wounds, on the other hand, will force the player to touch base every now and then, and some bounties and other story related content will certainly have time limits and thresholds; the world should not stand still if the player spends two weeks at the saloon to recover from a bear attack.

Expanding on the current implementation, I'll test using grit for status ailments and buffs in addition to wounds. For instance, being temporarily blinded or confused might occupy a grit marker. Likewise, positive modifiers from skills/props could tap your grit when active. I think this can work well as "payment" for certain skills, having decided early on that I don't want skills with cooldown periods, as that may encourage techniques like pillar dancing. Instead, each effect should be designed with built-in weaknesses. For example, the "fan gun" skill allows you to cock and fire in one turn, but at the cost of reduced accuracy. Another available effect is sprinting (move at double speed for some turns), and I hadn't been able to come up with a good penalty for that. Now I'm thinking grit may offer a solution. Let's say you accumulate "out of breath" markers the longer you sprint, meaning that you must spend turns to recover, or else come into the next encounter at a disadvantage. That should cap the amount of running around it's feasible to do, without nerfing it too much as a defensive strategy. I don't mind if running away is an effective "panic button" for many situations. Knowing RL players, each and one will die by the dozen, anyway; and it bears mentioning that I'm hoping to add non-lethal combat: in particular the option to surrender – so why not an option to run away? The villain should really just stand back and shout insults then, all the while depleting the player's reputation as a valiant hero.

UI Overhauls

Testing #12: «Wanted» poster in Arken Town
Note random truism in the bandit's generated name :)   
Changing the combat system has many ripples. For one thing, the tactical menu had to be rearranged. Working with visual interface design is something I find at once painful and strangely compelling (a bit like masturbating with a branding iron). There's a lot of relative coordinates to keep track of, especially if you take into account varying resolutions and font sizes, and more often than not I'll stumble over cryptic pieces of algebra in the existing code, that my previous self sucessfully used to put things where they belong on the screen, but which my present self is utterly unable to understand.

The new UI puts some info in a top panel. I've kept the right hand menu for inventory, actions and message log, but I was thinking it might be nice to add a "wide screen" mode as well. You'll notice the new interface has flashy menu buttons. I added these since LoSt now has basic mouse support. Yay. The icons in this screenshot are place holder art, by the way. They are more or less hand made, but some are direct ripoffs of Mayan glyphs that actually mean something completely different. So I may or may not keep the visual style, but I'll want the designs used to be original, in any case.

Fonts: Before…
While I was at it, I did some font work. Earlier versions used (and embedded) a few fonts with restrictive "freeware" licenses. I've been wanting to clean up that whole mess: reduce the amount of embedded fonts and make sure everything is open software. So I went font hunting, and found 1001 Fonts quite usable, especially as the site has the option to filter for only open source fonts. I also used Fontforge for the first time, making a very basic Frankenstein font by merging some glyphs into Linux Biolinum. I pulled the glyphs from various free sources, but was especially thrilled to discover Quivira, a font with pretty good Unicode support. In fact, that's where I got the glyph ♄ for lead, arguably the most important letter in the LoSt alphabet.

Fonts: After!
I also redid the logo, using Gimp to draw the letters with filled rectangles, that I then ran over with a bunch of filters. The new menu font IM Fell was just added for being pretty great and having probably the second most fantastic license I ever read (donated to the Oxford University by its creator upon his death in 1686). It may be too old fashioned for LoSt in the long run, but here and now it's quite functional.

Questin' fer Bounties

Since I need to test out the new wounds system, as well as the basic content for defeating the bandit scourge of Arken Town, I had to zoom back in on tactical aspects of the game, which has been refreshing after mostly doing macro-level world building stuff for the last period. I had completely "turned off" encounters (houses, animals, and even plants), but now switched them back on to get a trajectory back and forth to the bandit to slay him/her and bring back the head to the sheriff in Arken. If I do that (currently not trivial, but there's always the cheat options in the main menu :) it raises a little "karma flag" that I plan to use later, to influence reputation and skill advancement, whenever the player passes time between missions at one of the game world's resting hubs (eg. saloons, oases, hospices, cloisters).

I want you kids to get ahead
The infrastructure for implementing this basic kill/fetch quest, where the parameters are ultimately written in the human readable data files, can be used to track smaller achievements as well. There will probably be other "little karma flags" for conduct like giving to beggars, (not) shooting someone in the back, flaunting your pistol in church, and just generally pleasing/offending members of this or that faction/group in one way or the other. In the long run, I hope that the life time of more accomplished characters will span several years of game time, with slowly developing reputation, skill set, as well as global faction relations and story lines. If the game should come to that point, the "original bounty" I'm working on now will probably just be folded into a repertoire of random situations, that can be repeated, omitted and randomized over many replays.

So I'm walking a bit in the desert, getting killed some on the way, trying to imagine what the game will be like a few iterations down the road…

As always,

Gif of the month looks decent, but there's a lot of
graphical glitches too, as when simultaneously
scrolling the map and fading out dialogue bubbles!

10 December 2017

LoSt this week (yearning for Arken)

An easy bug fix, which I still
struggled to get just right. 
I'm still working on Arken Town (the settlement where the game is set to start), and making lots of small engine tweaks along the way. I've been refactoring the world generation routines for a while, and even if the changes don't make a huge visible difference, I spend quite some time just thinking the designs through. Organizing the data associated with the settlement, for instance, had me setting up some infrastructure to handle other important places on the map.

I've also changed to the climate map generator, so I can access more detailed info pertaining to regions and landscapes later. It's mostly stuff I need to generate bounties and story lines (ie. at the sheriff's/post office in Arken hangs a wanted poster, and the game must generate details regarding the fugitive's whereabouts).

The map generator just needs a few finishing touches before I can leave it for now, I think. So I'm zooming in again on the minutia of Arken to get this baby up in the air.

The gunsmith

Since I don't have a lot of time to muck about with LoSt these days, I'm trying to divide development into small chunks that can be handled in short, sporadic sessions. (In that light, it may be detrimental to the project that I take a few hours to write a blog post like this, but I hope it's part of the fun to some people at least who might drop by here from time to time :)

Now that I'm starting on Arken in earnest, I've decided to do it house by house. Each of the planned "places of interest" that can be generated, will demand that I fine tune the engine a bit. First out is the gunsmith, a pretty inconspicuous kid that offers some services. In addition to selling guns (and possibly special ammo), the smith can repair or enhance guns you already own (by adding a prefix, basically imbuing the gun with a special shtick).

Bittner lever action repeater, by a German gunsmith
Regarding engine tweaks needed to get this in the game, it's mostly AI-related. I have been working up to this, and already implemented the basic interface for giving items to NPCs. Now, I just need to make the gunsmith react appropriately if someone offers them a gun. It could be done by adding some states to the content database, but looking at practical solutions, it strikes me that the current AI module is very shaky. It may be a good time to go in and do some basic changes, since I'll only be facing increasingly complex NPC behavior as development continues. It's honestly something I've been mulling about in my brain for a while, so I have some ideas…

Adding the gunsmith will entail another addition to the engine, again quite moderate, but with possibly wide reaching consequences. When you offer the gunsmith a gun, I decided I'll have to pop up a window with a prompt to the player, like: <"I can fix this for 30♄." (Y/N)?> I already have <more>-prompts, so making it happen won't be a big deal (just get the confirmation, pay the bill and upgrade the gun). But it's something I might need later for popups connected to other game changing events. For instance, when resting at a saloon, the player may just see: <You rest for a week. Press Space to continue.> But the game should do a lot of things, like healing the player's longterm wounds, passing game time, and (if appropriate) grant the player new reputations and shticks, just to mention a few things. So, even this silly little popup becomes an issue to ponder on the metro after I've delivered the kids to school (whether I should compare that to a calligrapher meditating for hours before executing a simple stroke, or just admit analysis paralysis). In any case, it would be meaningless to hack my way through this to the benefit of the gunsmith, just to have to redo the whole thing when I come to the saloon a few houses down the road.

As always,

(1 hex ≈ 1 screen) A last change I must do before #12, is to make
the world larger with "bulkier" regions. The Land isn't supposed
to be huge, but the current scaling makes it feel too small.

18 June 2017

Breaking habits

Seeking fresh ideas … Hum!
Accomplished creators will sometimes say something to the effect that one needs to master the formal conventions in order to bend them and innovate. (In the arts, I suspect there is some deeper truth about the historical transition from Romanticism to Modernism, but I digress as always).

When I first started making LoSt, the idea was for a small 7DRL shooter with card based mechanics and no hit points (getting hit was game over). That didn't scale well, however, and was gradually transformed into the current combat system.

Wounds UI
Health: Actors have a number of health levels (HLs), each with a number of bruise levels (BLs). If an actor spends a turn not getting hit, they regenerate one BL. Once a HL reaches zero, however, it won't heal naturally, and the player needs to rest at a saloon or hospice.

Initiative: All events have a speed value, with actions performed in a fixed order each turn. Melee precedes missile attacks, which in turn precede movement. If you're next to an enemy, you can back away, but giving your enemy a free attack. Also, actions can be "interrupted" by incoming attacks. The idea was to give melee an edge in close quarters: If you're wielding a knife and facing a shooter, your best bet should be to get up close and stab your foe before they get a chance to shoot you.

Randomness: The system is mostly deterministic. Attacks have fixed damage, and there is no probability "to hit". Instead, melee sometimes deal grazes (half damage) or critical hits (effect depending on weapon). Firearms have a chance of going wild, depending on conditions like cover and skills.

Game changer
This may sound good on paper, but I've been vexed by the fact that melee in particular doesn't work well in practice. There was a problem of getting ganged up on, since taking more than one hit in a single turn almost invariably depletes a whole HL, something that should be avoidable with clever tactics. On the other hand, the rapid bruise regeneration means the player often has to land successive blows to properly wound the enemy, in turn taking as many hits himself. Likewise, it doesn't make any sense for instance to stab once and then spend some turns to wield and cock a gun, since the stab wound will be fully healed by the time you pull the trigger.

There's also been a problem with balancing damage. Comparing a club and a knife, they both deal 2 BLs, but the club spreads the damage over several HLs, whilst the knife puts all of it in a single HL. At the end of the day, the knife is almost unambiguously better, since it has the chance of depleting HLs more quickly.

However unbearable I find the current states of affairs, this system has been in place for years now, and me stumped as to how to fix it. Should I try to make something different altogether? Introduce a standard hit points system? God forbid! I'm giving the current rules another chance, and started by just tweaking the existing values.

Here are some of the changes I'm trying out currently:

Damage output: I made mostly everything deal a little less damage. I figured the lower tier weapons (bowie knives, tools, whips) can deal just a single BL in damage, and still be better than unarmed fighting, since unarmed fighters are unable to score critical hits. Increasing the player's health might also be an option here.

Bruise regeneration: Bruises now regenerate every second turn, and healing the last BL of a HL takes another extra turn.

Interrupted actions: I've disabled this almost completely. If an actor gets hit right before carrying out an attack, that attack is no longer blocked, but rather guaranteed to be a graze/wildshot. At point blank range, a wildshot will hit the target about 50% of the time.

This already works better than before, even if it's basically the same rules. For one thing, a couple of angry animals won't kill you in a single turn, even though it's still bad to get surrounded. The slowed regeneration rate means that there is more time to apply actual tactics, like spending a turn to reposition, without all bruises being reset. The fact that the last bruise in a HL takes an extra turn to heal also gives an advantage to weapons which deal damage over several HLs. A weapon dealing 2 BLs to a single HL still has an edge when it comes to quickly whittling down your enemies HLs, whilst a weapon dealing 1 BL to two separate HLs is less of an immediate threat, but will give an advantage a few game turns down the road.

I may still have to make some more fundamental changes to how combat works, but it's refreshing just to see the game work slightly different from what I've grown accustomed to.

Props unbound

Inspired by the moderate success with switching around combat rules, I'm also trying some changes to the inventory system. Again, some pretty arbitrary principles had grown out of the original game (some of them outlined in an earlier post). For instance, I felt that limiting actors to carry only six items at any time was pretty neat, since dead dudes would just drop all their loot in a nice circle around themselves.

Now, I've upped the inventory cap to 12 items, which really just lets the player carry more trash around (although balance issues may arise later). Secondly, props are now dropped and picked up from adjacent hexes rather than the one you're currently occupying.

The effect on gameplay is minimal, but I may keep it this way, just because it offers a solution to a problem I've been having: how to give props to NPCs? I didn't want a separate "give" command, so instead I implementing a heavy-handed system for offering NPCs stuff by dropping it in their field of vision. This is how you currently collect bounties from judges, by plopping the severed head of a goon in their vicinity. God only knows if a single player has yet picked up on the fact that this is a thing, as it's only vaguely hinted at in the dialogue. But if props are dropped onto the hex right in front of to you, the system pretty much gives itself: Simply invoking the "drop" command when facing an NPC should make for a pretty intuitive and smooth interface.

Current shop layout, and more spacious mockup
D=door, s=shopkeep, c=counter, p=props
I'm slightly concerned that some veteran RL players may find this counterintuitive. It's still possible to pick up items you're standing on, but that has the disadvantage of not properly teaching how it "should" be done. Players who fall into the habit of walking on stuff to pick it up, will in effect be wasting a turn as opposed to players who fall naturally into using the new system. There are some possible ways to fix that, either by making it a free action to pick something up, or even let props on the ground block movement. This last solution would mean some pretty drastic changes to tactics, but might even work when I start making everything a bit more spacious, which is something I've planned in any case.

Come what may, it's always good to break habitual thinking by changing the rules around a bit. Every dead end explored is a step in the right direction.

As always,

17 June 2017

LoSt this week (2 steps ahead, 1 step back)

It's been a while since I found the time to anything substantial with LoSt, but this week I managed to put in a few coding sessions and implemented some features that I've long been wanting to have. 

So I fired up old trusty byzanz to make a gif, which came
out slightly discolored, but I kind of liked that crusty feel. 
First, I got in a basic function to zoom in and out of the map. This will provide the framework for waypoints/travel, a logbook, etc. later on. Even in its current bare-bone condition, it provides me with a nice tool to examine my maps. It is an example of something which it is perfectly lovely to make. Since it'll help me as a developer, I'll of course be furnishing that map with icons to represent waypoints and other points of interest. And I probably won't be able to resist adding some ornament, like a compass rose or a smooth transition animation. All of this will only enhance the play experience.

Coming soon to a GUI near you?
Today I sat down and wrote the outline of an editor for place themes/blueprints. It's been cumbersome to use a text editor to make these, and the simple little application I hobbled together this afternoon is already more comfortable. It just makes the blueprints, so I still have to write the map legend by hand (rules like eg. fill hexes marked "E" with walls, put 1-3 shooters at "s", pick and put features/loot at "a", "b", and/or "c"). But it might make sense to add the function to set those parameters straight from the blueprint editor. It would have to be able to write blueprints as well as regular kits, which are the data syntax I use to store almost everything in the game. A few releases down the road, the actual game might even ship with a full fledged content editor that can be used to add/mod places, critters, props, bounties, skills, etc. :)

I hope to use these tools to do a rather extensive overhaul of the world building routines, that I've been dreading on the horizon for quite a while. The thing is that the current Python class used to build places is very all over the place. So I want to go through it and remove crud, as well as adding some tweaks and variables that I'm going to need to implement the next big thing in LoSt, namely bounties (random quest lines). Let's hope I manage to be clever about it, not leaving too many traps for myself later on. There are details I would like to get right sooner rather than later. For instance, I've been feeling that the game world is a bit too constrained. To amend this, I must above all make some inspired changes to the combat system, but I want to try to tailor them to fit a world with more space. Ideally, a house should have room for a table with some chairs that several people can comfortably walk around. For this alone, I only need some minor tweaks to the code, but when the time comes to remake all the old blueprints, I'm pretty hopeful that my little editor will be a nice tool to have. I've been digging up some maps of Western towns, thinking it should be possible to generate something similar, using map chunks. Typing out big map segments in a text editor was a great hassle, though, and is going to be much easier now.

A sleepy settlement

Nail Soup

I mentioned that bounties are the next major feature to show up. They introduce a whole new feature to design, and it's a feature that touches on practically every other part of the game. From the world map, to dialogue, to props, to combat, to the skill system, everything seems to come together around bounties. It's also a point where the setting is bound to become much more defined, which is a Good Thing™. Although I've always liked that early stage of creative development where everything is still lying quite open, I'm also looking forward to getting some meat on the bones with a starting settlement to provide the player with plot hooks, a place to rest, important NPCs, etc. 

Long term readers will note that I've already touted the coming of bounties as a feature for quite a while already. But it feels now as if I have to deliver at least a rudimentary fun game within the next few releases, or I might as well abandon the whole thing. Not said in a pessimistic note, rather hopeful that I might manage to reach the next stage of development in not too long a time.

Bounties will provide some sense of purpose and direction to the game, by stating explicit goals and pacing healing and advancement of skills/reputation between missions. But as I mentioned earlier, I also have to fix the combat system somehow, to make melee a more interesting option. As is, fighting happens too fast and is too deadly. There is usually no time to do any fancy footwork before you're dead, even if the game points in that direction with "fancy footwork" skills like Tumble and Feint. I may test "slowing down" combat a bit, giving everyone (at least the player) a tick more health, and making most weapons deal a bit less damage. Maybe even natural regeneration of bruises should be slowed, as long as the system stays transparent. The player should be able to take a hit or two as he spends a turn repositioning, switching weapons or using a skill. If I start with gentle tweaks of what I have, it's hard to say in advance if I will stumble upon something that works, or get some completely other idea for how to do it.

And really, it's not just a question of rebalancing the actual combat system. Other planned features will have an effect. For instance, there will be more ways to gather posses to aid you in battle (currently doable with the Populist shtick), and I am planning AI templates that will allow non-lethal battle, in particular surrendering (by dropping your weapon) and capturing (using rope or chain). And so maybe it will be okay for the combat system to be on the lethal side, if the player can (un)reliably hope to solicit the aid of NPCs or let himself be captured by the bad kids rather than outright killed (leading to possible interesting escape scenarios).

It feels a bit like I would want to do all the changes at once, just to be able to see how they interact. But I guess it's more like cooking. You start by frying the garlic and then the onions before getting on to the saucy parts. And a good saucier can predict how a sauce will turn out in advance, when it still only tastes like flour and salt. Me, not so much. I have this floury soupy slop, for sure, but no inkling of how it's going to turn out in the end.

As always,

PS. The current working title of LoSt is "Nail Soup", which is obviously an allusion to Dungeon Crawl: Stone Soup, although the allusion itself may be less obvious: "Stone Soup" is (so I've heard) a Portuguese fairytale about a vagrant who fools some villagers into believing that he can teach them how to make soup out of nothing but stones and water. They gather round, and the vagrant starts cooking, after a while remarking how the soup would be even better if they added a few carrots, perhaps. One of villagers happens be in possession of that precise vegetable, and so they add a few. After a while, the vagrant says this is gonna be good, but it would be even better if they added some chopped potatoes, and so it goes. In the end, the soup turns out pretty awesome of course, since everyone chipped in, which is the morale of the story. "Nail Soup", on the other hand, is the Norwegian variety of that same fairytale. Here, the protagonist vagrant meets with a single old crone in a house, asking to spend the night if he promises to teach her how to make soup just from nails. The story proceeds more or less as its Continental cousin, except here the hero is just ripping off a single person, so that the productive/social morale of the story is flipped. When a Norwegian speaker talks about making nail soup, that means rather to make something with no or meager resources.
And there was much rejoicing

12 May 2017

The Slow Application Development (SAD) Methodology

Head space!
C'est à un combat sans corps qu'il faut te préparer, tel que tu puisses faire front en tout cas, combat abstrait qui, au contraire des autres, s'apprend par rêverie.

A rant about very little in particular (which is incidentally also how, if ever my exploits as a Roguelike developer are to be mentioned in some footnote of history, they will be described).

I found some notes for an old blog post, and decided why not go ahead and publish this scrambled mess?

I was going to start by mentioning Tobias and the Dark Sceptres, which had just been released for free after 13 years in the making. This was in 2014, so bringing it up now might feel a bit late. In that sense, I guess everything is going according to plan.

This is supposed to be a blogpost about the Slow Application Development (SAD™) Methodology, the professed in-house design philosophy here at Domus Daedali. The rules of the SAD Methology are as numerous as they are fickle…

Thou shalt start in the middle.
Thou shalt code under the influence.
Thou shalt add empty variables with vaguely suggestive names, in case thou needst them later.
When too late, refactor.
Release sometime, release sometimes.
Embellish details.
Thou shalt never monetize thy project!

The guy who released Tobias had been tinkering on and off since he was a kid, and the whole thing was made in klik'n'play or something like that. Now, some of the commentariat were boggling at the fact that he didn't charge any money for the game, and I remember thinking: If you have to ask why someone chooses to give away something they've been working on for thirteen years, you probably won't understand the answer.

As always, I find comfort in the SAD methodology.
If it's not broke, fix it.
Never monetize!
It's one step forwards and two steps back, so the way ahead may be to walk away from your project.
Take out your money and shoot it in the head! 
We have to build cabins.

LoSt's business plan
The SAD methodology is not applicable to professionalism of any kind: From struggling artists to celebrities and mainstream developers, movers and shakers of the mindscape… We bid them farewell, with a thanks for paving the way nonetheless.

The crux of the matter is that having no real stakes in the project means you've less time in the day-to-day, but so much more as the years accumulate.

Though it remains unclear what we are trying to gain freedom from, we are willing to spend every ounce of our patience and monomania to get it.

A tiny shelter.

Developing commercially entails another mindset entirely. Mind to say, it is not one less respectable. On the contrary, it demands an admirable effort and excess of ideas to achieve the degree of polish needed to set something afloat in the vast ocean of cultural products. In fact, one of the things that prompted me to pick this post up again after all this time, was a post about monetizing RL devlopment over at Cogmind's excellent blog. (That's already been four months, so I'm staying true to my tenets, if nothing else.)

In any case: As fascinating as I find that pursuit, and as much as I respect and understand the decision to venture in commercial game design, I am also glad this is not the way that Land of Strangers is going. Even if I were to try to tidy it up, finish and sell it as an "indie open world wild west roguelike", the work/pay ratio would just be weepable, and I might risk the overall vision by making "concessions" to some imagined demands from the paying public. Developing in accordance with the SAD Methodology, I get instead to focus on the work/play ratio.

What I like about making my "little open acid western roguelike" is that I don't have to take all that stuff into account. I can choose to just say no, or whatever, to wholesome values and clever design choices. Proper graphics and overall polish? Yawn. Audio, who needs it? (Or maybe I will, but just slap on a sub-par recording of me mishandling my youngest son's ukulele.)

Never finish.
Work in the crevices.
Start side projects.
(Don't) quit your day job.
Just in case.
Have kids.
Stand in a pedestrian island reciting sutras whilst meditating on the cars coming to rape you.

Psyching up to do some coding
The SAD Methodology depends on a circular definition: The refusal to monetize and the refusal to finalize enable one another, defining a space, like a protective chalk circle where any (in)conceivable project can be allowed to grow. In many cases, it becomes a question of necessity. Lately we're seeing how old giants like ADOM and Caves of Qud are monetizing updated versions of their classic games. One thing these two have in common (and an article could be devoted just to discussing the differences), is that the colossal games which were already in place as the business model started to kick in, had taken many years of hard, unpaid work to achieve. If ADOM and CoQ had started out as commercial projects, they probably would never have seen the light of day.

I suspect this is part of the reason why Mark Johnson  has refrained from any kind of crowd funding scheme for his grand opus Ultima Ratio Regum. It also seems that Krice professes to the SAD Methodology, so what in the world could go wrong? It certainly is the fuel of much vaporware – and honestly, we would be so much worse off without classic never-mades in the vein of Shockfrost's game and World of Rogue.

It might be tempting to say that sites such as Kickstarter have been doing us a disfavor by blurring the lines between professional and amateur development. But the problem doesn't really lie with concepts like crowd funding, even if there is a deep-set problem with how capitalism is carried out these days. Be that as is may, the SAD Methodology isn't mainly about Smashing Capitalism™ (though let's do that as well, while we're @ it).

Rather (with the risk of becoming too pretentious even to the tastes of a reader who made it thus far), I'd say it's akin how a painter or author is never able to step back from the work and say: It is finished. Such a grandiose image can also be applied to humbler endeavors.

Never finish!
Never monetize!
Go and live in the desert!
We're all blessed. 

You know the drill.

We have to build cabins.

As always,

1 "You must prepare for a battle without body, to be able to take a stand no matter what; an abstract battle which, unlike others, is learned through reverie." (Henri Michaux, Poteaux d'angles)