Playmaker worth it for experienced programmers?

I've been a professional developer for 6 years, I know C# inside and out, and though I'm new to Unity, I have no problem writing scripts to accomplish things. Only a few hours in, my game is progressing nicely, but, like most people, time is my most precious commodity, so I'm open to anything I can do to expedite things.

The reviews for Playmaker speak for themselves, and I'm considering grabbing it while it's $45, but it's a product that sells itself as an alternative to knowing how to code. Some of the reviews speak to it being a boon to experienced developers. Can some people here weigh in as well? Is it worth it if programming is your wheelhouse?

Thanks.

 

Well I think its more for artists or people who cant program if you watch etsskis video about qube it was made using UDKs visual scripting language, they made the whole game without any programmers.

 

i bought it when it was on sale... opened it twice and i think i'll never use it. it's much faster for me to code.
anyway i'll keep it for my son when he'll want to start developing a game

 

I wouldn't describe it as an alternative to knowing how to code. You can get so far using just PM and little coding knowledge but the more code you know the better the output will be. I'm a very average coder, more of a 'designer' and my major downfall is keeping things organised.

I soon lose the 'flow' of a project and become frustrated after going through pages of texts and scripts and keeping the connection between them...this is where PM comes in for me. The flow is natural, I even pencilled in the start screen of my first/current Unity/PM project on a notepad and took it over to Unity once I was happy with it. My game does rely on a bit of scripting though, so if you can master the binding of PlayMakers FSM's to just a few scripts you have a lot of power at your disposal.

 

I watched the tutorials and like krur, I purchased it on sale "just because" it's so cool. I watched the tutorials and thought, "Gee, I really should take a serious look at that when I have some time." On top of that, I actually played one of the games featured on their Website and thought, "Really? Really! Wow! That's great!" So it's very capable.

I hand-jam all of my code. It's just the way I do things. Playmaker is essentially a state machine and if you've never programmed before, then it makes perfect sense because you don't know any better. I don't mean that in a negative way. It is what it is.

Watch some of the tutorials, start coding, and then you'll figure out if you need it or not.

Hope that helped.

 

Yup it's completely doable with Kismet in UDK, and it taught me some things, that I later transposed into scripts, but now, I'd rather code it in. Unity's code is tons simpler than UDKs Uscript.

 

Playmaker operates little differently than programming. I think every visual scripting plugins does. So, some things can really seem like - 'oh I can do this way faster in C#. This is slowing down my dev process.' When you are coming from a programming background, this can be your initial reaction.

Once you get over it, you can find Playmaker is really helpful in developing a game visually, like a flowchart. It's not really a flowchart, but gives you a workflow somewhere between a flowchart and programming. So, you can get developing more rapidly, as you don't have to design the architecture and then program. And this really helps. Also, coming from a programming background really helps in developing your own actions and extending Playmaker the way you want to. As you know programming has different levels and it's usage. Playmaker being at a very high level, it doesn't limits you in any way.

In my work, I have to do multiple tasks, design, draw, model, texture, rig, animate, do fx, render, composite and code. So, I don't have to look at the architecture every time and try to remember the maze of interconnections and function calls when I get back to code. One look at the PM flow and I back inside the project.

To me this matters a lot.

 

I like to use it to design AI behaviours.
Not THAT useful for general development.

 

FlyingRobot thank you so much you just sold me playmaker for your reasons as they are exactly what I would need it for I am a 12year c# and other language developer. But as an idie I have to take concept art to finished game including all the tasks you mentioned I would use it to speed up my production and not worry about complex logical head aches.thank you soooo much.and this is the only reason I would expect an experienced developer to get it like ourselves.

 

Ha ha! You're welcome!

 

Good merchandising! I'll buy it now!

 

Nope, I don't like visual programming. Too hard to read once it gets complex. I only recommend it if you wanna skimp on learning syntax and semantics.

 

I would like to have a node based visual programming environment, that actually mimics current unity's language the best way possible.

I've put this very quickly just now, but this is kind of what I would like:


It's basically the same functionality as our current coding language (in this case Unity Script)...

Right now, text coding is one dimension, you keep adding line after line. And scrolling gets long quick if you don't separate it into several scripts. You have to divide your code into several scripts for the sake of being organized, but often that also makes your code confusing, as scripts need to communicate each other.

