[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enigma-devel] new level: Things Gonna Change
Re: [Enigma-devel] new level: Things Gonna Change
Fri, 12 Sep 2014 02:53:02 +0100
On Sat, 2014-09-06 at 08:30 -0700, address@hidden wrote:
> Hi Enigma-Team
> here is my first level. I hope you enjoy it.
Note to people trying this: there's a stray newline at the start of
the .xml file that stops the file loading. Deleting the newline causes
the level to load correctly.
I've looked through the level, completing it unspoiled as far as the key
idea, then looking at the level file to work out the rest. (I'm not in
charge of choosing which levels go into Enigma, but feel like my
feedback may nonetheless be helpful in improving it.) I'll try to avoid
spoilers in this post, which means that I may be more obscure than
necessary at times; if you don't understand something, feel free to
contact me for clarification. However, people who are planning to solve
the level unspoiled might want to avoid this post altogether in order,
just in case I haven't been obscure enough.
The start of this level works out really well. In puzzle games
generally, and in Enigma in particular, there's something of a standard
rule "if a puzzle is impossible under the rules you're presented with,
there must be something hidden". Normally, this rule is used as a way to
produce an extra option in a puzzle; if a level presents you with a
puzzle, it means that you have to attempt to solve the puzzle and
determine either "this puzzle is possible, I can enter the solution", or
"this puzzle is impossible, I need to look for something hidden that
lets me solve it". This level uses the principle in a valid, but
entirely different, way, which I was very impressed by; it's clear that
you correctly predicted the first ten or so moves that a solving player
will make very accurately (to the extent that even when I know what to
do, I often revert into the "obvious" pattern out of habit rather than
following the actual solution).
After that, though, things go downhill a bit. By the time a player has
determined the purpose of the switch (that is, not what it does – which
is obvious – but which setting it should have at various points in the
level solution and why), the level is essentially solved, but there is
still a lot of work to do (especially in opening the oxyds). A
fair-shuffle is clearly needed for times in this level to be comparable
with each other, but forcing the worst possible oxyd distribution is
not; because the exact distribution clearly doesn't matter (apart from
being fair), it would be worthwhile giving a distribution that's kinder
to the players. One thing that might work well would be to pick two
colours that are appropriate for the level (it doesn't have to be red
and blue), and place the oxyds in a fixed, pre-revealed (using
st_oxyd_e), pattern. This would make the oxyd opening work in a much
kinder way, while not taking away from the idea behind the level.
There are two other things that annoyed me a lot. One is that I
frequently died from falling into abyss, which isn't something that has
much to do with the idea of the level at all. I'd recommend two changes.
One is to leave the player with their extralifes, using
wo["AutoRespawn"]=true in order to prevent this introducing shortcuts.
The other is to increase the friction of the floor a bit in order to
make the dexterity required for the level a little lower; apart from the
very start of the level, it really isn't a level about dexterity. I
subscribe to the thought that each level should be about one thing in
particular (although that one thing can be "doing lots of different
things at once / in sequence"); an intelligence-level and a
dexterity-level are separate concepts, and adding dexterity-based
challenges to an intelligence-based level mostly just annoys people
rather than gives them extra enjoyment. To put this in context: the
level took me about 10 tries even after I knew the solution.
The other thing is that there is one stage in the middle of the level
(just after getting the first key) when the player has a lot of options,
not enough information to distinguish between them, and about 1 and a
half minutes to get back to that point if they choose the wrong one.
(This is the point that made me check the level source code to see what
I had to do.) I'm not sure there's even a benefit to placing abyss
before the keyhole; this means that your level becomes more complex than
it needs to be in order to let the player access them, and I don't see
any gain from that complexity (especially because its main function is
to make the level require more trial-and-error without adding much
challenge in any direction but Patience). Removing that part of the
level would be relatively easy; you could move the keyhole somewhere the
player could access, get rid of the method you provide for crossing the
abyss, and the level would be just the same. This would also make it
easier to guarantee that there are no shortcuts; there's a potential
shortcut I see in the level design which I'm reasonably sure doesn't
work, but the level would be better if either players had no reason to
attempt it, or else the level were modified so that sufficiently good
players could pull it off.
So overall, my feedback is that this is an excellent level idea that
starts out well – I'm a big fan of computer game levels that are
designed with knowledge of the player's likely actions in mind – but you
seemed a little uncertain about what to do after that. I'd recommend
shortening the level so that it's basically just the really good idea,
rather than having some generic (and relatively uninteresting) work to
do after that. As explained above, this wouldn't require major changes
to the level.