I have been using Playmaker a lot recently. Playmaker is finite state machine and visual scripting editor for unity. I like it a ton.
A finite state machine is a sort of burly flowchart. Rather than have simple yes/no options at the intersection of the flowchart, you have states that a program can be in. If you were creating a character movement system for a game you could have a state that waits for player input. Input would trigger another state where the character would move based on that input. There can be another state also running that would watch for collisions and transition the character out of movement and into a collision animation when they hit a wall. States can be one shot effects, that terminate on completion or transition back to a previous state, or they can be loops that run continuously until some criteria is met triggering a transition. There are probably as many ways to wire these states up as there are people who look at the problem. While not all programming problems can or should be solved using finite state machines, they are ridiculously powerful tools. They are especially useful for videogames because games by their nature are interactive and reactive computer programs. Input produces output, and everything is based on interlocking systems and rules.
Playmaker is also a visual scripting tool. One of the main selling points for visual scripting is that you don’t need to know a programming language to use it. Most tasks in a visual editor are drag and drop, click buttons, and fill in input field operations. Of course, not needing to know a programming language is a long ways from not knowing how to program. Playmaker can streamline the process a bit, but you won’t get much out of it until you can plan out a logical sequence of events. If you have some experience with any programming language you will have a much easier time navigating Playmaker. C# happens to be the language that Playmaker is written in so that might be a good place to start. Then again, I started with z80 basic, so what do I know.
Of course a lot of people come to these visual scripting tools with no programming knowledge at all. Without context it may be more difficult to figure out what’s going on in Playmaker, but I think this is where these types of tools really shine. I feel relatively comfortable shifting back and forth between Playmaker and C# scripts in the “knows just enough to be dangerous” sort of way, but I could imagine someone transitioning smoothly from learning a visual scripting tool to learning plain old, no tool assisted, programming. In fact, I think this will be the preferred way to teach programming to kids until we can come up with something better.
For the project I’m currently working on, I plan to use Playmaker as much as possible. Occasionally that has meant writing a quick addon script for it in C# just so I could do something that was difficult or cumbersome inside the visual tool. Keeping all my game logic in the state machine framework of Playmaker is also incredibly useful.
A finite state machine is a sort of burly flowchart. Rather than have simple yes/no options at the intersection of the flowchart, you have states that a program can be in. If you were creating a character movement system for a game you could have a state that waits for player input. Input would trigger another state where the character would move based on that input. There can be another state also running that would watch for collisions and transition the character out of movement and into a collision animation when they hit a wall. States can be one shot effects, that terminate on completion or transition back to a previous state, or they can be loops that run continuously until some criteria is met triggering a transition. There are probably as many ways to wire these states up as there are people who look at the problem. While not all programming problems can or should be solved using finite state machines, they are ridiculously powerful tools. They are especially useful for videogames because games by their nature are interactive and reactive computer programs. Input produces output, and everything is based on interlocking systems and rules.
Playmaker is also a visual scripting tool. One of the main selling points for visual scripting is that you don’t need to know a programming language to use it. Most tasks in a visual editor are drag and drop, click buttons, and fill in input field operations. Of course, not needing to know a programming language is a long ways from not knowing how to program. Playmaker can streamline the process a bit, but you won’t get much out of it until you can plan out a logical sequence of events. If you have some experience with any programming language you will have a much easier time navigating Playmaker. C# happens to be the language that Playmaker is written in so that might be a good place to start. Then again, I started with z80 basic, so what do I know.
Of course a lot of people come to these visual scripting tools with no programming knowledge at all. Without context it may be more difficult to figure out what’s going on in Playmaker, but I think this is where these types of tools really shine. I feel relatively comfortable shifting back and forth between Playmaker and C# scripts in the “knows just enough to be dangerous” sort of way, but I could imagine someone transitioning smoothly from learning a visual scripting tool to learning plain old, no tool assisted, programming. In fact, I think this will be the preferred way to teach programming to kids until we can come up with something better.
For the project I’m currently working on, I plan to use Playmaker as much as possible. Occasionally that has meant writing a quick addon script for it in C# just so I could do something that was difficult or cumbersome inside the visual tool. Keeping all my game logic in the state machine framework of Playmaker is also incredibly useful.