LambdaHack

[tuturto]

I have been learning some Haskell recently and wanted to start writing something more complicated. There's engine called LambdaHack (https://github.com/LambdaHack/LambdaHack) that is used at least in Allure of the Stars (https://github.com/AllureOfTheStars/Allure). So, there are at least two examples how to use the engine, but is there a tutorial or something somewhere? Or other games written with the same engine?

[tuturto]

I got LambdaHack compiled and running (not that difficult actually) with GTK interface. I have been picking around the source code and getting familiar with the layout. Nice thing is that the code is really well organized and looks sane. Maybe the best course of action is to copy the example game and start trying to change it a bit.

[tuturto]

Currently I have a game up and running that uses LambdaHack as an engine. Configuration\actual exe is from a separate package (although code for that is still from the LambdaHack example). The biggest hurdle was to write .cabal file that specifies what libraries the game depends on and what extensions should be turned on.

So, there's a self contained software project that results a runnable game and depends on LambdaHack engine. Next step is to start picking it up and try to figure out how all the pieces relate to each other. I'm kind of thrilled, since I got a working game with user interface and all I have to do is to add the content Later on will have to look into actually extending things beyond what the engine offers.

Any ideas or hints, where should one start such a task? Any hints on Haskell (except the obvious one "learn to use it"). The language is really sweet and it's growing on me more and more.

[tuturto]

Here's a screen shot just a moment before quine manages to kill the captain and the game ends.



Repo available at: https://github.com/tuturto/space-privateers

The engine supports having multiple units under command of the player. So far it looks to me that only one of them is moving at any given time, while others just stand still. I have been wondering if there exists a way to make them move autonomously and follow the player and fight when given a chance.

[Man of Letters]

Hi! Just stumbled upon the thread...

Any hints on Haskell (except the obvious one "learn to use it"). The language is really sweet and it's growing on me more and more.

True. Here is a sensible prioritized list of Haskell resources

https://github.com/bitemyapp/learnhaskell

But nothing beats jumping headfirst into an alien codebase, obviously.

So, there are at least two examples how to use the engine, but is there a tutorial or something somewhere? Or other games written with the same engine?

No tutorial and moreover the engine changes all the time (though the API
should be more stable after 0.2.14 was released yesterday). AFAICT, you are the first
brave (or mad) enough soul to use it and to announce the foolhardy attempt beforehand.

BTW, congratulations on choosing the cleaner, but harder, way of using
the engine, namely by keeping your game content in a separate Haskell package
from the start. I've modified the game docs to address that such noble
and audacious possibility even exists:

https://github.com/LambdaHack/LambdaHack/commit/d3d31fcb3fbf0d2110905ab534ab8797b3ae6f5b?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8

Here's a screen shot just a moment before quine manages to kill the captain and the game ends.

Heh, YASD. Nice.

I see your dungeon has Hack/Nethack style visuals. For comparison
here is the Moria/Angband style (particularly the last screenshot)
that Allure of the Stars uses:

http://www.roguebasin.com/index.php?title=Allure_of_the_Stars

The engine supports having multiple units under command of the player. So far it looks to me that only one of them is moving at any given time, while others just stand still.

Yep. By default humans move one by one, and only melee simultaneously.
You can switch among the actors you control with Tab and Shift-Tab.
And if you really want to move a group together in formation,
you can select them with '=' or '_' and then run (Shift-direction).
Note however that they move one by one and each individual move takes a turn.

I have been wondering if there exists a way to make them move autonomously and follow the player and fight when given a chance.

By default monsters (aliens, robots, animals) do that. There's nothing stopping you
from adjusting your human faction to move like that or creating yet another
faction with this behaviour. Just tweak this line (from the 0.2.14 codebase)
to assign 'allSkills' to a non-leader actor:

https://github.com/LambdaHack/LambdaHack/blob/7e0776face9d4f0fbe8743b75da6067d3c7deb80/GameDefinition/Content/FactionKind.hs#L27

Or you can set 'meleeAndRanged' and then the heroes will remain immobile,
but will be able to reaction-shoot (or rather reaction-throw) all the time.

Have fun creating your world and eventually hacking the reality engine itself!

[tuturto]

Hi! Just stumbled upon the thread...

Any hints on Haskell (except the obvious one "learn to use it"). The language is really sweet and it's growing on me more and more.

True. Here is a sensible prioritized list of Haskell resources

https://github.com/bitemyapp/learnhaskell

But nothing beats jumping headfirst into an alien codebase, obviously.

