Here's a little design process doc for my game Little Lost Robots made for the Blackthornprod Game Jam.

Inspiration: The theme of the jam was Game Development. I've recently come to love these programming-esque games. Zachtronics Opus Magnum is my current favourite. The idea of setting up a series of commands and then letting things run to see if it crashes or beauty ensues. I immediately thought of that when I heard the theme.

It was two days into the jam though before inspiration for Little Lost Robots hit. I thought instead of having each object (robots in this case) have a string of commands, what if the commands were placed on the game play area itself? A simple play with Game Maker with how to setup a very simple grid system and voila we had the barest prototype. A robot that would run around and change positions on command.

General Game Design: Initially I had a lot of ideas with these robots. I thought maybe they could combine together into different robots, or maybe different robots could go through different elements, or maybe they could pick up different elements to combine them, or they had to press a button(s) to open the exit. 

What I've discovered having participated in two game jams now, is that game jams are great for forcing me to narrow things down to one simple strong idea and building on it.

So, I threw out all the really complex ideas (which would have taken ages for me to figure out what the game play was and then how to code for it) for a very simple but clear idea. Place down instructions to direct the robots to the exits. I think this simplicity really worked in creating a strong game loop and creating immediate player understanding.

For this I actually hacked away a lot of distractions players will never know about and take for granted. For example: the robots remember their initial direction orders even when the level is reset. I reduced the number of buttons in the game to just the mouse button (I eventually opted to keep the right mouse button as cancel instead of reducing it to just the left mouse button because the "delete" move felt strongly negative to the positive "create" and "activate" actions of the left mouse button). All of this to reduce distractions and help the player think of one thing only: where should the commands go?

My reward was to watch players rather seamlessly get into the game. I was proud to see little confusion as my test players started the game and slowly figure it out. 

Level Design: I really wanted to teach players the game without words. In the end though, I did have instructions in the first three levels of the game just in case.

However, in the earlier builds where there were no instructions, players didn't seem to have an issue even discovering how to delete orders. Players seemed to know to drag and drop the buttons, delete the commands, and reset the level by pure UI design. It was great watching.

Example: The start screen has a big obvious green button that says "Start" under a "Commands" bar. Naturally people press that. The button gives feedback by flashing when clicked to acknowledge the game has started. The button now turns into a "Play" button.

The first level is designed to have the robot going the wrong way. If the player presses the play button the robot will crash into the rocks. The "Play" button now turns into an orange "Reset" button. Players immediately learn that levels can be reset in seconds. More experienced or intuitive players would have noticed the blue arrows around the robot. Those who crashed the robot would immediately take note of them after the reset. Clicking the arrows change the direction the robot starts off in. Another lesson learnt. No words given.

The second level introduces a single "Up" command arrow appearing out of nowhere. There is no way for the robot to reach the exit with the blue arrows. Intuitive players (almost all my test players) simply dragged and dropped the "Up" command automatically. I inserted text just in case people weren't familiar with the idea.

I continue to build every level in this fashion.

With each of the twenty levels, my principles  of puzzle design was that the design had to be surprising, curious, or aesthetic. Surprise comes with what on first glance looks challenging or even impossible to accomplish: a sudden burst of enemies or a new obstacle. Curiosity comes often from either new elements or a new way for things to interact with each other. Aesthetic comes from the visual design. In this game I went for a lot of symmetry whenever I could incorporate it.

The levels build up in difficulty. I would often get an idea in my head of what a problem could be. Test out the idea in the level editor and discover it wouldn't work like I thought it did. But this was good because after a few iterations, interesting problems and solutions presented. I probably threw out 3-5 levels. Once I had the levels made I arranged them in terms of introducing the different elements, as well as increasing difficulty.

The last two levels in particular produced in me that particular satisfaction of beating something really hard when I solved them. Even better, I didn't necessarily know that they were even actually solvable! The last one took me more than two hours to discover the solution. I'd be fascinated to see how others respond to it. Perhaps it is too difficult? Or perhaps players will take pride in being the select few to beat a hard game. I would need far more test players to know that.

Art and Music: I was able to engage quite a talented composer, a Daniel Docherty this jam for the game. I quite like his tune. It grows on you and has the dangerous quality that it might get stuck in your head. 

With sounds I went and scoured OpenGameArt and Freesound. I did my best that every action the player made would have a little feedback to it. Whether this was placing commands or the reset button. However, I found only the temperature buttons required feedback sound as the directional buttons were far too confusing if they played sounds when the robots stepped on them.

Art wise I went for a cute pixel art style (my automatic current style with Game Maker anyway). Again the art was to help the player focus on where to place commands. (This was actually true of the sound too). Simple, bright art. Perfect for the game and the game jam time limit. I think if I could, I'd actually make the game a little brighter and even more cheerful (perhaps to counteract the frustration of the last few levels.

Things I would have liked:  
A variety of backgrounds to break the scene moods.
There were a few more ideas for commands such as a stop sign, and a directional one that changed with each subsequent robot that stepped on it. 
More music, probably one during the planning phase and another in the play phase. Or simply different music with different levels.
A better transition screen with more player reward for having completed a level.

Thank you for reading. All the best with creating and playing more games!