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,
Minotauros

(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.

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

Burro!

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,

Minotauros

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,

Minotauros

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

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.

   —Michaux¹

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.

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

Minotauros

---

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) ^↩

Released: LoSt #11.1 (Mercury Chewinggum)

This fixes a bug in the Windows executable. The bug didn't affect gameplay, but made it impossible to complete the in-game survey. Linux users and users executing the source code directly should not be affected. Sorry for the inconvenience.

Go to the download page to get your mercury fix.

As always,
Minotauros

Released: LoSt #11 (Mercury Bubblegum)

Catch of the day

This is an interim release, preceding a hefty rewrite of some of the systems. I wanted to start refactoring from a clean cut, so to speak, so I'm publishing what I have to date.

In other words, LoSt is still in alpha. Compared to #10, this version contains some bug fixes and a bit of content. The most spectacular feature is perhaps that you can now gain followers by choosing the "Populist" shtick.

I'm about to redesign big chunks of the world generation algorithm, in part to fix problems which have become apparent in testing, in part to accomodate plans I have for bounties (quests) and other features. Bounties will also be tied up to a system for the passage of time (including healing and skill advancement), so there may be some exciting prospects on the horizon, even though I as a developer will have to do some untangling to get there.

Comments are always appreciated, on appropriate forum threads, per email, or you can fill out the in-game survey that I added as an experimental feature in this version. It'll be interesting to see whether that garners any response, and if I can use it to guide and motivate further development.

As always,
Minotauros

CHANGELOG

BUG: Couldn't pick up lead slugs when pockets were full
BUG: Buggy inventory interface if pockets were empty
BUG: Critters turned invisible when spending props
BUG: Could see through walls at certain angles
BUG: (Serious) bug that made game pick invalid kits
BUG: Bug that printed nonexisting plants and obstacles
BUG: Spitting bush had forgot how to spit
BUG: Some instances of NPCs getting stuck repeating one action
BUG: Crashed because game tried to draw outside the screen
GAME: Player can now start with up to two shticks
GAME: Some props can be used directly from inventory (experimental)
GAME: Prompt to abort extended actions when hostiles enter line of sight
GAME: Commandline options to set world seed
GAME: Scrollable menus (needs polish, but should work ;)
GAME: Cleaned up the log area a bit
GAME: Can save multiple characters in the same world
GAME: Default field of vision now set to 11
CONTENT: Renamed "derringer" as "pepperbox gun"
CONTENT: Fleshed out animal species a bit
CONTENT: Weapon prefixes
CONTENT: Added some skills, props, places and critters
CONTENT: Backstory generator now spits out terser texts
AI: Added more bias switches: annoy, please, exalt
AI: Action calculation for fields of battle plants should be quicker
AI: Gain followers (experimental)
AI: Most beings now set to stay at home or roam their native region
AI: Toolwielders now better at choosing their weapon
VAR: Added an in-game survey
VAR: Various tweaks and fixes

Idea that will never be a 7DRL

Please excuse this quite silly rant about my old idea for a 7 Day Roguelike.
TL;DR: In the end, it's practically randomized, anyway :P

#DogmeRL 7DRL

A Dogme 95-inspired Roguelike, featuring:

No ASCII!
No message log!
No keyboard interface!
No random maps!
No permadeath!
No grid-based tactics!
No item identification!
No MacGyvering your way out!
No resource management (consumables, healing, food clock)!
No hack'n'slash!
No rpg system!
No dungeons!
Modular gameplay!
Emphasis on story!
Play as a party!
The full Roguelitelike experience in one package!

Check and mate, suckers!

I've long wanted to make an Anti-RL that "breaks all the rules" for what a RL is. It struck me now that it would be ideal to combine with two other things I've been wanting to do, namely learning a bit of Godot, and making a game for my kids (targeted age around 6-9).

In the end, I would aim to make something that doesn't fit the genre definition by any stretch, while retaining that good ol'e RL feeling.

Tail of Eugor

For the actual game, I figured the basic interface is a touchscreen Roguelite with minimal text and easily graspable (hopefully deep/fun) gameplay.

The scourge of elephants

