Messages

61

Programming / Re: LambdaHack

« on: August 03, 2014, 10:44:50 PM »

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.

I've just added (to branch master) a stricter validation of content and some crude text messages given
when the content is detected invalid. Should make the process less painful.

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

I'm away 13--23 Aug, so I think I will release LambdaHack 0.4.9.0 a couple days before I go.
If you base your release on that version,  you can state "LambdaHack >= 0.4.9.0 && < 0.6.0.0"
in your .cabal file, because the content API won't break till 0.6.
But "release early, release often", so you may as well release a version based on 0.2.14
--- it's relatively stable as far as I can say so far.

Edit: Actually "LambdaHack >= 0.4.9.0 && < 0.5.1.0" is safer, but the interval should still take
many months and quite a few versions of LH.

I'm hoping/trying to finish first rough version of the game in a week or so and upload it to Hackage.

Splendid, whenever it eventually happens. You may wish to announce that on "New Roguelike Releases"
and "Recently Updated Roguelikes" on http://www.roguebasin.com.

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.

I have the previous Ubuntu LTS (12.04.4), so I can build binaries for you there.
I wonder if it makes sense to try and build statically linked binaries for download.
Normally, with GHC 7.8 I get binaries that are reported by `file` like that:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped

Windows binaries would be great, but maybe in the future.

I haven't yet figured out cross-compilation on Windows nor OSX (not sure if anybody tried the latter), so I can't help with that.

62

Programming / Re: LambdaHack

« on: August 01, 2014, 11:42:31 PM »

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.

63

Programming / Re: LambdaHack

« on: July 31, 2014, 05:44:09 AM »

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

64

Programming / Re: LambdaHack

« on: July 29, 2014, 01:18:15 PM »

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

65

Programming / Re: LambdaHack

« on: July 29, 2014, 10:13:28 AM »

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

66

Programming / Re: LambdaHack

« on: July 28, 2014, 02:21:58 PM »

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.

67

Programming / Re: LambdaHack

« on: July 27, 2014, 09:15:03 AM »

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!

68

Traditional Roguelikes (Turn Based) / Re: LambdaHack/Allure of the Stars

« on: December 05, 2013, 04:35:37 PM »

Hey, that ARRP 2013 was absolutely by chance!

Thanks to whomever adds these announcements. Even if it's a bot --- than you again kind (electronical) being and please come over and compete with my AI players!