Resolute: Postmortem
Tee on 2019/04/14 17:49
of Tee-py27
Difficulty and confusion
There were issues with confusion, and I completely understand that. I struggled with designing the learning curve because it's not easy to explain the rules, and I still don't know what's the best way to do that. It takes a while to get a hang of it, even with just two types of block. Also, I still don't know what's the best interface for the game. I ended up using colored borders to indicate how blocks would unmerge, but it would have been nice to add a way for the player to know what a block will transform to (i.e. make the rules visual instead of having the player memorize them).
I find it interesting that a relatively high number of people were confused and solved levels by moving around randomly. I guess that's hard to avoid with a board this small. On that note, the game seems to be too difficult for those who didn't have a full understanding of the merging rules (understandably), but it was challenging but doable for those who got the hang of it. I'm glad the game was challenging but doable, because that's usually my goal. :) But I think the game would have benefited from a better ramp up. I did consider this carefully and I think I did what I could in the time I had, but it definitely could use improvement. Maybe I should have flashed text every time the player tried an invalid action. I don't plan to keep working on this but I'm curious from a game design standpoint what others would do to improve on this.
Mechanics and level design
There are Pyweeks in which I have an idea I like from the beginning, and there are those in which I go through many iterations of different ideas (whether I fail or succeed). "6" is a difficult theme to work with, so this one was the latter. After several scrapped ideas, I had this idea on Thursday, spent that night iterating through the mechanics on paper, started implementing the framework Friday night, and I didn't actually try designing levels before the last day. I was concerned because it was possible that the puzzle mechanics were just bad, but I'm glad something worked out.
Level design was challenging; it was mostly done backwards from the goal with a lot of trial and error. It's difficult because the levels have to be kind of tight, as the merged board is very small. For example, at some point I thought I had a challenging last level, but it turned out there was a trivial solution to it I missed; I ended up redoing the last level at the very end.
Without adding new features or more resolution levels, I suspect there's not a lot more room for variety in level design. The issue is that 3x2 and even 6x4 is too small to do anything too deep (although it was fun working with tight constraints). But maybe adding new mechanics could help. One idea I had but didn't have time to implement were boxes that would destroy an underlying box if attempted to merge down together (if that makes any sense).
I did originally plan to have a third level of resolution. I started implementing the game in a way that would allow it. However, at some point I was running out of time, and I started assuming two levels to code more quickly. In particular, I don't know how I would do the colored borders for more than two levels. Maybe that's for the best though. If two levels are already confusing, I imagine that three levels would be too difficult.
Final notes
Sorry about the escape key leaving the game; I should be more careful with that next time. I added the instructions in the last hour before submitting, so I didn't consider someone might press escape to exit the instructions. :)
Congratulations to Cosmologicon and hexima for first places! Thanks mauve for organizing this! Great improvements to the website; I really like the ratings dashboard. See you all next time.
(log in to comment)
Comments
Tee on
2019/04/14 22:50:
That's a good question! The small board and (relative) simplicity of the rules makes this game a good candidate for an approach like that.
I considered this but I only started making levels on the last day, so I wouldn't have had the time to do it. The merging/unmerging makes the implementation slightly longer but it's doable. I might have given it a shot if I had started on this in the beginning of the week. I would have done a hybrid version though: implement a solver and handcraft levels with the aid of the solver. This is probably slower overall but it gives me more creative control and still helps avoid unintended solutions and guide me to good levels.
asrp on
2019/04/15 00:09:
In particular, I don't know how I would do the colored borders for more than two levels.You could have two rings of borders, one for each higher resolution. The extra border would also serve as visual cue for where the grouping for the resolution two up would be.
Maybe a second border to show the result of a merge at all times (without executing a merge) could help the player. Or maybe, at low resolution have the same four squares show this result.
Though I think the difficulty and confusion comes from understanding the consequences of the rules, especially when adding or removing a block changes the result of the tie breaker. And I don't think visual/design aids would be of much help there. But I just took it as being part of the puzzle game and thought it worked surprisingly well for having very few rules that results in the consequences you want.
By the way, the main character should be at the top of the list for ties.
I didn't actually try designing levels before the last day. I was concerned because it was possible that the puzzle mechanics were just bad, but I'm glad something worked out.Oh, wow. This is really impressive, for both your luck and level design skills. From the player's perspective, it looks like it was all well thought out with careful planning.
Tee on
2019/04/15 03:26:
Thanks for the input! The main issue with more than two levels is that there are internal squares (top level holds 4x4 squares two levels down), so extra borders might not be sufficient (unless I just present information for the level immediately below). It's kind of tricky. I agree that for the merge up, an extra border or something like that could help.
It's good to hear that the puzzle worked well for having few rules, because this is an explicit goal of mine. My puzzle design philosophy is to minimize the mechanics in a way that creates the most interesting dynamics possible. I designed the rules with this in mind. I've also learned that minimalism is great for Pyweeks because you don't need as much time to implement the game. :)
I didn't add the character as a tie breaker because it's a special case. It's not really a tie breaker because you still need to follow the rules for the other blocks (counting the tile the character is in as empty), and if the square the character is in does not become an empty space, then you cannot merge. Maybe the special rules for the character added to the confusion.
I'm glad the levels look planned! I'm always scrambling on Pyweek, even though sometimes it might not look that way. :)
Cosmologicon on
2019/04/14 19:05:
Just wondering, have you tried automatically generating puzzles? In my experience this is a very powerful for tightly-enclosed sliding block puzzles like this. Randomly generate a board and then use A* or something to find the minimum number of moves, then run for a few hours looking for longer and longer puzzles. You'd think the results wouldn't be as interesting or fun as hand-crafted layouts, but in my experience they're pretty good.