The setting rips off various sources. Take a silly mangaish/fantasy universe like Mario, Sonic or Lego: Ninjago, throw in some White Wolf's Exalted, mix with Tove Jansson's Moomin (and more obscure references) ... I decided to just go ahead and make the heroes furries :D So you have this magic stone age world inhabited by tribes of biped animals wielding magic just cooling it with gods and spirits who still tread the earth of this young world. In the rivers and wetlands dwell frogs and hippos, striking secretive deals with daemons of the depths; whilst elephants rule the plainlands from their walled cities of byzanthine bureaucracy, but fear the wild mice who roam the woods. You get the general drift.

On the list of anti-features, some almost give themselves, some merit more consideration.

EUGOR: Featuring
Modular Gameplay™

INTERFACE: We're on a touch screen with graphics, so no ascii or keyboard. We don't want turnbased, gridbased tactics, but we do want modular gameplay. So let's make it a bit like a jrpg (bear with me). There is a walk/explore mode where you tap wherever you want to go on the map. NPCs walk around in real time. If you bump into an NPC or feature (or if an NPC bumps into you), you engange that being (bump a person to speak, bump a monster to fight). This engagement can be handled in a separate mode with alternating turns for combat/actions. Put on top: an overworld mode to travel between the different maps, designed like an overworld in a typical Nintendo console game, with each place a node, and paths between those nodes.

NO HACK'N'SLASH: Since it's for kids, I don't want combat to be the main way to solve everything. Sure, some spectacular fighting scenes with earthquake hammers and the like, but it might be better to give the hungry lion a pancake to make it happy. Maybe it will even join you on your quest!

NO IVENTORY HANDLING: Instead of inventory, the player collects "gifts" (objects, skills or characters who join your party). Your gifts determine what you can do, depicted as icons in a menu. You can always try to use any gift in any encounter? If you have Icarus Wings, you can use them to fly over the river or escape from a fight. If you have Persuation as a gift, use it to calm your enemies or get special favors from friendly NPCs, etc. Gifts may sometimes not work (angry bees won't be persuaded, troll immune to sleeping magic), and gifts are not comsumable. The gift Itching Powder would have infinite charges, it's just a thing your toon can do. Throughout any one game, you'll just get a handful of gifts, so there's no looting and no identification subgame. While there is leeway for some "easter egg effects", there should be no "complex interactions" like dipping, throwing or collateral demolition.

Uh … Follow the
dotted brick road?

NO RANDOM CONTENT GENERATION: The biggie. I'm actually planning to cheat on this one :) I would venture to replace random content generation with (drum roll) stochastic content generation! It would be deterministic, but provide replayability akin to randomness, by dynamically generating the world based upon the player's choices :P

First of all, each level/node you visit is prefabricated. If "elemental temple" is a place, you always get the same layout, with the same designated spots for your acolytes and abbess, your braziers and you vortex of elemental doom. Each place should be a small screen, so the "temple" is really just a little shrine that your avatar can cross in less than ten strides..

Second, the overworld map is predetermined, divided into four zones to visit. From the starting zone are borders you can breach to enter Zone A or Zone B, the midgame zones. Here you need to prepare and to find the key to enter the fourth and last zone, where the endgame takes place. It could be structured a bit like one of those exemplary analyses of Zelda levels, with bombs to breach weak walls, branches to make you feel like you're choosing your own way while carefully guiding you past mandatory choke points, etc. The midgame zone you choose to enter first should be set as the main branch, with the remaining midgame zone tagged to remain as an optional bonus branch.

Third, the player gets to choose some parameters at the start of the game. This is where it starts getting stochastic, as we're doing the equivalent of setting a random seed. Consider the following:

«Just send me the money»

"Eugor was a young …
    1) frog 2) mouse 3) elephant 4) fox 5) chicken

… who lived in a …
    1) cabin 2) town 3) shrine 

… by a …
    1) river 2) ravine 3) mountain 4) great wall. 

… Eugor's neighbor tribe were …
    1) frogs 2) mice 3) elephants 4) foxes."