That's actually the list I'm currently working my way through. Still at the very beginning of course, but far enough that I want to start digging around some real code.

BTW, congratulations on choosing the cleaner, but harder, way of using
the engine, namely by keeping your game content in a separate Haskell package
from the start.

It's always nice to be able to stand on the shoulders of a giant and use code that has been built before. I suspect that in the long run this way will be easier, since I can update the engine I'm using when you release new versions. Haven't had time to do that with the latest release yet, but it's on my list of things to do.

Here's a screen shot just a moment before quine manages to kill the captain and the game ends.

Heh, YASD. Nice.

Here's a short video of the current game: https://www.youtube.com/watch?v=PzyTw1g65Lg It's still quite similar with the LambdaHack, but I'm slowly working my way through how game content is defined and what kinds of tricks the engine can do. I should for example change the UI a bit, so it doesn't look like a direct copy of LambdaHack. As you showed with Allure of Stars, this is possible.

I have been wondering if there exists a way to make them move autonomously and follow the player and fight when given a chance.

By default monsters (aliens, robots, animals) do that. There's nothing stopping you
from adjusting your human faction to move like that or creating yet another
faction with this behaviour. Just tweak this line (from the 0.2.14 codebase)
to assign 'allSkills' to a non-leader actor:

https://github.com/LambdaHack/LambdaHack/blob/7e0776face9d4f0fbe8743b75da6067d3c7deb80/GameDefinition/Content/FactionKind.hs#L27

Or you can set 'meleeAndRanged' and then the heroes will remain immobile,
but will be able to reaction-shoot (or rather reaction-throw) all the time.

Nice, I will try that and see what happens. What about if I wanted to write a completely new AI for some actors, how should I approach that? I would like to have some monsters that don't explore the level, but remain within a room and sneak by the walls.

[Man of Letters]

Here's a short video of the current game: https://www.youtube.com/watch?v=PzyTw1g65Lg

Yay, fun, you've beaten me to it. Heh, it's great to be surprised by the game's content for a change (being surprised by unintended consequences of my own content does not quite count ). I'd love to play-test the engine using your game.

It's also great to see how people new to the game play it. E.g., you wisely keep you team members mostly together (except for some solo exploration missions), but usually not too close (danger due to grenades in newer versions). I wonder if you use running (it's not clear from the video, but I suspect you don't)? It's done via Shift-direction. If you use the numeric keypad, Num Lock may need to be (de)pressed. Running is good, because when a monster is spotted, running stops, so there is no risk of one-keypress-too-many YASD. When there is mouse support, running will be easier (just point and click), but for now I wonder if the first help screen should spend more words pointing it out or if something doesn't work well enough.

What about if I wanted to write a completely new AI for some actors, how should I approach that? I would like to have some monsters that don't explore the level, but remain within a room and sneak by the walls.

