Apart: Postmortem
Tee on 2020/10/11 01:46
of Tee
Despite its flaws (I will talk about them in a bit), I'm quite proud of this one. I was worried that the puzzles might be too difficult and that would get in the way of being fun, but it sounds like it was still fun despite the difficulty. I usually don't work on my games past Pyweek but I might actually polish this one further because I want to fix the flaws in it, and I just really like this idea overall.
This main post is spoiler-free. I will post a comment with spoilers on the story and individual puzzles so that it doesn't show up when someone is scrolling through the diaries page.
Puzzles are always hard to balance. As a designer, you're the one who made it, so the solution seems obvious to you, but it may be completely baffling to others. These were especially hard for me to know how difficult they were because they're open-ended, out-of-the-box puzzles. These are the types of puzzles that you either get or don't, there's no step-by-step process to get to them. It sounds like it was generally difficult, which was my main concern, but it looks like you still had fun with them, so I'm glad. Personally, I had a lot of fun designing these puzzles.
Oh, and thanks mit-mit for asking for hints! I didn't think of posting hints if no one had asked, and ultimately it helped people get through this game.
Puzzle interface
The interface of the puzzle screen took me longer than I would have liked to implement, and it's still not great. I wanted the entire game to be keyboard based, but maybe that was not needed. I probably should have implemented moving pieces inside the "inventory" as well (currently moving a piece back just places it automatically), I think that's the most confusing aspect of the UI. It's also buggy sometimes: a piece sometimes hovers under a piece that is already placed. If you have any suggestions on how to improve it, or if you know any useful library I could have used to implement it more quickly, I would be interested in knowing.
Final notes
Let me know if you have any other feedback or thoughts about this game. I enjoyed playing your games, though unfortunately I didn't have time to go through all of them this time, so apologies if you didn't get a rating from me. There were many great games, and I'm always impressed at what can be done in one week. Congratulations to the Obbo's Descent's team for first place in the team category! Thanks mauve for hosting this! See you all next time.
(log in to comment)
Comments
Cosmologicon on
2020/10/11 03:21:
SPOILER ALERT continues for this comment.
Great writeup, and as I said in my rating comment, great game! Would you be willing to give more detail on the solution to #6? I've read your solution and I don't see why the answer isn't NWWN, as shown here.
For the puzzle interface, I found that it took a lot of key presses to get from one state to another. I think you could get this number down in a few ways. The ability to swap the piece in hand with the one you're hovering over would be handy. As would a key that clears the board, or the piece you're currently hovering over. Also possibly allowing the board to temporarily be in an invalid state, so you can place down the piece you want before you pick up its unmatching neighbor. You have to decide how to represent this visually, and decide what happens if they press Esc in an invalid state, but I think the simplest solution (just clearing the board) would be acceptable.
There are a few possibilities for making the lighthouse puzzle easier, if you decided to. You could put the same symbol at the center of every piece involved in the chain: lighthouse, mirrors, and pit. I also think that having more pieces in the chain would actually make it easier to guess what you're supposed to do: 4 mirrors for a total of 6 pieces would be ideal. What would really do it is having the lighthouse cast a spotlight into the center of the tile it's facing, that you can see if you walk there. If that tile is one of the mirror tiles, then it casts another spotlight into the next tile, and so on. And of course the spotlight in the pit tile lands right on top of the pit.
Anyway, just some thoughts because I found your design challenges interesting. I'm really impressed at how much work you put into the game, and thanks for taking the time to make this post!
mit-mit on
2020/10/11 11:44:
Tee on
2020/10/11 22:20:
Thanks for the feedback on the puzzle interface! Thinking about it in terms of minimizing key presses is a good idea. I wanted the game to have a single action button (besides esc and arrow keys), but I think a second button here could be helpful to do things like swapping, etc.
I really like the idea of having the spotlight show up in the real world. I think that's the right thing to do, it makes a lot of sense. Having more pieces in the chain would probably make it easier, too.
These are all great ideas, I appreciate the feedback!
@mit-mit: I somehow have the opposite problem: whenever I make a non-puzzle game, it doesn't turn out to be as good. :) There are exceptions, of course -- A Knight of Curses is still one of my favorite Pyweek games I developed. But if you've followed my Pyweek games, it's not uncommon for me to fail to create the game that I envisioned (often time is the main factor).
I can write a lot about my design process, so here we go. :) I might have mentioned some of these things before.
This game in particular is a bit different from my other puzzle games. I think I need to split this reply up into two parts: how I typically design my logic-based puzzle games (the bulk of my previous Pyweek puzzle games), and how I designed this one. But to first answer your question, I implement the engine and design the puzzles concurrently. I first try to get the mechanic right and design a few puzzles in a way that feels satisfying, then implement the engine, then I use the engine to help me design more puzzles (usually this is done in the very last day, which is a bad habit because the balancing ends up all wonky).
My typical Pyweek puzzle design process
Let me talk about my typical process first (for more logic-based games like Lightwing and Breach), after that I'll talk more about Apart specifically. I've mentioned this before but I've found that minimalism helps a lot not only in finishing Pyweek games, but also in puzzle design. This applies less so to this game than my previous ones, but even here note that I intentionally used a 3x3 puzzle grid. A general rule of thumb that I follow is to make minimal puzzles that are tightly constrained just in the right way. There do exist good complex puzzles that have a broad set of rules but I think those are a lot harder to make it right, and don't fit the scope of a Pyweek. Even then, they are often built by starting small.
I typically start by identifying a core mechanic that I want to play around with. This is what will make or break the game, and this requires a lot of thought. One suggestion is to write down game ideas outside of Pyweek whenever you think of something cool, or whenever you're inspired by a game. I have such a list but I actually rarely use it, but I did have a core idea I wanted to explore for Apart before Pyweek started (will talk about that below). It's also helpful to have some intuition on whether you could build a fun puzzle on top of a core mechanic, and I've found this to be more challenging than it sounds. If I think of a puzzle mechanic, I could try to envision how it would look like in the end, but it is very hard to figure out if it will actually be fun. In most cases, it does require a lot of tweaking, and I've often had to scrap ideas late in the week.
Once I've decided on the base mechanic, I try to produce a few mini-puzzles that will serve as building blocks for the actual puzzles. These are components that need to be as tight as possible and should not have any extraneous parts. I call these "gadgets" because they feel like the "gadgets" you might use when you're proving something is NP-hard (for those with a CS background). The trick to create these gadgets is to tighten them as much as possible, make them minimal. For example, use as few tiles as possible, or use as few components as possible. These should represent only a single desired effect, like a tight tutorial puzzle. This is a process of discovery and it's the part that I have the most fun with when designing puzzles. This will teach you how the mechanics that you've thought of interact with each other. The more you understand the dynamics of your puzzle mechanics, the more you are able to attain depth. I often discover interesting and surprising properties of the mechanics with this process that are very nontrivial to figure out at a glance, and these will help you design your puzzle further. For example, in Lightwing, I was surprised to find out that you can't have particular cycles. In Flip, there are interesting properties related to parity. Sometimes these properties are bad and you have to tweak the mechanic to get it right. Sometimes they are good and you want to design gadgets around them.
After I've figured out some gadgets and decided that this is fun, I start implementing the engine and other things. Concurrently, I try to design a few simple levels. At the end of the week, I typically start constructing the more complex levels. Often my main concern is balancing, but I do what I can in the given amount of time. With these logic-based puzzles, I basically spend the last day producing as many levels as I can.
Apart
That is my usual process, but Apart was different. The core idea that I wanted to explore with Apart was not mechanic-based, but the higher-level idea of having a representation of the game world as a mini-game inside the game, and being able to manipulate one to affect the other. I was intrigued by this idea for a while now and I wanted explore it independently of the theme. I think Castaway was the best outcome for this idea. The theme evoked this idea of exploring an island in which you are trapped, and the idea of manipulating the island itself by playing a mysterious game came naturally. Having it be a jigsaw puzzle popped out after that.
After that, I had to figure out what exactly the gameplay would be. I settled for open-ended puzzles because it's something I've been wanting to do for several Pyweeks now. I was going to do open-ended puzzles for Pyweek #26 (two years ago!), but back then I failed and had to scrap everything on the second-to-last day and developed a mini-game instead. I'm not always successful, but you have to take some risks. :)
Open-ended puzzles can be particularly hard to design as I've found, but I felt like the mechanic I developed was a very good fit for this. It gives you basically two worlds that you can manipulate and opens possibilities. The puzzles themselves were essentially designed by just thinking a lot about them and trying different things on paper. I mainly wanted to play with the idea that you can manipulate both worlds in different ways. I guess there was no particular step-by-step process like the one I explained above, and I had to come up with a (mostly) different idea for each puzzle. And unsurprisingly some of them turned out to be somewhat flawed, but overall I was happy with the result.
In general, the other thing that helps a lot is simply playing a lot of puzzle games. By playing games, you develop a repertoire of puzzle mechanics in your head, and it helps a lot with designing new puzzle mechanics. I also do puzzle hunts sometimes. If you don't know what they are, these are "pen-and-paper" puzzles (well, typically a digital version of that) that often have a hidden "mechanic" you have to figure out. Puzzled Pint is an accessible version of puzzle hunts, but this is a world that can get arbitrarily difficult, e.g. MIT Mystery Hunts. I've seen some puzzles that are incredibly creative, and although Apart is not really a puzzle-hunt-type game, they were my original inspiration in giving a shot at a more open-ended puzzle game rather than the logic-based ones that I tend to develop.
I can write a lot about my design process, so here we go. :) I might have mentioned some of these things before.
This game in particular is a bit different from my other puzzle games. I think I need to split this reply up into two parts: how I typically design my logic-based puzzle games (the bulk of my previous Pyweek puzzle games), and how I designed this one. But to first answer your question, I implement the engine and design the puzzles concurrently. I first try to get the mechanic right and design a few puzzles in a way that feels satisfying, then implement the engine, then I use the engine to help me design more puzzles (usually this is done in the very last day, which is a bad habit because the balancing ends up all wonky).
My typical Pyweek puzzle design process
Let me talk about my typical process first (for more logic-based games like Lightwing and Breach), after that I'll talk more about Apart specifically. I've mentioned this before but I've found that minimalism helps a lot not only in finishing Pyweek games, but also in puzzle design. This applies less so to this game than my previous ones, but even here note that I intentionally used a 3x3 puzzle grid. A general rule of thumb that I follow is to make minimal puzzles that are tightly constrained just in the right way. There do exist good complex puzzles that have a broad set of rules but I think those are a lot harder to make it right, and don't fit the scope of a Pyweek. Even then, they are often built by starting small.
I typically start by identifying a core mechanic that I want to play around with. This is what will make or break the game, and this requires a lot of thought. One suggestion is to write down game ideas outside of Pyweek whenever you think of something cool, or whenever you're inspired by a game. I have such a list but I actually rarely use it, but I did have a core idea I wanted to explore for Apart before Pyweek started (will talk about that below). It's also helpful to have some intuition on whether you could build a fun puzzle on top of a core mechanic, and I've found this to be more challenging than it sounds. If I think of a puzzle mechanic, I could try to envision how it would look like in the end, but it is very hard to figure out if it will actually be fun. In most cases, it does require a lot of tweaking, and I've often had to scrap ideas late in the week.
Once I've decided on the base mechanic, I try to produce a few mini-puzzles that will serve as building blocks for the actual puzzles. These are components that need to be as tight as possible and should not have any extraneous parts. I call these "gadgets" because they feel like the "gadgets" you might use when you're proving something is NP-hard (for those with a CS background). The trick to create these gadgets is to tighten them as much as possible, make them minimal. For example, use as few tiles as possible, or use as few components as possible. These should represent only a single desired effect, like a tight tutorial puzzle. This is a process of discovery and it's the part that I have the most fun with when designing puzzles. This will teach you how the mechanics that you've thought of interact with each other. The more you understand the dynamics of your puzzle mechanics, the more you are able to attain depth. I often discover interesting and surprising properties of the mechanics with this process that are very nontrivial to figure out at a glance, and these will help you design your puzzle further. For example, in Lightwing, I was surprised to find out that you can't have particular cycles. In Flip, there are interesting properties related to parity. Sometimes these properties are bad and you have to tweak the mechanic to get it right. Sometimes they are good and you want to design gadgets around them.
After I've figured out some gadgets and decided that this is fun, I start implementing the engine and other things. Concurrently, I try to design a few simple levels. At the end of the week, I typically start constructing the more complex levels. Often my main concern is balancing, but I do what I can in the given amount of time. With these logic-based puzzles, I basically spend the last day producing as many levels as I can.
Apart
That is my usual process, but Apart was different. The core idea that I wanted to explore with Apart was not mechanic-based, but the higher-level idea of having a representation of the game world as a mini-game inside the game, and being able to manipulate one to affect the other. I was intrigued by this idea for a while now and I wanted explore it independently of the theme. I think Castaway was the best outcome for this idea. The theme evoked this idea of exploring an island in which you are trapped, and the idea of manipulating the island itself by playing a mysterious game came naturally. Having it be a jigsaw puzzle popped out after that.
After that, I had to figure out what exactly the gameplay would be. I settled for open-ended puzzles because it's something I've been wanting to do for several Pyweeks now. I was going to do open-ended puzzles for Pyweek #26 (two years ago!), but back then I failed and had to scrap everything on the second-to-last day and developed a mini-game instead. I'm not always successful, but you have to take some risks. :)
Open-ended puzzles can be particularly hard to design as I've found, but I felt like the mechanic I developed was a very good fit for this. It gives you basically two worlds that you can manipulate and opens possibilities. The puzzles themselves were essentially designed by just thinking a lot about them and trying different things on paper. I mainly wanted to play with the idea that you can manipulate both worlds in different ways. I guess there was no particular step-by-step process like the one I explained above, and I had to come up with a (mostly) different idea for each puzzle. And unsurprisingly some of them turned out to be somewhat flawed, but overall I was happy with the result.
In general, the other thing that helps a lot is simply playing a lot of puzzle games. By playing games, you develop a repertoire of puzzle mechanics in your head, and it helps a lot with designing new puzzle mechanics. I also do puzzle hunts sometimes. If you don't know what they are, these are "pen-and-paper" puzzles (well, typically a digital version of that) that often have a hidden "mechanic" you have to figure out. Puzzled Pint is an accessible version of puzzle hunts, but this is a world that can get arbitrarily difficult, e.g. MIT Mystery Hunts. I've seen some puzzles that are incredibly creative, and although Apart is not really a puzzle-hunt-type game, they were my original inspiration in giving a shot at a more open-ended puzzle game rather than the logic-based ones that I tend to develop.
Tee on
2020/10/11 01:51:
SPOILER ALERT: Do not read this comment if you don't want to know the ending of the story or the solution to the puzzles.Story
The story just came up when I was thinking about jigsaw puzzles and piecing things together. Although it's not a happy story, I quite like it. The idea of someone trying to piece themselves together after a tragedy simply clicked in place with the jigsaw and castaway theme, and it gives it a nice ending twist. I was worried that people might find the story too sad, especially because it touches a subject that might be sensitive. I did get one comment about the ending not being happy, but hopefully it was enjoyable.
I had more events in mind when I thought about this game, but I didn't have time to implement everything. I also ran out of time to add sounds, unfortunately. There were a few things that I had planned (too ambitiously): Jen, the wife, would follow you around for most of the game until you get to the hole. The hole would swallow up Jen, which is why you go inside a cave at some point. This is also why the hole is kind of scary looking: the vines would pull her inside. The playground exists because you would see an apparition of the daughter that would disappear. In a way, all the locations were designed with these cutscenes in mind, but none of these cutscenes got actually put into the game. In the end, I just realized that implementing these would take way too long, and I gave up on them.
Oh, and sorry, I guess the game is not short. :) It just felt short because I could zoom through the puzzles.
Puzzles
I think there were three puzzles that are particularly in need of improvement, and your feedback confirms that: the lighthouse, the cave, and the final one.
Lighthouse: I messed this one up, and had to post a warning about the "bug": you could "shine" the light directly into the hole, and it doesn't do anything. Maybe it needs a bit more hinting, too. The idea is that some of the puzzle pieces serve as mirrors, and it would shine a light back in the hole. I'm not exactly sure what hints I would add, but I feel like it needs something. My goal here was to play with this idea of duality between the real world and the puzzle world, so I didn't want to add actual mirrors in the real world.
Cave: This is a tough one. I like the overall idea but I think it needs to be better executed. I wanted a situation where you could only find the path through the cave by seeing how certain pieces fit (those with the triangles in the corner). But I think the execution wasn't ideal. What makes this very hard to design is that you have the rest of the game and you can't change pieces arbitrarily without affecting the other puzzles. The idea was kind of to find a path back to the playground as if you were going back into the cave, but maybe this is just too hard to express as a puzzle. I should have probably defined a clearer endpoint because the puzzle is hard enough. It's hard to even explain via text.
Final puzzle: I had a different plan for this one, but I didn't have time to make it right, so I decided to make something that was much simpler to design, but more difficult in-game. The main issue with this puzzle is that you have to imagine it, and there is no in-game mechanism to "reveal" the answer. One person noted that you can't really overlay pieces inside the game and another one mentioned it was too abstract, and they're both completely right. My original plan was to make the leftover pieces form a word when you fit them in the only way possible (either in-game or in-puzzle, I hadn't decided). But the issue is that I couldn't control the shapes of the pieces due to other puzzles. I tried for a bit, but this was one of the last puzzles I designed and it just was too risky to introduce "bugs" in other puzzles. In the end, I went with the simpler-to-design overlay idea, which I think just doesn't really click with this game, but it was the easiest way forward given the time constraints.
Overall, as I mentioned above, what makes the puzzles hard to put together is that they can interfere with each other, and you have to make sure they don't. I think it's possible to make the puzzles cleaner, but it needed time that I didn't have. I also think that I should have more softly eased the player into this idea of open-ended puzzles within the game. But it's hard to explain open-ended puzzles because there are no hard rules.
All that said, I had a lot of fun designing these. I think they need tweaking, especially in terms of difficulty, but I'm generally happy with how they turned out.