It would be better to be able to layout our code so it's easier to find, like a map.

When using nodes, you gain the benefit of bi-dimentional coding. I'm convinced we could handle more code if we could layout it this way. But maybe it's just me!

 

I wrote a review at my website (actually an experience report) using Playmaker for Unity if you are used to program: http://playing4real.com/en/unity-plugin-review-playmaker/

My own, highly subjective two cents.
Hope it helps.

 

Thanks a lot! This was pretty interesting to read!

 

When I started using Unity I said I would never use a visual designer, but sometimes after spending months working on graphics and animation, when I come back to scripting I find it hard to get in the mindset and be productive. Theres a lot of huff and puff moments where I can't be bothered with scripting.

some days I just get so bored of it and then purchase a visual tool, then I start it up for about an hour and then feel I'm letting myself down and feel the need to focus on learning to code better. This week I decided that I would focus on playmaker and see really what it has to offer. I always thought playmaker would be just for prototyping, but I soon realized that it's really much better than that. Very powerful tool indeed !

I'm so impressed with "playmaker" and the tutorials are just fantastic. You will be up and running in no time. The team behind Playmaker are the most productive asset developers I've ever seen, they just keep on pumping more and more functionality.

You can create custom scripts and add them to Playmaker, so complex things that would be longer to create in playmaker you just need to code and add.

 

I've just started using Playmaker and I'm a pretty experienced programmer. I've found that it's useful for AI and other state-based things, especially when timing is involved. The nice thing is that it has the ability to call methods and set properties on a MonoBehavior, and the Playmaker component itself lets you trigger events and change variables in the FSM.
So basically, whenever I find myself thinking "this would be way easier in C#", I stop, do what I want to do in C#, then hook it back up to Playmaker so I get the benefits of a visual state editor.

 

I use playmaker for all the same exact reasons FlyingRobot mentioned. Im a solo dev and I want to be responsible for all the other areas of game dev, art, gameplay, models, animations, textures, etc. So people like us, love to save time and work more efficiently so we can put that time into other areas. Playmaker is an excellent tool especially for solo devs. With playmaker you can rapidly develop your game and in a very organized way. All programmers had this experience before where they code something, and then one day they go back to it and look at their code and say to themselves "what the heck did I code here". With playmaker, this will never happen again. Really easy to pick up where you left off and see what you where doing because its a visual representation of what you did instead of trying to understand your old code again.Its perfect for people who cant code and even better for people who can code. If you can code you can extend playmaker and make your own custom actions.

I am also a programmer and I know both uniscript and C# and have fully coded most of my previous projects. But ever since I started using PM I have saved so much time and have been able to focus on a lot of the other areas like art. definitely worth it, best asset ever purchased.

 

Hmm... I see where you're going, but I'm not seeing how adding an extra dimension would help. Wouldn't that make things harder to find, since you've got an extra axis to search on? Also, it's now potentially harder to search as you'd lack the highly refined tools available in text-based IDEs. Plus, if you visually represent what's connected to what you'll get "spaghetti code" in the most visually literal form possible short of throwing your dinner at your screen.

On that note, text based IDEs (and modern languages themselves) have pretty good tools to help you navigate your code. Code folding, go-to-definition, find references, info popups when you hover over things, code completion, etc. etc., all of that stuff helps.

 

Short answer no.
As soon as your behavior becomes more complex, you're in trouble. You'll end up with trillions of little boxes and gazillions arrows. :\

If you know how to write decent code then:
- If you work alone, no artists or designers, write everything in code.
- If you work with artists/designers and they want to take control over the game (events, behavior, whatever) then it's a good idea to abstract lot of code into higher states/behaviors and let them glue those chunk of code.

If you don't know how to write code then:
- Good luck creating your game.

 

Using a state machine when working alone can still sometimes be beneficial, especially with things related to AI.

 

I can't really agree with that. Code takes ages to change. The more benefit you can get from flexibility the more benefit you'll get from making things data driven with some nice tools, even if they're simple.

I haven't used Playmaker, so I can't say if this approach works there. But I often find myself prototyping things a few different ways and then, having learned the various ways in which I or my team will want to change things, write tools to get as much of the job done without writing further case-specific code.

 

I think you are missing something here.

