Author Topic: LambdaHack  (Read 31829 times)

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #15 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.

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

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

Quote
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

Quote
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.
« Last Edit: August 06, 2014, 11:25:14 PM by Mikon »

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: LambdaHack
« Reply #16 on: August 05, 2014, 09:46:59 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.

This is always nice. While the current messages aren't always very clear, they are really helpful while developing a game. It's much easier to test things when possible problems are reported on a start up and not when the problem actually might occur.

Quote
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

Static ones would be easier for end users. With dynamic ones there's always the chance that the system where game is being run has incompatible libraries. I looked briefly into building a static version and added following to ghc options:
Code: [Select]
-static -optc-static -optl-static
In the linking phase, I got following errors:
Code: [Select]
Linking dist/build/SpacePrivateers/SpacePrivateers ...
/usr/bin/ld: cannot find -latk-1.0
/usr/bin/ld: cannot find -lgdk_pixbuf-2.0
That's of course because neither of those libraries are shipped with static versions by default (I'm running Ubuntu 14.04). Probably next step would be to compile static versions and use those while linking the game. I'm not going to pursue that right now, but it's something to keep in mind for the future.
Everyone you will ever meet knows something you don't.
 - Bill Nye

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #17 on: August 06, 2014, 05:08:31 PM »
This is always nice. While the current messages aren't always very clear, they are really helpful while developing a game. It's much easier to test things when possible problems are reported on a start up and not when the problem actually might occur.

I'm glad you think so, too. :)
I'm ready to publish LambdaHack 0.4.9.0. I may lazily test a couple more days
or publish at once if that's in any way helpful to you.

Quote
Static ones would be easier for end users.

Actually, I've just found this

http://stackoverflow.com/questions/8657908/deploying-yesod-to-heroku-cant-build-statically/8658468#8658468

and here is some more context

http://stackoverflow.com/questions/5953199/create-a-static-haskell-linux-executable

So it's not obvious if static libraries are better, though in our case they may be,
since we depend on lots of shared libraries:

Code: [Select]
~/r/LambdaHack$ ldd /tmp/LambdaHack
linux-vdso.so.1 =>  (0x00007fff055c0000)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fc52f925000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007fc52f673000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007fc52f450000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fc52f230000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007fc52efe7000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fc52ed97000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fc52eaa2000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fc52e8a0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc52e697000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc52e480000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc52e27c000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fc52e00d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc52dd11000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc52daf4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc52d8dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc52d51d000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007fc52d311000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fc52cfdb000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fc52cdd5000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007fc52cb17000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fc52c7c7000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007fc52c59d000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fc52c367000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fc52c155000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fc52bf4b000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fc52bd48000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fc52bb37000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fc52b92f000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fc52b725000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007fc52b521000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fc52b31e000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fc52b119000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fc52af11000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc52acd4000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc52ff80000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fc52aa37000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fc52a819000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007fc52a581000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fc52a359000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fc52a156000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fc529f4b000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fc529d2c000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fc529b10000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fc5298e5000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fc5296e2000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fc5294db000)

What is obvious, however, is that if we build with shared libraries, we should do that
on my old system and test on yours, since new libs are supposed to be compatible
with old binaries, but not the other ways around.

Quote
In the linking phase, I got following errors:
Code: [Select]
Linking dist/build/SpacePrivateers/SpacePrivateers ...
/usr/bin/ld: cannot find -latk-1.0
/usr/bin/ld: cannot find -lgdk_pixbuf-2.0

I didn't manage to get that far regardless of the combination of options.
The errors, mentioning "relocation R_X86_64_32", suggest some code compiled
for 32 bits is involved, but this may be any other kind of wierd bug, as well.
I'm on GHC 7.8.3 and on 64 bits Ubuntu 12.04.4.

I haven't tested the --whole-archive option yet,
but I don't quite understand how it differs from static linking
(does it link statically only some libs? or bundles shared libs with the binary?)

http://stackoverflow.com/a/12564602

I suppose I will just publish shared libs binaries with 0.4.9.0 and ask you
to try if they work for you.

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: LambdaHack
« Reply #18 on: August 07, 2014, 10:04:34 AM »
I'm glad you think so, too. :)
I'm ready to publish LambdaHack 0.4.9.0. I may lazily test a couple more days
or publish at once if that's in any way helpful to you.

No need to rush I guess. I probably try to finish and publish first version of the game using the current version of LambdaHack and update to the next one after that. I'm thinking of declaring the current version I have what I'm going to release (not that there's that much of new content there yet, but it's a start). Still need to edit all guides and stuff that still read what LambdaHack came with.

Actually, I've just found this

http://stackoverflow.com/questions/8657908/deploying-yesod-to-heroku-cant-build-statically/8658468#8658468

