Wow! We have two visual shader tools and now two visual scripting tools. That’s fantastic. I’m not going to have time to try this for a while but I’ll be interested to learn how it compares to “VIZIO”.
Hi,
i’ve been testing Playmaker for few hours now and have to say that it’s very impressive, great great tool, congratulations.
The samples scenes aren’t imported with the packages, and they seems to not work even if we copy the “PlaymakerSamples” folder as no meshes are visibles when i load a scene…am i doing something wrong ?
.
Thanks!
The easiest way to play with the samples is to unzip the download to your unity projects folder and open it as a Unity project.
You can then open any scene in PlaymakerSamples.
The playmaker package lets you import Playmaker into other projects.
Not sure why you wouldn’t be able copy the samples folder… I’ll try it on my end and let you know. I may need to make a samples package.
I like it very much, are you planning any 3rd person movement logic?
Thanks! I have a long list of Actions I want to make… including 3rd person controllers, iOS input, camera transitions etc.
I think the beta is close to the basic set of actions that will be in the initial release, but I’m always adding more!
The final release will also ship with Templates for common state machine structures. See Templates Browser The beta doesn’t ship with any templates yet, but you can make your own…
You can also use Playmaker to control regular scripts on objects (e.g., Unity’s default movement controllers). See Script Control Actions.
Finally, it’s fairly easy to write your own actions (docs coming soon). Playmaker ships with lots of examples that you can use as a starting point.
The ultimate goal is to build a comprehensive library of actions and templates so you can quickly prototype and build almost any idea within Playmaker without scripting.
Here are some suggestions。
look like playmaker can’t support List or Array Properties type?
- support more data type.
- support [GameLogic] user custom ActionCategory.
- PlayAnimation action can’t fire finish event.
- action can change to Modifiers liked framework. (HBT etc).
Thanks for the feedback!
We plan to support Lists/Arrays in Actions in a future release. Also more data types!
You can make your own Action Categories; the enum is for convenience, but you can use a string instead. We’re still finalizing the categories - GameLogic is a good one - we’ll add it to the enum.
I’ll look into the PlayAnimation finish event. You might be running into the issue described under finish event in the docs: here I’ll take another look at the action though, would be better if it “just worked” without extra documentation…
Not sure what you mean by Modifier framework…? Can you be more specific?
what is your current idea of what the price range might be when it is released? This sounds very interesting since I am more of a model junkie then a scripter and something like this would be a BIG help.
Oh WOW!
Man, this is looking great!
I will be looking at this as well as the other 2 Visual programming projects VERY closely.
Would it be possible for people to create actions/states and share them?
EDIT: I see we just might be able too 
Writing Custom Actions
This is very good news.
I think unity will see an indirect uptake as well just because of this.
.
looks damn great thumbs up
Wow! Amazing! Feels great to have finally a visual scripting tool! Thanks, I can’t wait for the final!
Something is not completely clear to me. In the State tab, does the order of the actions make any difference? I mean when i put an action on top of the list will the action under it be “played” after the first action?
And I found something a little bit annoying; when I close a tab (eg Actions) the whole Playmaker window closes.
Alex,
A fantastic piece of work, well done. Although I shall probably stick to coding my stuff I can see that a lot of people coming to Unity will see a huge benefit to a package like yours.
Out of interest and in relation to the other visual scripting tool - how does this compare to hand coded scripts at runtime? Is there a performance hit when you have a lot of interactivity going on in your game for example?
Give yourself a big pat on the back though - its a great piece of software!
Best Regards
Just curious. Unreal Kismet is great when working wirth one map/scene but when a new map is loaded your Kismet is not transfered to the new map so game code does not work well. (like cameras and fighting systems) Will PlayMaker stay consistant when loading a new scene, so if I make a special camera type or a fighting system or what ever, will it work through out all scenes in my game?
this is great!
Thanks for this!
Thanks for the feedback!
A few people have asked about price. We haven’t settled on the final price yet, but we can say it will be under $100 for a single user license.
@Frido: Actions are activated in the order they are listed, from top to bottom. Check out this doc for more details. If you only read one page in the docs, this is the page to read!
Editor windows closing when you close a tab is standard Unity behavior - I don’t think there’s a way around this. You have to undock the tab before closing… unless I misunderstand the problem…
@mmuller: Thanks! The biggest performance hit happens when creating the state machine the first time since it uses reflection to create the Actions. After the state machine is created performance impact should be minimal. There are potential optimizations I can explore if it becomes necessary…
@n321: Great question! Playmaker FSMs are attached to Game Objects, so any game object loaded with a scene starts running it’s state machine as soon as the scene is loaded. You can also use Playmaker FSMs on prefabs - so you can spawn a game object complete with its own state machine.
For persistent behavior across levels, there are a few approaches you can take:
-
Use the start state to initialize variables in the state machine. E.g., a Camera FSM loaded in the level might use FindGameObject to find the hero.
-
Load persistent objects first then use the additive option in LoadLevel. You could use DestroyObject before loading the next level.
-
Use DontDestroyOnLoad to keep Playmaker FSMs between scenes. I’ll make an action for that, so you can set it within Playmaker.
-
Use the LEVEL LOADED event (see Events) to re-initialize state machines after a level is loaded (e.g., move the camera to a start position).
This is a great topic for the Playmaker help wiki. I’ll add it when I get a chance…
Thanks again for the enthusiastic reception! I can’t wait to see what you guys make with Playmaker!
New beta coming soon with a couple of bug fixes:
- Playmaker FSMs were broken in the web player.
- Blank events were showing up in Actions/Event Manager.
In the top right hand corner a banner saying playMaker comes up when I make a script… Is this meant to happen and does it have to be there. Can I take it down?
The banner is only in the beta. The final version will be banner free…
After having use both for a bit, I currently prefer VIZIO. Very easy to extended and create your own blocks. Will be interesting to see how Playmaker and VIZIO develop through the beta period
VIZIO looks really cool - can’t wait to play with it myself!
However, I think Playmaker and VIZIO are solving slightly different problems, so it’s not necessarilly an an either/or situation - I suspect they might actually work quite well together…
In my experience with rapid development you can make very quick early progress writing/wiring up scripts, but over time coordinating all these scripts gets harder and harder. Eventually you have to refactor and build more organizational architecture, or you find yourself gravitating towards another project… that you make very quick early progress with, but over time…
Playmaker is designed to facilitate rapid development though early prototyping all the way to finished game by providing a visually intuitive way to manage state.
In a typical game you have to manage a lot of state - animation states, game modes, interactive objects, cut scenes, menus, AI behaviors, story, button presses, spawning, dying, etc.
Playmaker lets you visualize, build, preview and debug state machines that control all of these different aspects of your game. It provides a common organizational framework and transparency. Instead of trying to figure out what’s going on in the scene, game objects are labeled with their state - the door is closed, the button is broken, the guard is sleeping, the gun is reloading… in the editor you can quickly see all the possible states, and the events that trigger transitions.
Actions, while similar to virtools style building blocks, are essentially scripts that run while a state is active.
In some ways the distinction is subtle since you can build virtools style graphs using states and low level actions. However, if you embrace the State/Action paradigm in Playmaker, you should find that it provides an intuitive way to organize and control the behavior of everything from a button, to a cut scene…