Push Pull Postmortem

I wanted to share some general game design thoughts I had from the development of Push Pull. I hope it's helpful to some of you.

Push Pull is a puzzle game that I originally made for the GM48 game jam in October and continued development on, releasing on Steam this weekend. The Steam page is here if you want to know more.

Developing with Game Maker Studio 2:

Overall I'm a big fan of the software. It allows very rapid development, the inbuilt sprite editor is pretty solid (from a non artist's opinion) and for a game this size I didn't have any of the file management issues others have raised. Also, a one off fee is a great deal and only gets better the better your game sells.

One of the issues I had is that views/resolution isn't straight forward for novices and always causes some issues in every project I do. I find a lot of the video tutorials about this are incorrect which isn't helpful (the best one I have found is Pixelated Pope's but the way he sets the application surface causes scaling issues on rotated sprites for me). The other issue was around my discipline with creating groups to organise files and putting repeated sections of code into scripts, it takes a bit of time but saves more in the long run.

I did have one bug that I launched with. When quickly alt-tabbing when opening the game it fails to open fullscreen and the functions to change the view to fullscreen don't work. As this is a minor issue I launched with it and have yet to resolve it. I'm not sure if this is something any of you have experienced.

Puzzle Design

As this is a puzzle game, puzzle design was the primary struggle. I did research and have concluded that there aren't any easy answers, I have some "general principles" I found/developed that I'd like to share.

• Macro and micro design: this probably isn't the correct terminology but it's important to think of both individual levels (micro) and the order those levels are put together (macro).
• Macro level design: A good way to group levels is by mechanics. First show every consequence of a single mechanic alone, then show it in combination with other mechanics. For example if my game had mechanic A, B & C, I would create groups of levels with the following mechanics: A -> B -> C -> A+B -> A+C -> B+C -> A+B+C. Within each group of levels I would also ramp the difficulty. This system doesn't overwhelm players and produces a naturally increasing  difficulty curve across the game with peaks of difficulty at the end of each group of levels. I got this method from this video which is one of the best out there on puzzle design.
• Micro level design: this is the hardest part. The best levels in my opinion will have a purpose, typically to teach a consequence of the mechanics, and have as few elements as necessary. They shouldn't test memory or be difficult/time consuming to solve once the player understands. The best thing I can recommend is to program your mechanics and play with them and really understand how they work in every situation. Often when I programmed my mechanics there were consequences I hadn't foreseen that became some of my favourite puzzles. Once you have some good puzzles you can analyse them and look for common factors. For Push Pull, corridors with corners and enclosed areas were common in the better puzzles as it either forced the two characters to work together or because they would get in each others way.

Development Mentality

I personally think too many developers spend too much time on their code so I sometimes code in a sloppy way to finish projects as quickly as possible. Sometimes this makes sense but occasionally it backfires. For example, the dialogue system in this game I did in a sloppy way but because I had to use it so many times it would have taken less time to develop a proper dialogue system to begin with, which also could have been used in later projects. The real mistake was not taking the few seconds to think whether this was a piece of code I'll write once and never look at it again, or will I be using this many times in this game, or even into future games (if you are in this for the long haul).

Also, I probably spent too much time on art I knew was going to get redone by an artist eventually. Spend as little time on art (and music/sound) you know will get replaced as you can tolerate. 

Thanks for your time.