That sounds like a proper engine extension. We'd need to open a github issue and brainstorm a bit at our leisure. E.g., what if there are no rooms on the level? What if the monster is generated in a corridor? What is the story explanation for the behaviour? E.g., does the monster fear dark and only stays in lit rooms or does it remember it's birthplace and never goes beyond it's small territory? Or is it an intelligent assassin? But if so, shouldn't it rather hide in dark corridors? Or always try to keep out of melee range (I think monsters that don't melee already do that) or always try to stay not visible (AI already sometimes drops lights sources to ensure that, but it could also try to actively look for shadows). Etc.

Anyway, sounds like the module Game.LambdaHack.Client.AI.PickTargetClient would be involved. The bad news is that it's a rather dirty piece of code and that the whole target picking will be overhauled. The good news is that it should be a relatively simple change. You prepare it in your fork of the engine, make a pull request, I accept it and we are done.

You could define something close by removing the AbTrigger ability from the actor kind's skillset. The ability is responsible, in particular, for opening doors. So if the monster is generated within a room where all exits have doors (most rooms are like that --- you can control it via content on a per-cave-kind basis), it will remain in the room until another actor opens the door. A more brutal tweak is to remove the AbMove, which makes the actor immobile (except that it can exchange places with others; remove AbDisplace to disable that as well).

P.S. If we decide the feature is too specific/heavy/silly for the generic engine (very unlikely ), you can also add it locally when tying the knot of the Main module of your game, by overriding some modules from the library. It's *much* more work than adding such a feature to the engine itself and we'd need to expose and generalize some more of the engine internals (which is a good idea, anyway), but it is and should be possible. This is an engine library, not a black box proprietary engine, after all.

[Man of Letters]

BTW, I said that the game content API should be more stable after the 0.2.14 release, but I lied. I've just rewritten and simplified the Player (team capabilities definition) component of ModeKind (game mode definition) and it will still undergo minor changes in the next few days. Other than that I hope to keep the API stable and focus on the internals. The blame goes entirely to tuturto for his inspiring comments.

So, for development I'd advise to use the master branch of the github repo instead of the official release. I push only mildly tested things to master, plus there is the continuous integration via travis, so that should be fairly safe. As for catching up with the change in the .cabal file, the whole file can be safely copied from the Allure of the Stars repo, which is kept in sync with LambdaHack. I plan to publish the next release (and perhaps a couple after that) fairly soon (a month or two apart, I guess).

[tuturto]

I have upgraded to the latest version of LambdaHack and the game starts. Still need to play around a bit and see that everything is still working as I would it like to work. I must say that doing the upgrade taught me quite a bit more about how the system is laid out, since I had to modify multiple files and dig out what the changes were and how I could incorporate them into my game. Now that I have the newer version of the engine, I can add more varied content too, which is a big bonus.

It's also great to see how people new to the game play it. E.g., you wisely keep you team members mostly together (except for some solo exploration missions), but usually not too close (danger due to grenades in newer versions). I wonder if you use running (it's not clear from the video, but I suspect you don't)? It's done via Shift-direction. If you use the numeric keypad, Num Lock may need to be (de)pressed. Running is good, because when a monster is spotted, running stops, so there is no risk of one-keypress-too-many YASD. When there is mouse support, running will be easier (just point and click), but for now I wonder if the first help screen should spend more words pointing it out or if something doesn't work well enough.

I'm aware of the run option, but haven't gotten used to it yet, I guess it's mostly just a habit. It certainly makes it harder to make one step too many, like I often too. Especially when playing with a squad of privateers. The first help screen explains it sufficiently well I would think.

That sounds like a proper engine extension. We'd need to open a github issue and brainstorm a bit at our leisure. E.g., what if there are no rooms on the level? What if the monster is generated in a corridor? What is the story explanation for the behaviour? E.g., does the monster fear dark and only stays in lit rooms or does it remember it's birthplace and never goes beyond it's small territory? Or is it an intelligent assassin? But if so, shouldn't it rather hide in dark corridors? Or always try to keep out of melee range (I think monsters that don't melee already do that) or always try to stay not visible (AI already sometimes drops lights sources to ensure that, but it could also try to actively look for shadows). Etc.

Anyway, sounds like the module Game.LambdaHack.Client.AI.PickTargetClient would be involved. The bad news is that it's a rather dirty piece of code and that the whole target picking will be overhauled. The good news is that it should be a relatively simple change. You prepare it in your fork of the engine, make a pull request, I accept it and we are done.

I'm interested in this, because I would like to create varied creatures, which behave differently. In pyherc, I have rats and beetles, that behave in a similar way. Both have their preferred areas, where they patrol around and when player comes too close, they will attack.

Like, for rats I define AI like this (parens warning):

Code: [Select]

(defn patrol-area? [level location]
  "rats prefer rooms"
  (and (next-to-wall? level location)
       (not (corridor? level location))))

(def rat-act (patrol-ai patrol-area? 4))

And for beetles just (they have slightly worse eye sight than rats, thus 3 for detection range):

Code: [Select]

(def beetle-act (patrol-ai open-area? 3))

patrol-ai takes care of actual logic needed for moving into patrol area, moving around there and attacking possible threats. I just create suitable versions of it by feeding a function to it that can tell what the patrol area actually is. Nice thing is that if there is a big room with couple of rats and beetles, they will patrol different areas. Skillful player might be able to sneak around them without being detected, but a mistake will cause them to attack him.

P.S. If we decide the feature is too specific/heavy/silly for the generic engine (very unlikely ), you can also add it locally when tying the knot of the Main module of your game, by overriding some modules from the library. It's *much* more work than adding such a feature to the engine itself and we'd need to expose and generalize some more of the engine internals (which is a good idea, anyway), but it is and should be possible. This is an engine library, not a black box proprietary engine, after all.

I think this would be a good approach. Even if the engine would contain some basic AI routines in itself, other developers might want to roll out their own specific AIs for unique creatures. I'll tinker around a bit and try figure out things a bit before opening a ticket in github. Development will be slow in any case, because I'm still learning how the language is supposed to work

[Man of Letters]

I have upgraded to the latest version of LambdaHack and the game starts.

Oh, great, then don't bother looking at the master branch in the github repo. The next release will come rather soon anyway.

I'm interested in this, because I would like to create varied creatures, which behave differently.

OK, that would probably mean the creatures have to be from the animal faction. That's because the monster faction (the dungeon defenders faction) is a playable faction and so the AI is supposed to emulate a human playing the faction. And a human would not patrol a room, but explore for loot and then wait for some team members to spawn or gather and attack in a group. Currently, the animal faction chases enemies, if visible, and otherwise just dumbly walks around --- this should be made more varied and interesting indeed.

In pyherc, I have rats and beetles, that behave in a similar way. Both have their preferred areas, where they patrol around

OK, sounds good: find a suitable territory and patrol it. Some real life animals do that.

and when player comes too close, they will attack.

OK, so that's another needed extension: an aggressiveness flag for an actor kind. Currently AI usually tries not to melee if there are no other team members close.

       (not (corridor? level location))))

