Resolute
A short puzzle game about moving boxes in a restricted 3x2 board. Well, unless you change to a different resolution.
Awards
Scores
Ratings (show detail)
Overall: 3.8
Fun: 3.6
Production: 3.6
Innovation: 4.1
Files
File | Uploader | Date |
---|---|---|
Resolute-ss.png
Resolute. Screenshot. |
Tee | 2019/03/30 23:59 |
Resolute.zip
— final
Resolute. Final entry. |
Tee | 2019/03/30 23:52 |
Diary Entries
Resolute: Postmortem
Thanks for the feedback! Here are some final notes on the game.
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.
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.