[while'd]: a Post Mortem

Ludum Dare 47 is on its final week so we wanted to write down a couple of things in order to say goodbye to the Jam (and everyone of you!) and also as a conclusion to our journey with [while'd].

Stuck in a loop, like, literally

The main idea for our little game came surprisingly fast. Being stuck in a coding loop was one of the first things we came up after reading the main theme for the jam. The main challenge was adapting that idea to something "entertaining". After brainstorming our way through different game-scenarios, we settled in a simple puzzle game based on while rules. My main fear, as the game designer, was to find that this idea was not entertaining at all. It sounded kinda interesting in my mind but, in the end, we all agreed in one thing: we needed to try it. This is not an ideal scenario: in a game jam you work with limited time so prototiping something fast in order to check if it works is usually not a good idea at all. But as the game took form we grow more and more confident in our idea.

The main advantage of our design was that it was really simple but had a lot of potential to grow. This is an interesting learning point and one that I'm really sure can be applied in future game jams: start simple, grow bigger. In other words; if you can, stuck yourself in a design loop, iterating levels and introducing new ideas with each completed loop. But, of course, beware, the clock is ticking.

 72 hours to go

The development period was surprisingly pleasant. We all did our part and gave feedback on every aspect of the game. We stuck to our roles: designer had the last word on design, animator on animations and so on. But in the end, as a team, we trusted each other and tried to accomodate the game to every one desires. Some examples of that: the last screen of [while'd], as cryptic as it is, was a bit more weird an different, with several exit doors and a special rule that required the player to not do anything (literally, like, not pressing anything for a couple of seconds) in order for the level to be completed. It was weird. Actually, it was TOO weird, and, as the different members of the team tried it and gave some feedback, I decided to change it to a more approachable puzzle. There was no need for overcomplicating things, and I only saw this after receiving some feedback. Same could be applied to other fields like art or animations.

So our main learning point for the developmet process is, of course: get someone to try your thing and give you honest feedback. As hars as it can be sometimes, feedback will help you improve the final product. Always.

 Puzzle games are hard

One of our main challenges while creating [while'd] was the fact that creating puzzles is not as easy as it could seem. One could create a first level that is too simple and then ramp up the difficulty too much in the second level without thinking about it. The opposite could also happen. In the end, feedback helps a lot but, what is most important is focusing on the main mechanics of your game. For [while'd] our main mechanic was the "while loop", so, as the designer, I focused first on the rules and second on the shape of the levels. My main objective was to introduce always a new rule on each screen and, of course, make the experience feel somewhat interesting. And, to be completely honest, I don't know if I really succeded on that field.

With limited time and resources, we aimed for 5 levels and no tutorials. This means, the player needs to learn how to play your game ASAP. This was not an easy taks to achieve in a game were some actions are forbiden from minute 0, but I think we achieved a nice balance here (control prompts on the first level really helped, tho). But, regarding the difficulty of each level and its "joy" factor, I really think we hit a middle ground. Replaying the game now I see there is a lot of room for new rules and different levels, with more interesting and balanced challenges. This could sound really obvious but, in the end, only trial and error can help you hit the right balance.

 What went right

• We aimed for a particular aesthetic and I think we really nailed it. With our resources and time, the smartest thing was to focus on something simple but really attractive, and our "coding aesthetics" seems to have attracted lots of players.

• Our design philosophy ("start simple, grow bigger") really helped us develop an interesting and not too overambitious game for the jam. Sticking to that mentality, we developed the first screen and the main rules in less than 8 hours, leaving the rest of the first day for art + animations. The second day was dedicated exclusively to levels while the last day was only polish.

• Animations matter. Focusing on implementing really satisfying animations for the main character was something that, in the end, really payed off. They contribute A LOT to the fun factor and make the act of controlling the character really rewarding.

 What went wrong

• As I said, trial and error helps striking a right balance but, in the end, a developer/designer is always subjected to its own opinion. I, personally, failed here, creating a short game that can get frustrating really fast. At least the "cheat code" for skipping levels helped some players reach the ending. Without it, it could have been a disaster.

• Neither of us noticed in our play sessions that the "while screen" can get boring really fast. This issue also contributed in escalating the frustration factor.

•  No tutorial levels. Yup. If you are going to develop a puzzle game, take your time to introduce the player to your control scheme and rules via some simple and easy screens. It matters.

The future

We are not planning on developing [while'd] as a full game at the momment. But we are planning on releasing [while'd] v2.0 as soon as jam ends. This build will include some fixes to the code, a complete revamp in the third screen including platforms that move with the player, some tutorial prompts in the first two runs, a marker that lets the player know which rules has broken each time he/she dies and, last but not least, an important change in the game: breaking a rule will now make the player re-start the level from that particular rule instead of from the beginning. Meaning, if the players breaks rule 1, he/she will have to start the level from the first rule (like previously) but, if he breaks the third or second rule, he/she will be able to re-do the level from those rules. So, now, instead of removing the progress from the player after a failed attempt, it's up to him/her to control its progress.

We really thought about this, contemplating options like not removing any progress at all from the player, and, in the end, I decided we needed to maintain a degree of challenge in the game. Removing the penalty from breaking a rule could remove the frustration factor, of course, but it also could contribute to create a non impactful experience. In other words, "no pain, no gain".

And that's it, hope you enjoyed our conclusions. As soon as version 2.0 is ready (and the jam is over), we will update our Itch.io/Ludum Dare page with the proper links. Thanks a lot to everyone who played [while'd] and see you in the next Ludum Dare. Stay safe!!!