Walkway: Postmortem

Tee on 2012/09/16 13:51 of Tee-py15

I've been very busy these past few weeks, since I've had some major changes to my life recently. Nevertheless, I'm quite satisfied with how this Pyweek turned out for me.

Fortunately, I was able to spare a day (not without some sacrifice). I don't want to lose my Pyweek streak after all. :) So I figured I would make something very small and minimal for a day. I felt making a puzzle with a minimal mechanic would be interesting. The tie to the theme might be a little hard to see: it's about constructing a "one way" path. The rules are fairly simple: you should pass through every yellow node and cross twice every orange node, and you cannot cross yourself except on orange nodes.

I think this game turned out more interesting than I was expecting. When I started this morning, I thought this mechanic was too shallow to generate hard puzzles. Thankfully, I was wrong. It may not be deep, but it's also not too shallow.

I hope it's not too hard though. I haven't had anyone else playtest it and it's really hard to calibrate a puzzle by yourself (since you know the answer already :)). If you manage to finish it (or not), please let me know. If you find it's too easy, add GOOD_LUCK to the list of levels at the end of level.py and good luck. :)

It was quite a nice experience to do something with a small scope this time. I guess I should try this more often.

Anyway, once again, congratulations to everyone who finished and thanks to Richard for hosting yet another Pyweek. I'm fairly sure I won't have time to judge your games, unfortunately. :(

See you all next Pyweek!

(log in to comment)

Comments

BlueDragon on 2012/09/27 17:53:

May I say "Congratulations!"?
This is, in a way (one way?), the best game I've played from this Pyweek so far.
While I've played quite a few good games (it seems to me that the level has improved compared to the previous edition) this one is the best for me because it looks polished, complete, fun and challenging.
The only downside I can find is that there's not much "replay value", once you've finished one time it doesn't make much sense (to me) playing it again. However, many other games have this "shortfall" too.
Even more praise for you considering that you created it in just one day.
I also loved the music, again I say: the game looks polished.
The levels also were challenging and I think they are roughly in good order (I didn't find an "easy" one among the latest ones).
However, I must say that I've played the game in a bit "unorthodox" way (maybe): instead of just trying path after path by trial and error, once the game got harder (around 8-10 level?) I made screenshots of the level and "planned" my way by drawing the path on an image editor. Once I got a plausible path, I tested it in the game.

I have not tried the "GOOD_LUCK" level yet, but I will do shortly.

My only regret is that I can't vote your game as I haven't submitted anything this Pyweek (too busy - maybe I should have tried your "one day" approach!).

Again - congratulations for your beautiful game, I hope it will get many reviews and high scores!

BlueDragon on 2012/09/27 18:09:

PS: Solved the GOOD_LUCK level too! :)

Tee on 2012/10/01 04:03:

BlueDragon: Thanks. :) Great work on solving GOOD_LUCK. That was a level that I was going to put in as the last one but I removed because I thought that was impossible. May I ask what was your strategy to solve it?

BlueDragon on 2012/10/01 18:13:

First of all, I want to say that, in spite of what I wrote before, I have played the game again, all 15 levels + GOOD_LUCK, without using external tools this time - and I liked it a lot again :)

The strategy I used when I planned my routes on GIMP was to draw a cross on all squares, since they have to be crossed sooner or later - then draw "obliged" routes like through yellow diamonds which have only 2 neighbours (so you have to come from one side and exit to the other). 
Then you carefully inspect these pieces of routes you have drawn and you realize that they "oblige" you to make some other steps, and you draw them too. In the end you find you have drawn a "one way" that you have to follow.
It's a bit like solving a Sudoku, once you have done the obvious moves, more obvious ones come up as a consequence :)
However, if I remember correctly, GOOD_LUCK required also some trial and error, even on paper.

Playing without external tools was similar, but involved more trial and error - since it's hard to visualize the whole route on big levels without trying it first a few times.


So I have a question for you: how did you design these levels?
They look very good and balanced to me, especially considering the limited time you had :)

Tee on 2012/10/02 00:24:

That's an interesting strategy. While it may seem a natural strategy in retrospect, I didn't try playing my game enough to think of that. Usually puzzle games with these kinds of strategy are fun (a chain of logical implications), which is a good sign. Thanks for the insightful information. :)

Designing these levels was actually fairly easy. Basically I first built the path, then chose the nodes from there. At later levels, I tried building longer paths with lots of crossings and some empty spaces to create uncertainty. It's as simple as that. I may have been a little lucky to get them in the right order of difficulty.

If you like puzzle design or math, here's a quick quiz for you ("you" as in anyone interested): would the game be the same if instead of only allowing crossings on large nodes, I allowed any movement on them as long as you touch them twice? That is, the difference is that now you'd be able to make a corner on the large node and then later complete it with another opposite corner. The game as it is right now doesn't allow you to do that.

This is actually two questions in disguise, one of a math nature and another of a game design nature. By same, I can either mean any level that is solvable on one version is solvable on the other (math version), or mean that the game is equally fun and challenging (game design version). This is something I unexpectedly stumbled upon during the creation of the game, which I thought was quite interesting to think about. I know the answer to the first one, but I'm not certain about the second one.

Cosmologicon on 2012/10/02 15:02:

No, the game wouldn't be the same mathematically. Some boards would become solvable that are currently unsolvable. The simplest example is 10 nodes laid out like the 10 digits on a telephone keypad, with the start at 5 and a large node at 8.

Tee on 2012/10/03 01:51:

That's a nice way to illustrate your counter-example. :)

That wasn't obvious to me at first. When I was designing the game, I considered whether I should restrict to crossings or not. I was thinking of it from a game design perspective. After some thought, I realized they were two different games. In any case, I opted for restricting to crossings, since it makes the rules clearer and I believe it is a good thing to remove uncertainty at the large nodes (at least when you play it linearly).

A side note: this puzzle is NP-complete. It is in NP, and an efficient algorithm to solve this game would be able to efficiently solve the Hamiltonian path problem in grids (just consider the small yellow nodes), which is NP-complete. The reason I mention this is because I have a general feeling that puzzles based on NP-complete problems tend to be fun. I admit I did not take this into account when designing this game, though.

eswald on 2012/10/04 14:39:

Now I have to wonder where Rainbow Rooms falls in complexity.  I suspect NP, but I'm less certain about NP-complete.

GOOD_LUCK was very nice; I had skipped over it when I first saw it in the code, and tried it out after reading this thread.  I like the way it forces you to extend a bit farther in multiple places.