On Sat, 2014-09-06 at 08:30 -0700, l...@xmail.net 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. -- ais523 _______________________________________________ Enigma-devel mailing list Enigma-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/enigma-devel
