Neohack progress report - I'm being chased by wolves!

[Bear]

Module interface is now debugged and working.  New creatures (and by extension items, tools, supplies, treasure, etc) can now be added without touching any of the 'engine' code.

Full blog post at:
http://dillingers.com/blog/2014/09/29/i-have-never-been-so-happy-to-be-chased-by-wolves/

Excerpt:

So Action_Wolf_INIT does the following things;  First, it defines an attribute stack for wolves.  Neohack has generic actors, whose actions, interactions, and capabilities are all defined by attributes.  An actor can have any number of attributes.  The attributes that define wolves give them things like a speed, a reference to the AI routine they use, a map representation (the brown 'w'), a size and mass for modeling in-game interactions, and so on.  Then it adds the attribute stack, with the name 'wolf' and the additional information that it is a 'species' kind, to the kinds table, so from now on that 'kind' will refer to a species having that attribute stack.   Then it creates an event (using the predefined event routine 'Action_Make_Critter') which will make two wolves, and puts that event into the 'Natural Animals' generation table, with an oddment, in this case, of 1000, which corresponds to a probility of 1000 out of however many oddments the Natural Animals table has when everything has eventually been added to it.  And that is absolutely everything that Action_Wolf_INIT needs to do.

The map generator gets called after all the INIT events have run.  It calls the 'Natural Animals' table to get an event, makes a copy of the event, adds a 'to location' argument to that copy so that the created critters will appear in a definite location on the map, and then puts the copy into the schedule as a new event.

[Bear]

I reduced this to 50% of the size of the screenshot, but it's still big.  Anyway, above you can see the @ getting chased by one of the 'w's I talked about in the post.

[mushroom patch]

Nice looking dungeon display. What are you using for your open floors? Something like " ."? I've never been satisfied with the way unicode fonts handle wide center dots. They're never actually centered =\

[Bear]

They're just plain periods, displayed in bold where they are lit and in view. 

Each 'tile' is two character cells, which is why they're lining up in a square-ish grid instead of being stretched top-to-bottom. And the place where you can actually stand in a tile (ie, the left character cell) is the one marked by a period. 

[mushroom patch]

Oh, I see. That looks better than I would've thought.

[Bear]

I've been refactoring a little to reduce inter-header dependencies, and running this program over and over to test each time I compile it, and my imagination plus testing and tweaking is coming up with a tight little  coffeebreak game that seems very achievable without building out much more infrastructure at all. One kind of monster.  One kind of object.  One level.  Imagine it as sort of a turn-based pac-man, except that the mazes are random and most of the time you can't see the ghosts. 

I slowed the w's down, and now I'm imagining them as some kind of undead things instead of wolves. They don't wake up until they see you, but once they've seen you they chase you relentlessly using sight-gradient pathfinding.  Because the @ is a little faster than they are, and the level usually has loops in it, or at least chambers big enough to lead them in a circle, you can get far enough ahead that you can explore all the little dead-ends if you're careful and a bit lucky.  But you can't see the w's unless they're in line of sight, so most of the time you can't directly see how far ahead you are. Instead, you know how far ahead you *were* the last time you saw them, and you have a decent guess (though not a perfect one, due to some randomness in their movement) as to the path they're following chasing you.

The strategy involved is that while you're moving and exploring,  you have to keep track of where the w's will have gotten to by this time from where you last saw them.  You can be fairly safe if you have a loop or two to run them around.  But getting caught in a dead-end with the pursuers behind you means you're dead meat.  So you're constantly asking yourself, "how many steps can I take into that unexplored area before I either find a loop or a big chamber I can outmaneuver them in for safety, or else have to turn around and come back so I don't get caught in a dead end?" 

Sometimes you also need to maneuver to keep them together if they start getting strung out, or maneuver to get them back together if they get separated.  They're more dangerous when they're spread out or separated because then you might get caught between them if the last one cuts a corner you didn't expect it to cut, or in a chamber you might have the last one still coming out of the entrance you wanted to go back down, after you've outmaneuvered the ones that came in first. 

When you catch sight of the pursuers again and there's one missing, you're going "ohcrapocrapocrap, where's the other guy?"  Because you don't want to find him ahead of you in a passage when you've got the main group still behind you.  Or when you catch sight of the pursuers again and they're not where you expected them to be, it's time to stop immediately and plan a new route because they cut a corner.  And you don't know for sure whether or not it was *ALL* of them that cut the corner, if you don't see the whole group at once, so there may be one still coming on the path behind you in addition to these guys who are now at shorter range and coming from a different angle.