You don't lay out PlayMaker's Nodes and connections and leave them just like that when you are making complex systems. PlayMaker's nodes are made with rapid prototyping in mind. Not optimizing and shrinking in mind. Just like you prototype any electronics with a breadboard and jumper wires. Although it will work like that, you must work on shrinkify it into a PCB after your idea is implemented and doesn't require major changes. The same technique works in PlayMaker too. Once your idea and system is working in the maze of node and you are happy...shrinkify it into one custom action, may be more than one if required. Here, you can do all optimizations thingy. And all your maze disappears into this action which is also faster than that maze of nodes. That's how you build up complex systems.

Another thing, the only way you can build games is by coding, either written or visual boxes. The logic works in exactly same way. There's no way around it. You don't remember sytanxes in PlayMaker, but you will have to remember and learn how to use the actions, which are the counterpart of syntaxes. It's the same. If anybody is looking for a way for making games without programming, PlayMaker is certainly not the answer.

It secretly teaches you programming even if you are trying to avoid

 

You can also write your state machine code if you work alone.

 

You can still write datadriven code, you can still write a state machine code, no need a visual tool to glue your own code. Sure for prototyping small behaviours, yeah why not, a visual thingy could be useful but that's not how real games are done.

 

Sure, that's an option, it's the same idea really. Although there is the downside that you'll have to migrate later if your project happens to get bigger.

 

Oh? Ever heard of Kismet?

But also, who said anything about visual stuff? I'm still talking about purpose built code created around research based requirements, it's just flexible code driven by easily configurable data wit tools to suit. There's nothing wrong and plenty right with developing functionality around flexibility that doesn't require further code effort. Even if you're a programmer, how long does it take to tweak code as compared to tweaking configuration properties in real-time while you're playing with the thing you're tweaking?

And plenty of "real games" are done that way. I remember the CEO of a large studio describing how impressed people were when his studio initially started doing things that way. Other developers would have multiple-day turnarounds between designers and coders, submitting change requests to tweak simple things, waiting for the build the next day to try it out, and issuing a new change request... taking days to get one bit right. These guys made tool-driven stuff that could be changed in real-time, and their designers could tweak things in minutes instead of days and then submit their own change.

 

@angrypenguin,
That's fine, exept that we are talking about one man dev not a studio or multiple developers.
Let me re-quote my initial answer again:

Just to point out that you are just saying what I've initially said to the threads author. ^^

 

So what?

I can quote myself too:

Faster iteration is faster iteration. And, if you ask me, smaller teams are where increased efficiency are most needed, because they've got the least time to waste.

 

Tweaking configuration properties won't make you any functional application, that's just... tweaking configuration properties.
But I fail to see your point, why are you arguing?

 

This is more of a debate about visual scripting vs code scripting... and I think that visual scripting has huge advantages if properly integrated.

We're a small team here. The project has a lot of content and artists are hands-on into gameplay creation. In my situation, coding everything will take valuable time and resources.

So, a year ago, I decided to switch a lot of my 'core' to work with a visual scripting solution. I needed something that wasn't necessarily a FSM but could become one if required. I needed something that artists can use without feeling lost but I could use too if I have exceptions to manage (which in development is .. OFTEN).

That's why I decided to use uScript http://www.uscript.net/home/. Compared to Playmaker, it can create more convoluted code... BUT it also has a much greater flexibility for programmers. With some custom nodes, a few additions such as a GUID system for all GOs, my gameplay development productivity has basically ten-folded (I kid not) and I no longer require a programmer to code it.

Another plus is the QA. When artists integrate and create the gameplay with the assets they themselves integrated, you suddenly notice a much lower overhead and an increase in project ownership.

With that experience, I'm seriously considering using visual scripting for every project. There is always a part of a project that would just be easier to develop with flows and nodes and ins/outs. Always. Even individual projects.

 

I used Playmaker up until the point where it didn't make sense for one of my projects and pretty much came to same conclusion as tato. For a team environment I can completely see the benefit, there it makes sense to spend the extra time having your coders write custom actions so other team members can make use of them.

For solo, I just don't see the benefit at this point since it is not as if Playmaker saves you writing code(anything beyond hello world stuff you're going to be writing lots of custom actions, ie. code), it just causes you to write extra code and the nodemap is sort of an extra layer of documentation.

 