That gives a little more than 4^4=256, a fine, round number of starting positions. Your choice of species will set a starting gift, like frogs can swim, mice are fast, whatever. Your starting map ("cabin", "town" etc.) has its predetermined follow-ups, so if you choose "cabin" it has paths to "woods" and "town", and if you choose "town", you get "shrine" and "ferryman" as followups. Choosing to start in the town means you won't get the shrine or ferryman later in the game, but are guaranteed to come across the woods and the cabin. A level like "natural source" will play out differently if you're sent there to talk with a guardian, or to steal a treasure, and whether that happens in the early or late game. Also, factors like climate and player race may affect which species inhabits a particular place (facing slow, mighty elephants or quick, crafy mice makes a difference).

Off to see the wizard, biatch!

Visiting the swamp or the desert first might become a strategic choice, since it determines if you'll be facing salamanders and scorpions or spiders and platypuses.

Envisioned on this scale, with 4 zones, I'd probably need around a dozen locations. The game should be scaled to a small proof-of-concept, taking less than an hour to win. Still sounds more like a 7 Month Roguelike to me. It can be done, though. The hard part would be to get the design just right.

I might actually give it a shot (but probably not as a 7drl) if the right conditions arise, as I've really been wanting to check out Godot for mobile games, and I would love to make something silly like that, that my kids (and other random peeps) might enjoy playing.

As always,
Minotauros

In the works

Pick up smithereens

I'm hoping to get #11 out of the door within (quite) a few weeks. Since the release of #10, I've been trudging along, adding fixes, tweaks and content. I'm currently wrapping my head around two major additions for the next version: A proper starting settlement, and a basic system for bounties ("quests"). Both of these complex tasks imply various changes and additions that need to be done to the system, and they are tangled into each other as well, since the starting settlement will naturally be where you pick up your first bounty. Development is still at an early enough stage that fairly important parts of the engine are missing or incomplete. Once I manage to pump out some interesting settlements, for instance, it should be trivial (system-wise) to add more content and variation to them. Trivial, I say, knowing that the really time-consuming part of development is often designing and balancing content.

I put road generation on halt when
it started throwing swastikas at me.

Regarding settlement generation, I've been trying out different strategies: Settlements as blobs containing houses and points of interest, settlements starting from a single point and spawning outwards, or popping up along random roads, or as climate templates … The results have been unsatisfactory. Given the current map digging routines, really made for wilderness generation, it's been difficult to achieve the kind of division of space that a settlement should have. What's more, the settlements have to be tactically interesting, as they will set the stage for duels, robberies and other events later on. At the moment, I'm considering using prefabricated blueprints to a large extent. It would break my heart to see the same starting settlement again and again, but something quite static might provide a spring board for more testing.

Adding bounties is also a tough nut to crack. I want to get it as right as I can from the outset, to avoid having to come back and make too many major changes afterwards. Thus spake the optimist. Bounties touch upon many other aspects of the game, from map generation to skill advancement. I'm talking about proper story lines here, not just dumping some goon's head at the local tribunal to collect the cash reward (you can already do that in #10). As with settlements, I'll probably add something very simplistic for now, just to sort out the basics, like how the game world should spawn and know about bounty-related places, having villagers disperse rumors about active bounties, getting an interface for rewards/resting/experience, and so forth.

Hunted by kerebears

A detail I'm currently pondering, is simply how to present a bounty to the player. I hope to avoid dialogue trees, and have been envisioning a game with the player as "the silent type", and NPCs shouting out chat lines as appropriate. If that's going to work, it's pertinent to avoid the typical trope of NPCs just throwing random quests at the player upon arrival. It might just be a question of writing the right pieces of dialogue. For instance, a bounty to join a hunters' club could be presented by way of a kid sitting outside, proclaiming how he'd like to be a member, if he could fulfill the membership requirements (bringing in a random named animal, for instance). It's not Ibsen, perhaps, but I guess it would be acceptable in a crpg, as a way to inform the player of a certain possibility space.

Here and now, I may sidestep the issue, slap a Wanted-poster up on the wall of the jailhouse or post office and see where it takes me.

Also in the works is a travelogue mode, that zooms out on the map and gives the player access to various utilities (setting waypoints, logging rumors and bounties, etc). I may not need this for #11, but it's going to be a boon as the game world gets more involved.

As always, Minotauros