So the game I'm imagining involves retrieving nine keys from the level, given that three of them are guarded by relentless and deadly pursuers just a little bit slower than yourself.  You have to explore the level to find the keys, but there will be at least three that you cannot find without waking up pursuers, and at least two that you cannot find without waking up a pursuer that's probably in front of you while there's another one (or two) chasing at some distance behind you.  You have to avoid them all while maneuvering so you can get back to the locations they were on to get the keys they were guarding. 

It doesn't require much more infrastructure than I've already got, and all of the infrastructure is stuff I need to do for a bigger game anyway.  I need to implement inventory (pick up and carry anyway) so somebody can pick up the keys.  I need to implement a "death touch" attack, but that's easy.  I need to implement a scoring system and high scores board.  And if I go an extra mile, there might be a potion that grants very temporary (like maybe seven turns) of immunity to the death touch somewhere on the level, or an amulet that will protect you exactly once.  Because it's just a one-level, ten or fifteen minute game, it doesn't even need save-and-restore code yet.

[Hi]

If you make it available I will play it.

[Samildanach]

If you make it available I will play it.

Seconded.

[Bear]

Well, I added keys to the game -- that was easy.  They don't have any significant properties yet, except a (small) physical size and weight, and a display tile. They just sit there on the ground. 

I wanted to use unicode 0x1F511 (the actual 'Key' symbol) but my console font doesn't contain it, so it displays as a grue (black space on black background) regardless of color/attributes/etc. 

So I'm using 0x26b7 (the 'Chiron' symbol) instead.  It looks key-like. 

Eventually a console font that covers the Unicode glyphs I want the game to use, will need to become part of the project, I guess. 

Or (probably also) a test program that questions the user about what useful characters the console font contains (ie, which characters, of the ones the game wants to use, can the user can actually see?) and what display attributes the terminal implements (eg, ask the user if there is any visible difference between these two characters, displaying one A_DIM and one A_NORMAL, etc) and sets a configuration file accordingly.

But I don't want to make the users mess with font configuration to install the game, or make them use a special or different console to run it - I want it to work in a default console on any machine that has a Unicode locale.  So, for now anyway, 'Chiron' instead of 'Key'. 

Anyway, on to hacking inventory!

[Rickton]

Or (probably also) a test program that questions the user about what useful characters the console font contains (ie, which characters, of the ones the game wants to use, can the user can actually see?) and what display attributes the terminal implements (eg, ask the user if there is any visible difference between these two characters, displaying one A_DIM and one A_NORMAL, etc) and sets a configuration file accordingly.

That's a good idea. If you're going to do that, then depending on how important colors are to the game, you might want to add colorblind settings to it too.

[sokol815]

kind of reminds me of an old javascript game I wrote back... in 2010. Called minotaur vs orcs. you are a minotaur defending your maze against an incursion of orcs. The faster you beat a level, the more points you get. Not my best work, but it's what got me started writing roguelikes.

http://exilania.com/minotaur/

[Bear]

So, I hacked inventory.  Now the little @ can pick up items from the floor, and when he looks at inventory, it lists them under a 'carried' column.  Other columns cover worn, wielded, and (if we happen to be talking about something odd like @ is a container) contained items. 

It goes so far as to count them and list them together if their names (the names the character knows) are identical.  So if you've picked up one key seven times, it will tell you in inventory that you're carrying "7 keys" rather than listing "a key, a key, a key, a key,...."  Note that the names that guide this behavior are "as known to the character", so things that are different can stack as long as the player doesn't know that they are different. 

Right now the amount of stuff you can have in inventory isn't limited.  I don't think I *will* limit it in terms of number of slots.  I'll try to implement weight/bulk limitations instead. 

[Bear]

Today I implemented health,, damage, and death routines.  I know that the "Nine keys" game requires only a "Death Touch" attack because it's effectively a "one hitpoint game." But I'm implementing a bunch of things that I don't actually need yet just for the "Nine keys" game.

What I haven't implemented about that, yet, is a hitpoint determination algorithm.  I spent a good deal of time thinking about it though;  How should I decide how many hitpoints a character ought to have, when full up on health?  And I have the outline written up, though not yet coded.