and here is some more context

http://stackoverflow.com/questions/5953199/create-a-static-haskell-linux-executable

Hm.. that's interesting. I think that it would still be worthwhile to try to make a statically linked binaries. If for nothing else, then for the sake of an exercise :) And as you pointed out, LambdaHack has quite big list of dependencies and having to list all of them for end users to install before playing is bit tedious.

What is obvious, however, is that if we build with shared libraries, we should do that
on my old system and test on yours, since new libs are supposed to be compatible
with old binaries, but not the other ways around.

Sure, I would love to help testing things. I'm running a 32-bit system, but it should be possible to make 32-bit binaries in 64-bit system as far as I understand.

Everyone you will ever meet knows something you don't.
 - Bill Nye

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #19 on: August 07, 2014, 10:30:28 AM »
Quote
I probably try to finish and publish first version of the game using the current version of LambdaHack and update to the next one after that. I'm thinking of declaring the current version I have what I'm going to release (not that there's that much of new content there yet, but it's a start).

Great. So far, I like a lot, e.g.,  your general setting and the playful
but plausible names of things. :)

Quote
Hm.. that's interesting. I think that it would still be worthwhile to try to make a statically linked binaries. If for nothing else, then for the sake of an exercise :) And as you pointed out, LambdaHack has quite big list of dependencies and having to list all of them for end users to install before playing is bit tedious.

Yep. Perhaps ideally we should include all but glibc, but I don't know if that's possible
and in what way (even bundling the shared libs in subdirectories may make sense, actually).
I wonder what non-Haskell HOWTOs say about that.

Quote
I'm running a 32-bit system, but it should be possible to make 32-bit binaries in 64-bit system as far as I understand.

Ah, that may explain why you didn't have the 32bit-related errors that I encountered.
I guess I can make 32bit binaries, but I probably need 32bit versions of the libs installed.
I will try that. Anyway, I certainly makes sense to release both 64bit and 32bit binaries.

Have fun and no rush, indeed. :)

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #20 on: August 09, 2014, 07:20:19 AM »
Congratulations on the first release!

https://hackage.haskell.org/package/SpacePrivateers

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: LambdaHack
« Reply #21 on: August 09, 2014, 09:22:00 AM »
Congratulations on the first release!

https://hackage.haskell.org/package/SpacePrivateers

Thanks, and thank you for providing 64-bit binaries. The release is a bit rough, just simple readme, changelog and binaries. Next one should be a bit more fleshed out hopefully.

But before that, there's plenty things to do, like upgrading to the new version of LambdaHack when it comes out and adding more content.
Everyone you will ever meet knows something you don't.
 - Bill Nye

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: LambdaHack
« Reply #22 on: August 16, 2014, 10:19:25 AM »
I upgraded to the latest version of LambdaHack (0.4.99.0) without much of a problem. Game compiles and runs now, but I haven't added any new content yet. One new idea I have is a sect of tech-priests, who slowly wander through the ship, following their leader.

New validation routines saved my back couple of times, when I had inconsistent definitions for caves, modes and players.
Everyone you will ever meet knows something you don't.
 - Bill Nye

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #23 on: August 30, 2014, 11:12:52 AM »
Edit: this post has the AutoLeader details wrong. See a post below for a correction.

Quote
I upgraded to the latest version of LambdaHack (0.4.99.0) without much of a problem.

I'm glad to hear that!

Quote
One new idea I have is a sect of tech-priests, who slowly wander through the ship, following their leader.

This should be doable as on this line

https://github.com/LambdaHack/LambdaHack/blob/v0.4.99.0/GameDefinition/Content/ModeKindPlayer.hs#L66

which is documented at

http://hackage.haskell.org/package/LambdaHack-0.4.99.0/docs/Game-LambdaHack-Content-ModeKind.html#t:LeaderMode

but I'd better explain anyway. :)