Exactly.

 

I guess my point is that it's not as black white as you Tato (salut!) and Tiggus say.

About Playmaker and solo development, I mostly agree. But people use Playmaker as a placeholder word for Visual Scripting on unity forums and I think that's unfair. There are other visual scripting solutions that are more suited for programmers where even on Solo projects they will compartmentalize some gameplay elements much more efficiently than hand-coded.

It's all about integration and scope.

 

I'm pretty much a solo outfit and i got this randomly ages ago, never really did much with it but i cant see why people are so black and white abot this approaches uses. It looks great for systems that will by their nature, be mostly closed, so they can go off and do their thing, im very attracted to the idea of well functioning 'black boxes' that are easy to comprehend when looking inside, visually. On the other hand i wouldnt use this to create the frame these things work within or things that rely on a lot of flexibility/extendibility. So like a lot of very handy tools you can get for unity, seems a good one to have in the bag, along with the rest of your kit

 

It is great to fiddle around with, no doubt. The question is for someone who is comfortable coding their own C# FSM is it worth the extra hassle just for the visual tree representation. Keeping in mind it will make doing certain things less flexible than your own code based FSM.

The visual tool I am most intrigued by right now is AngryAnt's Behave 2, for complicated AI behavior, looks really slick.

 

Can you assemble an automatic transmission with no instructions or power tools? Some people can, and if you can, then you know you don't want to and anything that would make it easier would be welcome. We all know that many people using Unity are using it because of the workflow benefits and ease of access. Could CE/UDK make a better result? Probably. Do you want to use them instead? Probably not. Does it even really matter what you use? Not really. What is Unity/UDK/CE if not basically an elaborate, visual front end to a more complex low level engine that you could just code your game directly into?

Using Playmaker or visual scripting tools does not mean you suddenly cannot use scripts, or that your performance is going to sink if you use it. What it does mean is that you're going to be able to see what you're doing, prototype quickly with a generic set of functions/actions and return to old work to immediately see what is happening without having to do much more than read the state titles in a few seconds.

If you don't prefer to use it then there isn't anything wrong with that, but its silly to suggest that there are not benefits to using it and put it off as an amateur fallback tool. There are plenty of people and companies that have experience to the contrary.

 

I don't think it is silly to suggest anything when it is a thread asking for opinions by someone who "knows C# inside and out". It's a thread asking for opinions, yet if you say anything remotely critical of a tool like Playmaker people seem to come pouring out of the woodwork upset that you have audacity to suggest it is not the most efficient way to work for someone who is a self professed C# expert. *shrug*

 

I definitely didn't say that.

 

I don't see anyone criticizing non-Visual Scripting solutions.

The common ground appears to be that it's useful... but different visual scripting solutions are good for different logic requirements and that to really exploit its benefits, integration is key.

So yeah, the only other thing I think we can agree on is that its a complex subject and general comments that its "good" or "bad" are pointless IMHO.

 

Sure, I respect where you are coming from. Unlike some who are commenting here I wrote a couple hundred custom Playmaker actions for a project I was working on so I know how useful it can be when you take the time to plug it in properly and I also know how it can be cumbersome at times. I haven't used uScript which is why I can only comment on Playmaker which is what the OP is about.

You can go download a free fully working code based FSM off UnityGems for free and have it up and running in about 10 minutes if you are familiar with C#. That probably shouldn't feel like building an automatic transmission to most people who are C# experts.

 

There might also be some confusion about the extend of how much you should rely on a visual scripting solution.

I would _strongly_ advise against using visual scripting "exclusively" for any project other than prototypes. Just no...

Custom nodes can only go so far before it becomes huge mega "Do it all" blocks or hundreds of "Just do that little thing right" puzzle pieces. Argh...

 

Clearly we see "configuration properties" as very different things. I don't mean properties as in variables, I mean the properties of the data used to determine how something behaves, ie: the data used to drive data-driven stuff.

For instance, my current personal project has a locomotion system based on a state machine, and the whole state machine can be reconfigured at runtime, while I'm testing the gameplay, by clicking on things in an editor. I'm a coder, so I could definitely make the same changes by stopping my game, jumping over to Visual Studio, changing code... but it's way faster to represent the same things in data and point/click/drag to make changes without stopping.

