Hi,
Interesting
tltr? check out this video from Nate Gallardo about what you are trying to achieve with your team ( core dev and artists)
it's very important to see what other solutions are out there, and we are totally fine with that of course, PlayMaker is a tool with a vision, and that vision may not be your vision, we are ok with that
but if PlayMaker is the #1 visual solution for so many years, it's because Alex Chouls ( the developer behind PlayMaker) saw something that we didn't, and many have tried to create visual solutions and none so far are able to reach and hold up to PlayMaker.
My experience with PlayMaker which spans for more than 8 years now involve some huge projects, and I have a different outcome, I do think that PlayMaker has what it takes to handle large projects, but it is a paradigm shift in the way you approach it, and I think the problem you are facing is because of that paradigm shift not being complete.
What do you mean "enforced" Object oriented rules? If a developer is given a set of rules and doesn't follow them, it's not the tools' fault, what ever the tool. If I say don't use statics and singletons, and one dev creates a feature using that, I don't think c# or Unity is to blame, right?
PlayMaker is not object oriented, nor it Unity, so enforcing Object oriented approach has to make sense within this context. I love OOP in theory, but the downside is that true OOP is just like Java, and the main issue with this, is that once you decide on the structure, you can't change it, which is why so many project are doomed when they reach this critical time in the developement process where the client says "Let's do this instead..." which totally mess up your OOP structure and you are unable to deliver in time nor it becomes a clean project anymore. So OOP: yes, but loose and it's ok for it to be loose in my opinion
My very first big project with Unity years ago was to create a simulator for a Robot on a oil rig, which replace manual operations that are highly hazardous, the project spans over more than two years and is used to train employees before working on site so it has to be 100% realistic and true to the real thing, I also picked Playmaker, it just came out of beta) because of its Finite state machine, the client would give me a diagram of operations as they developed the robot itself, involves some very complex and ever changing rules, which if I had to do in c#, I would have certainly fail at it. With Playmaker, I was faster then the actual engineer in implementing new rules!! that is when the client was giving us instructions about how the robot should behave, the engineer that was suppose to code the robot ( no change in variables nor physical context, pure behaviour change), I was way faster! Every one was shocked. Even today if I had to start again, I would still pick PlayMaker, because c# doesn't offer any built in solution to create such a flexible system, and it would mean having to recreate an FSM or something similar to get there anyway.
My most successful approach so far when I have to create complex beasts with Playmaker is more an MVC approach actually, because of the way Playmaker can communicate so easily between each Fsms, without any boiler plates and event registrations, etc etc. So Maybe leaning towards a loose MVC ( Again because Unity and Playmaker are not fully MVC compliant context) will get you farther down the road than an OOP approach.
So, I differ from your conclusion that Playmaker is just for novice, Playmaker brings far more on the table then a quick learning entry level scripting solution, it offers a true production ready, performent, and battle tested Finite State Machine. I always say that Playmaker should not even advertise that it is visual, because it undermine what Playmaker is really about, it's a different approach.
- No more difference between synchrone and asynchrone operations! This is huge.
- No more boiler plates for event listening, this is also huge, but dangerous, I give you that
- No more compilation when making changes. Everytime I have to work with components or need to create a new custom actions, It hits me that I really got used to not having to wait for Unity to recompile to press play! this is massive in terms of production gain. I demonstrated that at Unite in texas few years ago, someone challenged me to write a quick logic, thinking playmaker would fail, what happen is, that by the time he was starting coding in visual studio, I was already playing. That was a a shock for that developer. This becomes more and more noticeable as your project grows as well.
- Total transparency at runtime, I can see where are all my fsm and what they are doing, Debugging is part of the development from scratch. The gains in production speed are also very noticeable, I curse everytime I have to debug a complex set of classes, which clearly is not as convenient to do than with PlayMaker.
I stop here
but I'd be interested in learning more about what where your flaws, we can certainly learn from your experience and see if we can improve the workflow or maybe do some samples where we show how Playmaker can be integrated in a mixed team of core developers and artists.
Bye,
Jean