The "Little Pythagoras Deluxe" development process is pretty unusual.

1. Sketch puzzle design during meeting at work
2. Do basic proof-of-concept
3. Script puzzle
4. Shoehorn puzzle into plot

Aside from the gameplay development prcoess described above, there is the "polish" phase, which falls is scheduled to the time between working on puzzles.

1. Become frustrated with trying to script something
2. Obsess over small details of something else

Of course, one should normally plan everything out ahead of time, but this works for me since this game is meant to be mostly a tech/talent demo. "Gone Tomorrow" (the next project) is going to actually be outlined and written ahead of time with a design doc and all that jazz.

Today I scripted an aqueduct puzzle, involving rotating secitons of an aqueduct to guide the flow of water to certain areas. I was under the impression that the Romans invented aqueducts, but I looked it up on wikipedia, and like pretty much everything else, the Greeks did it first. In fact, one of the Greek aqueducts existed on the island of Samos, where Pythagoras lived, no kidding.

Of course, it was a tunnel, and didn't have rotating sections, but hey, if you want historical accuracy, read a book.

Oh man, why has no one thought of this before: Steampunk Transformers. If this comic book makes the transition into toys (and those sketches look pretty darn close to toys already), I would totally shell out mad cash for that ironclad Shockwave.

I wonder how many tons of coal it takes to make one energon cube?

Up until about 5 minutes ago, I was under the impression that "Snakes on a Plane" was not actually a real movie. I stand corrected.

So, "Little Pythagoras Deluxe" (I'm pretty sure that the title will change at some point), has changed significantly from my first thoughts of merely recreating the old World Builder title. Though I'll definitely be lifting a lot of older puzzles and content, I'm trying to add in some actual plot elements and move the emphasis away from mathematics towards more logic-based puzzles, primarily Sokoban-style pushing puzzles.

Sokoban is an old Mac title, orinally Japanese, which has been ported and cloned many times over. Making a Sokoban game now really has little purpose other than as a programming exerice. However, many Sokoban games are simply clones of the original, often they'll have the same puzzles.

I cannot easily recreate Sokoban with RPG Maker, since I can't record the locations of events, only the player character. Thus, there is no way to know if a rock event has been pushed to a specific point. This limitation forces me to think of new puzzles.

This leaves me with a couple of basic Sokoban puzzle types (in addition to other types of puzzles, they're not all about pushing blocks): one Zelda fans will recognize, pushing blocks to get past them, and pushing blocks to one point. The first kind is easy enough, the second I have to cheat a little to tell when blocks reach that point, I just check the character's position rather than the block's position. This mean that the player character can push rocks into a bottomless pit, or push them into a stream to make a bridge.

Puzzles of this type also require being able to reset the puzzle. Unfortunately, there is no command in RPG Maker to simply reset a map to its initial state. Thus, in order to make sure that the player is free to experiment without worrying about accidentally blocking themselves in or otherwise screwing up a puzzle beyond completion, I need to make two identical maps for each one. There's also a common event that I can turn on and off depending on whether or not the player is currently engaged in a pushing puzzle. When it's triggered, I send the playe rot the other map, where all the events are reset. Fortunately, when entering a map, all events are at their initial state, so I can toggle back and forth between two maps to restart.

Not the most elegant solution, but working with limitations like this are what keeps things interesting and forces me to think of unorthodox solutions.