LeaderAI means the faction has a leader and it's controlled by AI, True means
the leader will spontaneously switch to an actor on another level from time to time
(so you'd probably want to set False there), and False means the leader will never spontaneously
change to another actor on the same level (but it may be forced to switch, e.g., if the old leader dies).
Normally it's good for a faction to switch leaders, because the new leaders tend to be closer
to enemies/loot/etc. But, for role-playing reasons, your tech-priests need

Code: [Select]
  fleaderMode = LeaderAI $ AutoLeader False False

and this also brings some variety compared to other factions.

You'd also need to set tactic, as on this line

https://github.com/LambdaHack/LambdaHack/blob/v0.4.99.0/GameDefinition/Content/ModeKind.hs#L165

which sets the AI tactics for the party to follow-the-leader. BTW, you can manually change the tactics
of your party with CTRL-T. This is also useful for testing (e.g., make frontendSafari), in that you can
take manual control of the tested AI party with ESC, change tactics and resume the AI with CTRL-A.

Do you still want your hero party to follow their leader automatically? With LH 0.4.99.0 it's easier to do
and probably much closer to your intent. To be precise, your other party members follow the leader's target,
and if not set, only then they follow the leader's position. See above how to set that.
« Last Edit: September 01, 2014, 01:12:20 AM by Mikon »

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: LambdaHack
« Reply #24 on: August 31, 2014, 07:35:10 PM »
Thanks for the clear explanation. Haddock is really nice, but nothing beats a well written example. However, I managed to get my game into state where it doesn't run properly anymore, but terminates with an error:
Code: [Select]
Contract failed and the following is to blame:
  ( "unexpected leader"
, ( UpdLeadFaction
      (FactionId (-2))
      (Just ( ActorId 10 , Nothing ))
      (Just ( ActorId 10 , Just (TPoint (LevelId (-1)) ( 60 , 5 )) ))
  , Just (ActorId 12)
  )
)
I can't spot why the changes done in this change set would cause such behaviour. I adds a new player and faction, but there isn't really anything special there that would cause the faction not to have a leader.

When I get this sorted out, I'll try your suggestion making rest of the squad to follow the player. That would be quite nice change, I would think.
Everyone you will ever meet knows something you don't.
 - Bill Nye

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #25 on: September 01, 2014, 01:06:31 AM »
Quote
I can't spot why the changes done in this change set would cause such behaviour.

You are right, your commit is fine. Congratulations, you've discovered a bug in the engine. ;)

I've now fixed the bug in the dev version but, fortunately, it should only mildly affect you
even if you use the released version. I have wrongly advised you to use AutoLeader True True
for your players to maximize the number of leader changes done by AI (which are usually beneficial).
In fact, for technical reasons, the correct incantation is AutoLeader True False.
If you use it, the bug will not manifest. Unfortunatley, for playerTechCult you'd need
AutoLeader False True, but that one would trigger the bug. So, for now, your cult
will change it's leader from time to time, I'm afraid. Technical details are at the end of this post.

BTW, _meleeAndRanged, though a fine choice for, e.g.,  playerMerchant,
does not fit playerTechCult, because it means the non-leader cultists will never move,
only melee or reaction-fire. You can spot such content errors by defining a few debug modes
where playerHero is controlled by AI and, e.g., playerTechCult has a UI client so that you can observe
how it behaves. See, e.g., 'make frontendDefense'.

fcanEscape = True means if any cultist reaches the spaceship exit, they win the game.
That is fun, a race to the exit, but to have a chance, either move their starting point down,
or move the spaceship exit down (see Allure of the Stars, where exit is at the opposite end of the ship).

fneverEmpty = True is weird for a faction that spawns, because as soon as
there is no actor left, the faction is announced to be defeated, but then, some turns later
another actor may spawn. I have no clue what happens then (I hope not a crash).
I will have to check the code, but perhaps in the future we should just try to cross-verify
fneverEmpty and cactorFreq in CaveKind and reject such content.
Anyway, thank you for the unexpected use case. :)

You may want to use LeaderNull instead of LeaderAI for most (half?) of your factions,
because each leader keeps a single level active. That means that up to 5 AI factions
may be concurrently exploring the dungeon on 5 different levels. There'll be no loot left before
you heroes get anywhere. :) TPatrol would help, but it's not yet implemented and there's even
less sense in a faction actively patrolling a level where no other faction has any actors.
With as many factions as you have, spreading out and establishing patrol areas
may be easily done when other non-human factions with leaders visit a level,
so that the patrolling faction is ready to get activated when the heroes come.


Technical details
-------------------

My wrong advice came from too simplified documentation (or too complex semantics),
to the point that it fooled even myself, after a particularly refreshing vacation.
The expanded documentation is below. The point is that in the current setup,
AI leader level changes are done exclusively by the server (hence True
in AutoLeader True False) and extensive AI leader switching without level changes
is done only by the client (hence False).

In the future, this should be more symmetric, with both kinds of leader changes available
both on the server and on the client. The server version would be more random, used as a mild drawback,
and the client version would be meticulous --- in case of leader level change, it would
maximize the chance of spawning a new party member, if the player that can spawn
on any levels (as specified per-level in CaveKind).

