I’ve been working on a prototype for an idea I’ve had for a while that I’ve nicknamed Robo. It’s inspired by the Karel J Robot tool that I was first introduced to programing with. The idea is essentially a puzzle game where you can graphically program a robot and use it to solve a map and collect the needed items. In my prototype the goal is to collect all the gold that’s on the map but that’s not enforced. You can try the prototype yourself through the jar version. You can also try to run it from source.
The UI is simple: there’s a left panel with the world you are operating in. The world is infinite in size and you can pan around by clicking and dragging the world and zoom in and out with the mouse wheel (sorry people without mouse wheels).
The right panel contains the programming UI. Programming of the robot is controlled by placing 14 icons in the top right corner in the control grid below. The control grid is infinite in length and can be scrolled down by clicking and dragging it. Program flow starts on the top left and goes in reading order: right and then down. Empty spaces are allowed and are skipped over. The meaning of the icons are as follows:
|Moves the Robot one tile in whatever direction it is facing|
|Rotates the robot 90 degrees counter clockwise|
|Rotates the robot 90 degrees clockwise|
|Drops a detector to the tile in front of the robot if there’s a detector in the robot’s inventory and nothing in the spot the robot is dropping it in|
|Indicates the start of a routine. When this tile is placed a pop-over comes up asking you to name the routine. If I were to implement the prototype more, this name would be used in configuring other tiles as well. Execution of other routines don’t flow into later routines. Currently the name of the routine should be A, B, or C to be useful.|
|Jumps execution flow to the routine labeled as A. If no routine exists labeled A, this does nothing. After routine A completes, flow continues in the calling routine|
|Jumps execution flow to the routine labeled as B. If no routine exists labeled B, this does nothing. After routine B completes, flow continues in the calling routine|
|Jumps execution flow to the routine labeled as C. If no routine exists labeled C, this does nothing. After routine C completes, flow continues in the calling routine|
|Looks at the tile immediately in front of the Robot and sees if there is a detector there. The result of the look is stored in the memory buffer.|
|Looks at the tile immediately in front of the Robot and sees if there is gold there. The result of the look is stored in the memory buffer.|
|Looks at the tile immediately in front of the Robot and sees if there is a wall there. The result of the look is stored in the memory buffer.|
|Jumps to A like the earlier jump command if and only if the value in the memory buffer is true. Otherwise it does nothing|
|Jumps to B like the earlier jump command if and only if the value in the memory buffer is true. Otherwise it does nothing|
|Jumps to C like the earlier jump command if and only if the value in the memory buffer is true. Otherwise it does nothing|
The binary version has a few different worlds attached to it and you can toggle between them by pressing the F1-F4 keys. These worlds are solvable meant to give an idea of some of the things you can program the robot to do. These would probably be more intermediate level puzzles as I expect they would be challenging to a non-programmer and trivial to a programmer. The prototype includes level editing capabilities so you can try making some maps yourself:
W: Move forward
A: Turn Left
D: Turn right
S: Go backwards
U: Drop a detector in front of you
I: Drop gold in front of you
O: Drop a wall in front of you
Backspace: Erase anything in front of you:
Arrows: Place a wall in a direction from you
Home: Increase gold inventory
End: Decrease gold inventory
Page up: Increase detector inventory
Page down: decrease detector inventory
Ctrl-F1 (through Ctrl-F6): Save world
F12: Clear world
Ctrl-z: Undo a world load
I think you can get an idea of the things I was considering from the prototype, however I am unsure of whether the idea is worth pursuing further or which way to pursue it. Thanks to the wonder of Turing Completeness it’s possible to make a system that is very powerful and follow the example of Minecraft Redstone. That’s to say, create a more sandbox type of system with puzzles to provide specific challenges and guidance but with a goal of being more open-ended and powerful. Alternatively I could try to hold truer to my original idea of the game being more of an educational tool by focusing on simplifying it and providing good puzzles with powerfulness being a ‘nice to have.’ This decision also pertains to the platform decision. Were this to be a sandbox, there is much more of an argument to be made about it having a pc/mac platform than with an educational game. For an educational game, the goal of simplicity with the current drag-heavy interface lends itself well to a touchscreen, though perhaps more towards tablets than phones.
The prototype was implemented in Java with libgdx, which provides platform abstraction, allowing you to run on both PC and Android. This was probably a mistake. With it being my first venture with libgdx, I found out that it is poorly documented and lacks some basic features and libraries compared to the Android API. While libgdx is a great tool for its purpose, its purpose is not prototyping. Granted, Java itself was a bad choice for that too. Oh well.
For the prototype I used art assets from opengameart.org, a great resource for game assets. I still managed to programmer art it up with my lack of animations and lack of design, but that’s what a prototype is for. Specifically, I used some assets from IconDock, a basic airship by Alex Pineda, and a few Dungeon Crawl tiles.