I'm deeply unsatisfied with games like D&D where it's simply proportional to level -- that gets ridiculous, where a squishy human has more hits than a dragon, can survive terminal-velocity falls, and so forth.  And I don't like the mechanic where due to the extreme differences in hits between low and high level characters, someone who tries to dive with a low-level character, no matter how well they play, will quickly get stomped flat.

From a game design POV, the progression in hitpoints (and damage capabilities) more or less regulates the rate at which players can access new content.  In games where finishing characters have upward of a thousand times as many hitpoints as starting characters, most of the time is spent grinding for power as opposed to actually trying to accomplish the real game objectives, because power (HP and damage capability) is simply required for continued EXISTENCE, regardless of brilliant or stupid play, in any areas where real game objectives can be accomplished. 

So, I decided to try to balance things very differently.  Winning characters, IMO, ought to have maybe about ten times as many hitpoints, and do ten times as much damage per round, as beginning characters.  Not a thousand (looking at YOU Zangband). Not a hundred (Looking at YOU Nethack).   Ten.  You get a third of the hitpoints you're likely ever to have by level seven, you get up to half by level 20, and you asymptotically approach but never exceed the limit the higher you go after that.

Meaning, yes, your 30th level character, if you play really stupid, actually can get killed by a bunch of goblins.  And also, yes, your 6th level character, if you play really smart and only a bit lucky, might actually reach and even steal the MacGuffin from (though probably not kill or even hurt) the final boss. 

Also, arbitrarily and randomly, some characters both will and SHOULD have above-average hits starting early and persisting for their whole careers, and some will and SHOULD have below-average hits for their whole careers.   While this is blatantly unfair as regards hitpoints alone, it gives me the opportunity to differentiate characters by awarding rare, randomly selected powers, bonuses, and abilities to characters who seem doomed to have equally rare low maximum hit totals.  Specifically, powers, bonuses, and abilities which are simply not available otherwise, and whose very possibility players might remain ignorant of even after scores of games.  There are things that ought to be possible but not to be relied on, and not reachable by any combination of increased level, grinding, etc. and these can be used as compensation/game balance for chronically low hitpoints.

Because, among other things, I really hate thousanduplet syndrome, and I really hate "formula play" where a player can play every character just like the last one.

Much of the pleasure of writing these things lies in trying something different specifically to address your own set of pet peeves.... 

[mushroom patch]

Seems like you want low level characters to be able to go toe to toe with high level monsters through "smart play." It's hard to see how something like that plays out. Does this make levelling meaningless to an expert player? If higher level monsters are not doing a lot more damage than lower level ones, where's the difference? More side effects?

What does smart play look like? Coming to a place with resistances appropriate to the monsters that live there? Sneaking around without fighting anything?

[Bear]

Well, if you're a low level character, "smart play" sure as heck means NOT trying to fight high level monsters.  However, it doesn't preclude making deals with them.  Doing something they want done, giving them money, driving a herd of goats into the lair ahead of you so at least when they see you they won't be hungry, and sneaking past are all possibilities depending on what kind of monster we're talking about, though none is without risk. 

If you're a high level character, you still have all those options, plus you might be able to kill a high level monster such as a dragon - by setting up an elaborate trap involving a seige engine that fires sharpened telephone poles, by a coordinated sneak attack on a sleeping dragon, with special attacks like stoning or a death touch, by levering big rocks over both exits and then flooding the cave, by causing a cave-in, or some such tactic.  But toe to toe?  No, that's just insane.  Nobody goes toe to toe with a dragon.

Smart play looks like knowing where you're going and what's there, and preparing appropriately.  For example, you don't try to steal from someplace called "Dragon's Eyrie" without, yes, finding some source of fire resistance (and preferably some way to fly) first.

Tactically, it means knowing how to ruthlessly exploit a speed advantage, how to guess where a chasing monster is even when you haven't seen it for a hundred turns, having planned routes in the area you've explored that allow you to escape and evade, knowing about how many steps you can take away from them without finding a place to run around an obstacle if something you can't fight starts chasing you, etc.  It means knowing you have to sneak or run instead of fighting sometimes, (more the deeper you get) and knowing when. 

It means knowing when armor that clanks as you walk along making it impossible to sneak isn't worth the better protection it offers (when the monsters are dragons that can kill you anyway) and when it is (when the monsters are puppy-sized giant ants or venomous snakes whose poison bites it makes you effectively immune to).

And, yes, I want smart play to be at least *AS* important as character level.