Flip
A simple puzzle game about constantly flipping worlds.
Awards
Scores
Ratings (show detail)
Overall: 3.8
Fun: 3.7
Production: 3.9
Innovation: 3.9
Files
File | Uploader | Date |
---|---|---|
Flip-Win.zip
— final
Flip. Windows version (py2exe'd). |
Tee | 2018/04/22 03:55 |
Flip-ss.png
Flip. Screenshot. |
Tee | 2018/04/21 23:48 |
Flip.zip
— final
Flip. Final version. |
Tee | 2018/04/21 23:43 |
Diary Entries
Flip: Done
I decided to go with another puzzle game. Designing puzzle mechanics is always fun to do. :)
Designing levels was quite tricky and I didn't allocate a lot of time to it. Hopefully the levels I made should give a feel for the puzzle mechanic. The puzzle has some interesting properties, but I'm not sure if it is possible to go much deeper with the mechanics as implemented; or at least, creating deeper levels is not straightforward. The synchronization aspect of the puzzle is a bit tricky to handle from a level design standpoint.
I hope you enjoy it!
Designing levels was quite tricky and I didn't allocate a lot of time to it. Hopefully the levels I made should give a feel for the puzzle mechanic. The puzzle has some interesting properties, but I'm not sure if it is possible to go much deeper with the mechanics as implemented; or at least, creating deeper levels is not straightforward. The synchronization aspect of the puzzle is a bit tricky to handle from a level design standpoint.
I hope you enjoy it!
Flip: Postmortem
Hey everyone,
Thank you all for the feedback! I'm glad that you had fun! Here's a quick postmortem.
Puzzle design
I always enjoy designing these puzzle games. It's like a little system that you have to figure out how to make fun. This one in particular was tricky: the frequency aspect of the puzzle led to some interesting challenges.
The fact that the board is laid out in alternating colors like a chessboard is not arbitrary. The location of the frequency gem is actually very important to the solution of the puzzle. For gems with even value, depending whether the gem is on a light or a dark tile, it allows or not certain patterns to be traversed. This is sort of a parity property. While this is also sort of true for odd gems, odd gems are special in that their "parity" depends on whether you pick them up while the world is red or blue. However, I thought that was too obscure and would lead to lost players wondering what they did wrong, so for the odd gems I made the levels so you are actually forced to pick them up at certain colors (if I haven't missed anything). I play a lot with this in the later levels, which have more than one gem of the same value but with different "parities".
I also had some trouble with depth. I'm not sure how you as players felt, but with only the components in the first part of the game, I wasn't able to make a super deep level. Mostly you had to figure out what order to do things, what path to choose, and how to switch to the color/state that you want. What I was initially hoping for was that you might have to think about the "number of turns left to flip" with which you want to arrive at a certain tile. However, it turns out that there's little flexibility there in the sense that the player can always sort of adjust themselves at the tile instead of having to plan ahead.
In other words, aside from choosing the right order to do things, the puzzle at its core is "local". This is why I added the stabilizers that appear in the later levels: they let you affect tiles that are far away, which gave me more flexibility in making interesting levels. For example, you may have to interact with stabilizers to activate a "support" to pass a certain pattern ("support" is what I call an adjacent tile that lets you switch colors by having a safe place to move). I think this is not something that is obvious and I hope it has the ability to give some players an "aha" moment.
I'm curious to hear if you figured out these properties of the puzzle! I didn't until I got deeper into the level design, so while I hope they influenced the decisions of the player at an intuitive level, I have no idea if a player would notice them explicitly.
Response to comments
Thanks for your comments! I especially appreciate all the positive feedback and I'm just glad that I made something most of you enjoyed. :) I want to reply to a few of the comments here:
"I feel like you applied the theme in a very direct way to the puzzle genre instead of doing something a bit more out of the box."
I like to think that there is some innovation in my game -- I haven't played a similar puzzle -- but I do see your point. Throughout the years I found out that the only way I can finish Pyweeks is by making simple and minimal games (and grow from them only if I have the time). Even if this was a simple puzzle idea, I thought it was a really interesting idea to explore in a design sense. With time, I've started to care less about the ideas that seed a game and more about the way they are grown. I think that's where the most interesting challenges lie.
"please make a simple, easy way to run the game consistent with the readme."
Sorry to hear you had trouble. I'm not sure what happened: all you need is Python 3 and Pygame. Also, I'd appreciate it if next time you tick the DNW checkbox so I don't end up with a 1 1 1!
"Would have loved an undo button" / "When I played later levels, I wanted a rewinding function."
Yes! Sorry about that. I didn't have the time to include one and I thought it wasn't too bad not to have one.
"a visual indication on the tiles themselves when they were about to change."
Good point! The indicator on top tells you when they will change, but I completely agree that it's inconvenient to keep looking away from the puzzle. It's not the first time I missed something like this (i.e. having an indicator of something important outside the visual focus of the player). I tend to playtest my games by myself, so I often miss things that are obvious to me but not to a new player. But yes, it wouldn't have been hard to have added it; I would have made the character glimmer and added an indicator sound.
"The music itself was good, but I don't think it was exactly fitting" / "This is a neat puzzle game with the weirdest music ever. Why all the meowing..?" / "...best music..." / "choice of music [...] are pretty top notch"
It seems that my choice of music was a bit polarizing. :) I wanted the music to be somewhat quirky and fun, and that's what I found. Music isn't my strength at all -- I can't make music, so I just choose one that I like in the limited amount of time that I have (with the appropriate license, of course). (I hope that in general people don't take into account the music of my games too much, since they're not mine...)
"A bit more bling would have boosted the production score even more." / "Given the simplicity of the game concept, I would like to see better graphical and sound effects (ie. juice)." / "I would've give it an exceptional innovation if there are more functioning events and storyline maybe."
Indeed. I wish I had the time. And, not that it excuses anything, but the simplicity is intentional. Otherwise I wouldn't be able to finish these games in one week. In other words: don't expect that to change. :)
"I would love that if there was some sort of objective other than completing levels. As it is, the motivation is to say that you finished which I don't find very compelling."
My answer to this is also that I wish I had the time. But I argue that, ideally, a puzzle game should be fun by itself and not need too much fluff. If you didn't find it compelling, then I have failed you. :)
Unfortunately I didn't get a chance to play and rate your games this time. The timing of this Pyweek was not very good for me. But congratulations to mit-mit and to Universe Factory for winning, and to everyone else who finished their games! Thanks to mauve for hosting this Pyweek and see you next time!
Thank you all for the feedback! I'm glad that you had fun! Here's a quick postmortem.
Puzzle design
I always enjoy designing these puzzle games. It's like a little system that you have to figure out how to make fun. This one in particular was tricky: the frequency aspect of the puzzle led to some interesting challenges.
The fact that the board is laid out in alternating colors like a chessboard is not arbitrary. The location of the frequency gem is actually very important to the solution of the puzzle. For gems with even value, depending whether the gem is on a light or a dark tile, it allows or not certain patterns to be traversed. This is sort of a parity property. While this is also sort of true for odd gems, odd gems are special in that their "parity" depends on whether you pick them up while the world is red or blue. However, I thought that was too obscure and would lead to lost players wondering what they did wrong, so for the odd gems I made the levels so you are actually forced to pick them up at certain colors (if I haven't missed anything). I play a lot with this in the later levels, which have more than one gem of the same value but with different "parities".
I also had some trouble with depth. I'm not sure how you as players felt, but with only the components in the first part of the game, I wasn't able to make a super deep level. Mostly you had to figure out what order to do things, what path to choose, and how to switch to the color/state that you want. What I was initially hoping for was that you might have to think about the "number of turns left to flip" with which you want to arrive at a certain tile. However, it turns out that there's little flexibility there in the sense that the player can always sort of adjust themselves at the tile instead of having to plan ahead.
In other words, aside from choosing the right order to do things, the puzzle at its core is "local". This is why I added the stabilizers that appear in the later levels: they let you affect tiles that are far away, which gave me more flexibility in making interesting levels. For example, you may have to interact with stabilizers to activate a "support" to pass a certain pattern ("support" is what I call an adjacent tile that lets you switch colors by having a safe place to move). I think this is not something that is obvious and I hope it has the ability to give some players an "aha" moment.
I'm curious to hear if you figured out these properties of the puzzle! I didn't until I got deeper into the level design, so while I hope they influenced the decisions of the player at an intuitive level, I have no idea if a player would notice them explicitly.
Response to comments
Thanks for your comments! I especially appreciate all the positive feedback and I'm just glad that I made something most of you enjoyed. :) I want to reply to a few of the comments here:
"I feel like you applied the theme in a very direct way to the puzzle genre instead of doing something a bit more out of the box."
I like to think that there is some innovation in my game -- I haven't played a similar puzzle -- but I do see your point. Throughout the years I found out that the only way I can finish Pyweeks is by making simple and minimal games (and grow from them only if I have the time). Even if this was a simple puzzle idea, I thought it was a really interesting idea to explore in a design sense. With time, I've started to care less about the ideas that seed a game and more about the way they are grown. I think that's where the most interesting challenges lie.
"please make a simple, easy way to run the game consistent with the readme."
Sorry to hear you had trouble. I'm not sure what happened: all you need is Python 3 and Pygame. Also, I'd appreciate it if next time you tick the DNW checkbox so I don't end up with a 1 1 1!
"Would have loved an undo button" / "When I played later levels, I wanted a rewinding function."
Yes! Sorry about that. I didn't have the time to include one and I thought it wasn't too bad not to have one.
"a visual indication on the tiles themselves when they were about to change."
Good point! The indicator on top tells you when they will change, but I completely agree that it's inconvenient to keep looking away from the puzzle. It's not the first time I missed something like this (i.e. having an indicator of something important outside the visual focus of the player). I tend to playtest my games by myself, so I often miss things that are obvious to me but not to a new player. But yes, it wouldn't have been hard to have added it; I would have made the character glimmer and added an indicator sound.
"The music itself was good, but I don't think it was exactly fitting" / "This is a neat puzzle game with the weirdest music ever. Why all the meowing..?" / "...best music..." / "choice of music [...] are pretty top notch"
It seems that my choice of music was a bit polarizing. :) I wanted the music to be somewhat quirky and fun, and that's what I found. Music isn't my strength at all -- I can't make music, so I just choose one that I like in the limited amount of time that I have (with the appropriate license, of course). (I hope that in general people don't take into account the music of my games too much, since they're not mine...)
"A bit more bling would have boosted the production score even more." / "Given the simplicity of the game concept, I would like to see better graphical and sound effects (ie. juice)." / "I would've give it an exceptional innovation if there are more functioning events and storyline maybe."
Indeed. I wish I had the time. And, not that it excuses anything, but the simplicity is intentional. Otherwise I wouldn't be able to finish these games in one week. In other words: don't expect that to change. :)
"I would love that if there was some sort of objective other than completing levels. As it is, the motivation is to say that you finished which I don't find very compelling."
My answer to this is also that I wish I had the time. But I argue that, ideally, a puzzle game should be fun by itself and not need too much fluff. If you didn't find it compelling, then I have failed you. :)
Unfortunately I didn't get a chance to play and rate your games this time. The timing of this Pyweek was not very good for me. But congratulations to mit-mit and to Universe Factory for winning, and to everyone else who finished their games! Thanks to mauve for hosting this Pyweek and see you next time!