Code: [Select]
data AutoLeader = AutoLeader
  { autoDungeon :: !Bool
      -- ^ leader switching between levels is automatically done by the server
      --   and client is not permitted to change leaders
      --   (the frequency of leader level switching done by the server
      --   is controlled by @RuleKind.rleadLevelClips@);
      --   if the flag is @False@, server still does a subset
      --   of the automatic switching, e.g., when the old leader dies
      --   and no other actor of the faction resides on his level,
      --   but the client (particularly UI) is expected to do changes as well
  , autoLevel   :: !Bool
      -- ^ leader switching within a level is automatically done by the server
      --   and client is not permitted to change leaders
      --   (server is guaranteed to switch leader within a level very rarely,
      --   e.g., when the old leader dies);
      --   if the flag is @False@, server still does a subset
      --   of the automatic switching, but the client is permitted to do more
  }
« Last Edit: September 01, 2014, 01:09:19 AM by Mikon »

CaptainKraft

  • 7DRL Reviewer
  • Rogueliker
  • *
  • Posts: 60
  • Karma: +0/-0
    • View Profile
Re: LambdaHack
« Reply #26 on: September 01, 2014, 06:45:26 PM »
Curse you all for making me want to do some more Haskell programming!
Build a man a fire, and he'll be warm for a day.
Set a man on fire, and he'll be warm for the rest of his life.

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: LambdaHack
« Reply #27 on: September 01, 2014, 07:05:12 PM »
Thanks, I got it working now :) I made a note on the source to update techCult after the next release is made. I also adjusted the skills of the factions a bit. Mostly I'm still trying to get a feel of the engine and trying out different things. Eventually tech cult will be moved to a special level made just for them. At that time I'll switch to LeaderNull for them I suppose, so they'll start wandering around the level only after player enters the special level.

BTW, I switched the default tactic for player faction to TFollow and also tried the CTRL+T to check various tactics available. I like sending team to explore and after they locate enemy, pull everyone together and tackle the enemy together. This is now much more fun to play than having to move each team member separately.

Curse you all for making me want to do some more Haskell programming!

Come to the non-strict side, our monads are filled with pure deliciousness :) But seriously, have you had a look at LambdaHack? I don't know much Haskell and I'm having trouble making even simplest things, but I'm having blast with it already. I'm currently trying to learn enough, so that I could help tackling the simplest tasks for it.
Everyone you will ever meet knows something you don't.
 - Bill Nye

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #28 on: September 01, 2014, 07:40:58 PM »
Quote
Mostly I'm still trying to get a feel of the engine and trying out different things.

Sure, have fun do bold things. :)

Quote
Eventually tech cult will be moved to a special level made just for them.

Actually, you can do that already. Start them at that level. Don't give them the AbTrigger skill (so that can't use stairs so they won't escape the level). In Content.CaveKind tweak the level, e.g., forbid other monsters spawning there and in cavesCampaign assign the cave to the level number. I fully expect you to trigger a bug or two, but that's just my hidden bonus for all this free comradely support. ;)

The LeaderNull idea is also neat, for this faction or for another. I haven't thought about that. In this way you race to get the items on the level before the enemy gets them. You only need to make sure the faction doesn't spawn on any other level (or on no level at all).

Quote
BTW, I switched the default tactic for player faction to TFollow and also tried the CTRL+T to check various tactics available. I like sending team to explore and after they locate enemy, pull everyone together and tackle the enemy together. This is now much more fun to play than having to move each team member separately.

Oh, I'm glad. I'm a perfectionist, so I detest my heroes making non-optimal moves and getting into each other's way. But I guess many people find it fun and strongly prefer faster play, just as you do. So, Space Privateers may become a hit much easier than Allure of the Stars, at least unless I add mouse selection and other tweaks to make manual moving of groups of heroes easier. Or perhaps you'll specialize in large battles and general mayhem and I'll have to focus Allure of the Stars on stealth, where every single move really matters.

Curse you all for making me want to do some more Haskell programming!

Muahaha. Resistance is futile. Come over and share your secret plans.

Man of Letters

  • Rogueliker
  • ***
  • Posts: 68
  • Karma: +0/-0
    • View Profile
    • Email
Re: LambdaHack
« Reply #29 on: September 01, 2014, 08:19:24 PM »
Quote
The LeaderNull idea is also neat, for this faction or for another. I haven't thought about that. In this way you race to get the items on the level before the enemy gets them. You only need to make sure the faction doesn't spawn on any other level (or on no level at all).

I got carried away. This won't work if other AI factions can use stairs and visit the special level --- that would trigger spawning or movement and exploration of the faction that inhabits the special level before heroes get there.

This gives me an idea to do just that in Allure --- have only animals and robots until certain level and don't introduce aliens with any pre-spawned actor. If I tweak animals and robots to avoid exploring other levels, I can surprise the player by a sudden onset of aliens once he wakes them up (that is, makes them start spawning, by visiting a level where they spawn) and then they start exploring the whole dungeon and attacking en masse.

Edit: typos and clarifications.
« Last Edit: September 01, 2014, 10:53:19 PM by Mikon »