7DRL idea - puzzle roguelike
Antoine
Puzzle game roguelike - You have a fixed number of moves to complete
each (pre-designed) maze. Only just enough to finish the level with
optimal play. If you run out of moves the ceiling falls in. Monsters
move deterministically (in predictable patterns), all monsters hit for
1 HP, you have 3 HP which replenish whenever you complete a map and
move on to the next one.
Kinda like DROD, but with more roguelike elements (consumables, hack-
and-back, LOS, etc).
A.
Radomir Dopieralski
I think that Furai No Shinren I on the Game Boy had something like this.
It was an optional side-game, and each puzzle was designed to teach you
another aspect of the game mechanics -- you had to use it in order to
finish the puzzle. So it worked a little like a tutorial.
--
Radomir Dopieralski, http://sheep.art.pl
Mike Blackney
Sounds to me like a nice addition to another RL. Like a bonus mode if
you feel the original isn't challenging enough.
--
Mike Blackney
Grillen Verboten!
Ido Yehieli
>
> Puzzle game roguelike - You have a fixed number of moves to complete
> each (pre-designed) maze. Only just enough to finish the level with
> optimal play. If you run out of moves the ceiling falls in.
I hope you are not planning permadeath for such a game... It sounds like
you'd have to die several times every level before learning how to
pass it properly.
-Ido.
Gerry Quinn
ido.y...@chello.at says...
Especially with LOS, if by that you mean to imply FOV! If the player
cannot be expected to work out everything in advance, surely the
winning criterion should be a little less stringent - i.e. the player
can win by playing well though not perfectly?
Thatr said, games with puzzle-like levels that are not revealed at the
start have been commercially successful; c.f. Cannon Fodder and similar
games. If this is the route you take, the levels better be interesting
enough to warrant replaying.
Still, it's not a bad idea, and you can always tweak the concept and
see what it evolves into.
- Gerry Quinn
Luchino alias Samel
Take a look at HYB, my <1kbrl, it has something similar to your gameply,
but without monster (if i remember right)
http://donotjava.netsons.org/?page_id=160
Hope it helps & if you have any comment/question, feel free to ask
Bye
--
Luca Giacometti alias Samel
Antoine
I'm doing this.
After 6 (non-consecutive) days of work, I have the engine ready to
roll. Seven kinds of monsters, nine kinds of objects, various
dangerous and useful terrains, David Gervais tiles, simple keyboard
interface (the only in-game commands are the direction keys), victory
condition.
Now I have the 7th day to actually make some puzzles!
A.
Pender
I think this puzzle-based pseudo-RL is a brilliant idea. You've set
what sound like some good parameters for a 7DRL. If you wanted to
continue development, you could work with more fully developed RL
mechanics as long as you stripped the randomness out. For example:
Monsters and the player have a displayed and fixed number of hit
points, damage per turn and speed. Every attack hits. Attacks against
the player have the damage reduced by a factor related to your armor.
Monsters travel along a preset loop of waypoints until the player is
in their field of view (which is displayed as colored tiles), at which
point they switch to an A* attack approach. Some monsters have special
abilities; for example, Medusas instantly kill you if you enter their
FOV. Potions and wands inflict various fully determined (non-random)
statuses or damage. The ID game is removed. The player's vision is not
restricted by a field of view algorithm. There is no HP regeneration,
but there are some terrain types (Fountains of Health) which instantly
heal you and disappear. Each level is a separate puzzle in which the
items, monsters, terrain, waypoints and inventory are all hard-coded;
the goal is to reach the staircase without being killed.
A comp-sci superwizard could probably even randomly generate certain
kinds of puzzles, thus squaring the circle and making what we'd
consider a full-blown chess-style roguelike.
Antoine
yes you're thinking along very similar lines to myself (except I think
the game benefits from much more naive monster pathfinding - A* is not
exploitable enough).
i'll have something to show in a day or two
A.
Antoine
Succeeded in completing PuzzleRogue as a 7DRL. (Well, 7DRL ish - It
was about seven sessions of coding, though they weren't on consecutive
days...)
The game compiles, runs, can be won, and (I think) is entertaining.
Each level is a puzzle, where the objective is to get from the start
to the end in a set number of moves. You may find some objects which
will help, but there are also dangerous traps and monsters which can
slow you down or kill you. If you run out of moves or health, you have
to begin the level again. So far, there are three levels plus a
tutorial.
You can download Windows binaries at http://puzzlerogue.googlecode.com/files/puzzlerogue_WinBinary.zip.
Sorry the binary download is so big at 10 MB, that's py2exe for ya.
If you're interested, you can also check out the Python source code at
http://puzzlerogue.googlecode.com/files/puzzlerogue_Source.zip.
The game works on my machine but I wouldn't be surprised if other
people had some teething problems, perhaps related to missing DLLs.
Will try to help sort these out.
Any feedback much appreciated!
Enjoy,
A.
Jotaf
> Hi all
>
> Succeeded in completing PuzzleRogue as a 7DRL. (Well, 7DRL ish - It
> was about seven sessions of coding, though they weren't on consecutive
> days...)
>
> The game compiles, runs, can be won, and (I think) is entertaining.
> Each level is a puzzle, where the objective is to get from the start
> to the end in a set number of moves. You may find some objects which
> will help, but there are also dangerous traps and monsters which can
> slow you down or kill you. If you run out of moves or health, you have
> to begin the level again. So far, there are three levels plus a
> tutorial.
>
> Sorry the binary download is so big at 10 MB, that's py2exe for ya.
>
>
> The game works on my machine but I wouldn't be surprised if other
> people had some teething problems, perhaps related to missing DLLs.
> Will try to help sort these out.
>
> Any feedback much appreciated!
>
> Enjoy,
> A.
Great job, the game is pretty awesome! The interactions between the
items, tiles and monsters make for some interesting puzzles. I'm glad
you kept the objects' state to a minimum otherwise it would be
difficult to keep track of everything while imagining a plan.
However, the second level frustrates me to no end :)
The best I can do is reach the two doors and open them. Even when
going straight for them, I always have to "sit around" a bit waiting
for the moving walls to open, wasting valuable turns!
Jotaf
Thijs van Ommen
> Hi all
>
> Succeeded in completing PuzzleRogue as a 7DRL. (Well, 7DRL ish - It
> was about seven sessions of coding, though they weren't on consecutive
> days...)
>
> The game compiles, runs, can be won, and (I think) is entertaining.
> Each level is a puzzle, where the objective is to get from the start
> to the end in a set number of moves. You may find some objects which
> will help, but there are also dangerous traps and monsters which can
> slow you down or kill you. If you run out of moves or health, you have
> to begin the level again. So far, there are three levels plus a
> tutorial.
Interesting game! The monsters and items are really well chosen for a
puzzle game. I especially love the jumping boots! Requiring the
optimal number of turns might be a bit harsh, though. I'm currently
one move short on the fourth level... because I can't fully predict
the monsters' movements over several turns, I don't really see a way
out of that except trial and error.
Two other things: there is a bug where if I press keys more quickly
than the monsters move, things start happening out of order. The walls
will also sometimes move more often than they're supposed to when I do
that.
And I managed to solve the "again but faster" level in 75 rather than
77 moves. I'm not sure where my solution differs from yours (but I'd
guess it involves the item juggling), so I'll paste my entire solution
below in rot13:
Eha cnfg gur tboyva naq gur zbhaq. Cvpx hc gur xrl, nkr naq fuvryq,
gura trg lbhefrys genccrq va gur ubyr jvgu gur cbgvba jura gur jnyyf
zbir. Trg gur obbgf naq hfr gurz gb trg whfg bar bs gur guerr xrlf ng
gur obggbz. Gura cvpx gur bevtvany xrl onpx hc, whzc gb gur nzhyrg naq
jnyx gb gur gryrcbegre. Fgrc qvntbanyyl gb gur rkvg.
Antoine
Heh heh
It is definitely possible!
On what turn do you _leave_ the moving-walls corridor? Should be turn
46 when you step into the 3x3 room on the right hand side of the
level. Your health and inventory at that point are important.
As a further hint, you don't need to kill a lot of monsters.
The password for the next level is 'wombat', if you want to try that.
A.
Antoine
<t__h_i_js__v_an__o_mm...@hotmail.com> wrote:
> On Jan 1, 9:35 am, Antoine <antoine.from.r...@gmail.com> wrote:
>
> > Hi all
>
> > Succeeded in completing PuzzleRogue as a 7DRL. (Well, 7DRL ish - It
> > was about seven sessions of coding, though they weren't on consecutive
> > days...)
>
> puzzle game. I especially love the jumping boots! Requiring the
> optimal number of turns might be a bit harsh, though. I'm currently
> one move short on the fourth level... because I can't fully predict
> the monsters' movements over several turns, I don't really see a way
> out of that except trial and error.
Some trial and error is needed. Post a rot13d solution? The level has
one quite sneaky bit.
> Two other things: there is a bug where if I press keys more quickly
> than the monsters move, things start happening out of order. The walls
> will also sometimes move more often than they're supposed to when I do
> that.
Thanks for bug report.
> And I managed to solve the "again but faster" level in 75 rather than
> 77 moves. I'm not sure where my solution differs from yours (but I'd
> guess it involves the item juggling), so I'll paste my entire solution
> below in rot13:
>
> Eha cnfg gur tboyva naq gur zbhaq. Cvpx hc gur xrl, nkr naq fuvryq,
> gura trg lbhefrys genccrq va gur ubyr jvgu gur cbgvba jura gur jnyyf
> zbir. Trg gur obbgf naq hfr gurz gb trg whfg bar bs gur guerr xrlf ng
> gur obggbz. Gura cvpx gur bevtvany xrl onpx hc, whzc gb gur nzhyrg naq
> jnyx gb gur gryrcbegre. Fgrc qvntbanyyl gb gur rkvg.
Oh! Good work. My item juggling was foolishly slow. 75 it is.
A.
Eric Casteleijn
> people had some teething problems, perhaps related to missing DLLs.
> Will try to help sort these out.
>
> Any feedback much appreciated!
FWIW, if I change line 12 in __main__.py to:
sound.initialise(1, os.path.join('.', 'sounds'))
(the proper crossplatform way to do filesystem paths in python) it
just works on Ubuntu (karmic, after installing pygame). Awesome
effort, I'm gonna play it immediately!
Thijs van Ommen
> On Jan 4, 2:51 am, Thijs van Ommen
>
> <t__h_i_js__v_an__o_mm...@hotmail.com> wrote:
> > I'm currently
> > one move short on the fourth level... because I can't fully predict
> > the monsters' movements over several turns, I don't really see a way
> > out of that except trial and error.
>
> Some trial and error is needed. Post a rot13d solution? The level has
> one quite sneaky bit.
Victory! It turned out there was still room for improvement in a part
where I thought I already had the optimal solution.
Thanks for making the game, it had fun solving the puzzles!
Antoine
Thanks for tip, will do this in next release
A.
eyenot
> So here's the idea, what do you reckon.
>
> Puzzle game roguelike - You have a fixed number of moves to complete
> each (pre-designed) maze. Only just enough to finish the level with
I'd like to work with you since you express a desire to create maze-
based difficulties in roguelikes with more of a rigid game-rule
structure that resembles something like chess or another closed-system
of gaming, that forces you to think more strategically about what to
do next (should I spend this hammer to break a wall or to kill a
kobold) instead of all the various story-telling thoughts that most
roguelikes prompt.
One thing to remember, of course, is that if all you do is present the
user with a 'maze', unless you are only giving them a small portion of
it visible at a certain time, all they need to do to solve it is stare
at the screen for awhile and trace the winning path. And if you pit
lowered visibility against a certain number of moves, you really
aren't in any way being fair to the player unless you are trying to
test them for clairvoyance (sorry but it's true, I've thought about
this a long time because this is my favorite idea to use to start with
for a roguelike).
I'd like you to check out my mini roguelike, "Kobold Mine".
http://lunarsurf.com/~eyenot/kobmine.html
The idea in that one is that w/ each move, the scattered "kobolds"
randomly move omnisciently towards your direction, increasing the
threat level, and when you leave the floor and return later, they are
still in the same position (preserving a reflection of your ability to
get past them in a timely manner but retaining the threat level for
when/if you return).
Scattered around are pieces of cobalt (increase score), cobalt ores/
gems (a much greater score increase), hammers, and potions. Just
running them over causes the player to pick them up and add them to
the tallies that appear underneath the dungeon floor view.
The hammers you pick up allow you to make a decision: destroy a wall-
tile to get through the maze easier, or destroy a kobold. Doing either
one of these consumes one (1) hammer from your hammer-supply. If you
happen to pick up 19 hammers (something I don't explain to the gamer
but they should eventually figure out if they accomplish it a few
times) you "pick up the Hammer of Ur", which basically gives you
unlimited hammers, something that is more or less necessary if you
want to pursue the 2nd game ending.
The 1st ending is to explore as deep as you can fathom, keeping in
mind the threat-level of each floor you left above you in terms of how
close all those kobolds are to the stairwell you left by and what kind
of threat they pose (are they behind walls around the corners or are
they straight down the hallway and so on), collecting cobalt pieces
and gemstones and, eventually, when you can't take it any more,
returning to the top to leave the dungeon.
One major force influencing the choice to leave the dungeon is the
increasing appearance of beholders -- if you are in a straight
cardinal direction from a beholder's location with no walls between
you for one full turn, the beholder instantly kills you. This means if
in one turn you notice a beholder sharing a vertical or horizontal
line of floor-tiles with you, then you have a choice of either getting
off that vertical or horizontal line or being fried next turn (like
being in check by a rook).
There are three potion-types scattered through the dungeon that give
you powers against the opponents: bluer potion which stops all enemies
from moving (but if you dare to collide with them you will die of
brain freeze, which effectively makes all those frozen enemies into
virtual walls, which can still be destroyed by your hammer); red
potions which allow you to destroy an enemy by colliding with it but
which also cause all enemies to reverse directions and run
omnisciently away from the player (due to the subroutine I use to
calculate their movements being somewhat 'dirty', enemy movements have
a failure rate that means they stand still, something the player
doesn't suffer from, which allows the player to catch up) and if the
player collides with them, they provide the player with gems; and the
green potion, which turns the player into a (very large) kobold, which
more or less puts the kobold enemies into a strange situation where
they are sometimes running away from your position and the rest of the
time running away from it, really 50/50, so they all appear to be
wandering aimlessly while you are affected by the potion, and it also
allows you to pass by them harmlessly. There is one more potion, the
humanity potion, which only appears on a predetermined floor and tile
in the dungeon and which, when gained, enforces your ability to stay
human.
Oh, yeah: if you spend more than a certain number of turns in the
dungeon, you turn into a kobold, and you will die if you attempt to
leave the dungeon after that, another incentive to grabbing the score-
increasing cobalt and gemstones, turning around, and leaving early. So
really, to reach the 2nd ending, you need not only to accomplish
grabbing the hammer of Ur (19 hammers) but also the humanity potion,
and then, if you should reach the bottom floor, you need to search
around for the hidden stairwell by basically attempting the down-
stairs command on every open tile until one of them happens to
actually send you down-stairs. I can't remember at this point in time
whether or not I built it in to reveal the stairway location if you
occupy the space next to it or not, sorry.
There is another ending that occurs under certain circumstances but I
can't remember how to obtain it, but I do remember that I coded in
some safeguards that make it hard to test it out by using the god-mode
(which you can activate by hitting your asterisk key). The second
version of the game gives you a bunch of free potions when you use god-
mode, and both versions allow you to turn god-mode off by hitting the
asterisk again. God-mode will freeze the motion of all enemies but I
can't remember if it also saves you from collisions.
^-- I don't have a TTY-capable terminal right now so I can't add that
to the actual page, so as
of now this message is the only place you can find the 'secrets' of
the game besides crawling
through the code and deciphering all the flags.
Antoine
> On Dec 20 2009, 2:13 am, Antoine <antoine.from.r...@gmail.com> wrote:
>
> > So here's the idea, what do you reckon.
>
> > Puzzle game roguelike - You have a fixed number of moves to complete
> > each (pre-designed) maze. Only just enough to finish the level with
>
> I'd like to work with you since you express a desire to create maze-
> based difficulties in roguelikes with more of a rigid game-rule
> structure that resembles something like chess or another closed-system
> of gaming, that forces you to think more strategically about what to
> do next (should I spend this hammer to break a wall or to kill a
> kobold) instead of all the various story-telling thoughts that most
> roguelikes prompt.
>
> One thing to remember, of course, is that if all you do is present the
> user with a 'maze', unless you are only giving them a small portion of
> it visible at a certain time, all they need to do to solve it is stare
> at the screen for awhile and trace the winning path. And if you pit
> lowered visibility against a certain number of moves, you really
> aren't in any way being fair to the player unless you are trying to
> test them for clairvoyance (sorry but it's true, I've thought about
> this a long time because this is my favorite idea to use to start with
> for a roguelike).
>
> I'd like you to check out my mini roguelike, "Kobold Mine".http://lunarsurf.com/~eyenot/kobmine.html
I'm enjoying the game. It has much roguelikeness. Reminds me of Pacman
a bit too.
Small problem - I don't get color on my screen (Vista) which means I
can;t tell the potions apart at range.
Question - sometimes kobolds do not move after I do, I cannot tell if
there is a pattern to it or whether it is random. If random then why?
A.
eyenot
>
> - Show quoted text -
Ah, the reason the enemy movements seem staggered
is because I wanted them to be slower than the player.
If they move at the same speed move for move, the
player ultimately has little to no chance to win simply by
reason of being totally outnumbered and surrounded.
There's no color in the game at all, and there's no way
built-in to tell potions apart without picking them up. I had
hoped the design made any potion as 'worth' picking up
as any of the others, so that the choice became whether
or not picking up a potion was worth the hassle.