That's another needed extension: we have to define what a corridor is, e.g., in a checker-board room, is every empty tile a corridor tile?

And for beetles just (they have slightly worse eye sight than rats, thus 3 for detection range):

That's OK, sight range is already implemented.

patrol-ai takes care of actual logic needed for moving into patrol area, moving around there and attacking possible threats. I just create suitable versions of it by feeding a function to it that can tell what the patrol area actually is. Nice thing is that if there is a big room with couple of rats and beetles, they will patrol different areas. Skillful player might be able to sneak around them without being detected, but a mistake will cause them to attack him.

That's great. Sneaking around and stealth are welcome diversions from the usual hack and slash.

Even if the engine would contain some basic AI routines in itself, other developers might want to roll out their own specific AIs for unique creatures.

Indeed. There's one more possibility: when we implement some routines in the engine, we can then generalize and push them out to content --- have a per-game file with named Haskell AI subroutines and use them, by name, in other parts of the content, e.g., actors or places (rooms) (weak-willed animals in such a room behave according to that AI).

[tuturto]

In pyherc, I have rats and beetles, that behave in a similar way. Both have their preferred areas, where they patrol around

OK, sounds good: find a suitable territory and patrol it. Some real life animals do that.

It could also be a robot that has been programmed to patrol an area, or an guard man, options are very wide depending on the theme of the game. The idea I'm after is emergent game play. Small and simple rules will create complex behaviour when mixed together.

       (not (corridor? level location))))

That's another needed extension: we have to define what a corridor is, e.g., in a checker-board room, is every empty tile a corridor tile?

In pyherc I have every location that has wall on two opposite sides (but not on any others) considered as a corridor. This has the flaw that bends are not corridors, although they should be. Could also be any location that has exactly 6 walls around it and free locations aren't next to each other.

Indeed. There's one more possibility: when we implement some routines in the engine, we can then generalize and push them out to content --- have a per-game file with named Haskell AI subroutines and use them, by name, in other parts of the content, e.g., actors or places (rooms) (weak-willed animals in such a room behave according to that AI).

This sounds like what I was after.

[tuturto]

I was setting up factions and players and have couple of questions.

This is how player is defined:

Code: [Select]

playerHero = Player
  { playerName = "Space Privateers"
  , playerFaction = "hero"
  , playerIsSpawn = False
  , playerIsHero = True
  , playerEntry = -1
  , playerInitial = 3
  , playerLeader = True
  , playerAI = False
  , playerUI = True
  }

What does playIsSpawn, playerEntry, playerLeader and playerUI control?

playerIsHero I think is used to mark which player is controlled by human in the campaign mode? playerInitial is amount of actors initially in the game and playerAI sets if this player is controlled by AI or not I think?

On the other hand, when defining a faction:

Code: [Select]

hero = FactionKind
  { fsymbol       = '1'
  , fname         = "hero"
  , ffreq         = [("hero", 1)]
  , fSkillsLeader = allSkills
  , fSkillsOther  = meleeAdjacent
  }

fSkillsLeader and fSkillsOther are skill lists used by the leader (often controlled by the human player) and others in faction. But what significance does ffreq have?

[Man of Letters]

The idea I'm after is emergent game play. Small and simple rules will create complex behaviour when mixed together.

Spot on.

I was setting up factions and players and have couple of questions.

This is how player is defined:

Each field is documented in

https://github.com/LambdaHack/LambdaHack/blob/v0.2.14/Game/LambdaHack/Content/ModeKind.hs

However, that's precisely the bit of content API that is changed for the next version
(in particular FactionKind is merged into Player, though the general principles mostly stay the same)

https://github.com/LambdaHack/LambdaHack/blob/LambdaHack_Content_API_v0.5.0.0/Game/LambdaHack/Content/ModeKind.hs

