If you're an artist or designer, you may find that your ability to code seems opposite to your main talents -- I have certainly found this myself! My main passion is game design, but without code, you can't make a game, right? With tools like Unity and Playmaker (a visual scripting system for Unity) this isn't necessarily the case.
After working part time on a couple of games, Zombie Outbreak Simulator and Class 3 Outbreak for a few years with Binary Space's programmer/CTO Saxon Druce, I was looking to add more titles to my game designer belt, but at the same time I wanted to keep things small-scale and achievable.
I had been playing a lot of iOS games while we ported Zombie Outbreak Simulator to iOS, and Tiny Wings in particular had me completely enthralled. From a gamer standpoint, I loved the feeling you got of being in the zone, getting perfect jump after perfect jump. From a business standpoint, I loved that it was essentially one level and extremely simple gameplay, hence quick development time.
After toying with a few ideas for games, I ultimately decided to try a version of Tiny Wings that was first person, in 3D. Using just Unity, I struggled through some basic physics code to get a ball rolling around on its terrain engine (I can hear you laughing) and after a week or so, I was quite happy with the result.
Somehow -- I think while looking through Unity's Asset Store -- I found Playmaker. Playmaker is a visual scripting system / state machine manager, which uses states (which house actions, each a snippet of pre-written code) and transitions to develop a game. A highly simplified example: You can attach a finite state machine, or "FSM", to a character with the states "fighting," "idle," and "walking."
Within each of these states, you can include animation actions, raycasting/shooting actions and movement actions. You transition between each state using events, i.e. within the idle state, you would add an action that waits for a left mouse click. This left mouse click triggers a transition event to the shooting state. Each action in a state is essentially a pre-made piece of code that you can tweak and fit together to create a state machine, and eventually an entire game.
Playmaker's Test Lab example scene, which controls simple opening/closing doors
You can see from the above image how, for the non-technical, these visual state machines are so powerful. When I look at a block of code, I see a wall of text, and try in vain to understand what it does, when it triggers, and what it's doing at any given point. With Playmaker, I can glance at an FSM and see what it does in almost an instant.
I can also see not only what it is doing in real time in the visual editor, but also in the game view, where each object will display which state it is in. I can't tell you how good this is for debugging and just general understanding of what your FSM and the game in general is doing. Add to this things like debug rays, break points, and more, and you get a very clear understanding of what's happening.
Using Playmaker, I've just completed my first (mostly solo) creation, Unknown Orbit, where you can float, jump and fly around a surreal, 3D planetary system as a comet. Part-time, this game has taken me about a year. Full-time, I imagine it would have taken six months, and now that I've learned Unity and Playmaker to a greater level, I think the game could be recreated in a few months if not less.
Here's a quick example of an FSM for Unknown Orbit, where the player picks up snowballs. On the left are the states and transitions that control when we move between states. The middle pane is currently showing the actions inside the "destroy self" action. In this FSM, when the player flies into a snowball and picks it up, an event is broadcast called "Add snow".
The comet object hears this broadcast via a "global transition", and enters a state that increases the radius of the comet's ice core.