As far as I understand, Playmaker is the same general kind of system applied to other parts of game development, and I can certainly see the value in it, and it doesn't make something any more or less of a "real game".

As for why I'm "arguing"... well, isn't discussing stuff what people do on a forum?

 

The topic of this thread has a lot to do with softcoding.

Softcoding is good. But too much softcoding is bad.

 

Yes, I think there was a discussion about that a few weeks ago, albeit under a different name. Making a tool that was so complex that it ended up requiring just as much skill and time to use as doing the same thing in code.

I think the key to good tools is what gets left out as much as what is included. Actually, that wiki article covers exactly that:

When you add a feature to a tool or a configuration option, weigh up the value of the benefits against the cost of the additional feature, both to the tool developer (implementation and maintenance time) and the user (how much harder or slower does it make the tool as a whole to use?).

A key to that, in my experience, is having a clearly defined scope you can compare things against.

 

I've been testing Playmaker before you and anyone here, I was the very first one that tried it when no one here knew about it. I know how it works inside out.
Sure, you can test and change stuff visually with PlayMaker at runtime. But there's an upfront cost you din't mention. All those custom actions must be coded (in an specific way) plus the execution overhead (plus learning how to create custom actions).
Unity serializable properties/classes provides you a way of debugging visually in real time through the inspector. For Instance, I can change my FSM states at runtime, change (and see) values properties. If you code actions and they require to be tweaked/changed, there's no way you can do it visually, you must go back to VS, change you actions code and go back to Unity. Unless you are doing everything visually (which is not really recommended) I don't see a way of skipping coding. Visual Scripting it's always a tradeoff.
I have no problem with your way of working things out, if you are confortable with that's fine but my point is that I don't think it's necessary for a one man team to do visual scripting (unless he don't know how to write code) or to the rare exeption of prototyping some complex behaviour.
Back to my initial answer, what I did suggested was that visual scripting (in this case Playmaker) could become handy if you got a team of designers/artist willing to take control over your application behaviour. In that case, you (the programmer) can create custom low-level actions and your guys will glue them out visually.
Finally, nothing will stop you from creating applications with visual coding but will that code be clean, readable, will it remain maintainable, will it run fast, will it be portable?

 

Haha, you're being very condescending there for no reason in particuar. You appear not to have picked up that I was not talking about Playmaker in particular, and went so far as to say that I hadn't even used it myself. In fact, my initial response was quite specifically to your suggestion that one-man teams should just "write everything in code", pointing out that there's often great gains to be made by taking other approaches.

Yes, there's an up-front cost of creating (or learning, in the case of a COTS solution) the tool at hand. I didn't think it needed explicit mentioning as I did mention creating the tools, and I figured it'd be clear that doing so requires some time investment.

You keep saying that it isn't "necessary". Since I've successfully delivered many a project without such an approach, I have to agree. It's not "necessary". My point was never that it's "necessary". It's that it can be, and in my experience often is, far more efficient.

You also keep saying "visual coding", which also isn't really what I'm talking about.

Absolutely. In fact, it's typically far better than when I too used the "just do everything in code" approach, in all of the ways you've mentioned, plus a few extras (reusability, flexibility, scalability within a business). I could go on at length, based on real world experience from successful professional projects, about the pros and cons of each approach, but I think a new thread would be best for that.

 

Ahahaha I remember that... I ended up doing the same (though I opened it only once).

With this I don't mean that PM is not good. Actually, it's supercool. But knowing how to code, I find much quicker to just write stuff down. Still, even if you're a coder, it might be useful if you want to do a really quick prototype.

 

I use a "hybrid" approach when using PlayMaker.

If an action is going to be used in many places, I'll make a custom action for it (one that inherits from HutongGames.PlayMaker.FsmStateAction)

But if the action is going to be used in just one place, such as for just one class, I'll just put Enter/Exit/Update methods in my Monobehavior. Then I have a Playmaker action to link in those methods when needed. In this way, I don't have to make a separate class file for something that will never be reused, which is a rather tedious process. So you get to define things mostly in code, but you get a nice little visual editor too.

 

You are repeating yourself over and over but you ain't proving anything.
I've been very clear in my previous messages but thanks to put it in a different way, save me lot of time.