(The tag LambdaHack_Content_API_v0.5.0.0 marks the version with the API
that should remain stable for a couple more releases, up to and including version v0.5.0.0 of the engine.
Sorry again for breaking the API, the new version is already on master branch of LH and Allure and the content API types and comments
should not change until after v0.5.0.0 (the behaviour will change subtly, e.g., due to fixing bugs or to the follow-the-leader AI
override being fleshed out (now it only works sensibly for AI teams))).

What does playIsSpawn, playerEntry, playerLeader and playerUI control?

playIsSpawn marks dungeon dwellers and playerIsHero marks humans.
playerEntry is the level the initial actors of that player start on.
playerLeader marks if the team has a leader at all, which mostly just means
the faction is potentially playable (e.g., animals are not).
playerUI means the actions of the team are displayed on the screen

playerInitial is amount of actors initially in the game and playerAI sets if this player is controlled by AI or not I think?

Yes, exactly. If a player is both playerUI and playerAI, the AI aspect can be turned off with ESC (and on again with Control-Shift-a). Try it e.g., with 'make frontendCampaign", which is great for testing your game.

fSkillsLeader and fSkillsOther are skill lists used by the leader (often controlled by the human player) and others in faction. But what significance does ffreq have?

It lists the actor groups that constitute the faction. Each actor belongs to a few groups, listed in ifreq in ItemKindActor. (In the new API this is simplified and each player controls exactly one group.)

P.S. I forgot the most important bit: if a faction has a leader, then the level where the leader resides is active --- actors move on that levels. So, if you have hero, monster and animal factions and the last one doesn't have a leader, then actors move on the levels where the hero or the monster leader resides and so the two factions control which levels are active. The animal faction actors can move only as long as their level is visited by the hero or monster leader (or as soon as they spawn on a level with a leader --- spawning is controlled via cactorFreq field of CaveKind, actor groups are listed together with relative frequencies; cactorCoeff in the new API determines the absolute frequency of spawning).

[Man of Letters]

The engine supports having multiple units under command of the player. So far it looks to me that only one of them is moving at any given time, while others just stand still. I have been wondering if there exists a way to make them move autonomously and follow the player and fight when given a chance.

I've just finished and pushed to master branch a basic implementation of the follow-the-leader AI. It can be enabled for a faction via foverrideAI in the new content API and will be officially available in the next release. The test 'make frontendSafari' uses it.

The standard AI, of the 0.2.14 release, keeps team members close only when the level is fully explored. Otherwise, it sends actors away to explore and gather loot ASAP, before monsters do. In the follow-the-leader AI, team members swarm towards the leader's target or, if target not set, towards the leader position. If they start fighting an enemy or if they stand on items, they will finish fighting/picking up before following the leader again. But they won't detour towards enemies nor items nor unknown tiles to explore. In the future, it may be interesting to mix the two AI somehow and, e.g., let team members detour towards interesting things in a given radius only.

So, now we have 3 AIs (the third one is used for leader-less factions, such as animals, and is rather dumb). It would be great to generalize and parametrise them somehow, to be able to toggle them on the fly, as well as to define them as content and use in actor, faction, room and other content definitions. This is ambitious, but rather standalone task, so I guess I will create an issue on github for it at some point. It overlaps significantly with only one other task: target pool (having a pool of targets for the whole faction and assigning them to actors continuously instead of, as it is now, each actor having an independently chosen and fixed target, leading to duplication of effort). Code quality should benefit a lot from adding this feature, too.

[tuturto]

Lots of cool AI stuff..

That sounds really great. I like the idea that I don't have to move each and every member of the squad all the time. These changes should make playing much more fun I think.

In the meantime (using the latest release of LambdaHack) I have defined factions and players and started working on some items. There are couple grenades, that are basically just potions that one can't drink.

Then there's still levels, places, creatures and maybe even rules to define. And lots more content on everywhere.

Sorry again for breaking the API, the new version is already on master branch of LH and Allure and the content API types and comments
should not change until after v0.5.0.0 (the behaviour will change subtly, e.g., due to fixing bugs or to the follow-the-leader AI
override being fleshed out (now it only works sensibly for AI teams))).

No worries, evolving APIs are a normal thing. I'm looking forward on the new features the next version will have.

I'm hoping/trying to finish first rough version of the game in a week or so and upload it to Hackage. Should also look into prebuilding binaries, but I have access only to a Linux machine, where I can do building so it'll be somewhat limited. Windows binaries would be great, but maybe in the future.