- OOP (Object Oriented Programming). Encapsulation and Properties are great, inheritance and polymorphism suck - for designers trying to read code at least. Having to read cold lines of text is already sufficient to pull a designer's mind away from the code, now having to keep multiples text files open and hopping back-and-forth among them just to understand exactly what a piece of code is supposed to do is something that, even as someone with a degree in the area and used to OOP underlying concepts, I personally despise. If you're used to notepad or notepad++, forget it, things become extremely hard to understand and usage is very susceptible to a plethora of bugs as you struggle with function names and definitions which are "somewhere else". To properly code with OOP you're pretty much *forced* to use Visual Studio and preferably Resharper just to understand what's going on, and as much as coders tout it I still find those solutions awkward and ineffective to fully grasp the power of object orientation. I find I can fragment (factor) code chunks much more while visualizing it much better using Playmaker than with pure Visual Studio + Resharper (and/or Visual Assist X).
- Visual Coding (Kismet, Antares, uScript). First and foremost, let's get something straight: if you don't know how to create a flowchart to describe game logic you're not a real designer, you're like a writer with good ideas that don't necessarily need to be feasible. So, supposing you are a designer, what's left to do? From a designer/developer PoV, I want to be able to "transcribe" my game logic flowchart to the computer, setting up commands and parameters with drop down menus to get the right fields, instead of typing a name and doubtfully hoping it's the right property or variable. VS/Resharper already gives you that possibility, so all that's left is to know what's the correct syntax to get loops and routines working as we want. Visual Assist does have code snippets that help a lot with this. So, supposing you have the right tools and don't try using the harder OOP concepts, you can describe your logic inside Unity quite easily. That's why some people make fun of Visual Coding claiming "it's already too easy to code in Unity". What they don't realize is how easier it is to create and visualize high-level and complex logics with a visual tool, due to their frequently non-linear and parallel nature.
That said, whenever I see some "real production" example of Visual Coding only one thing comes to my mind: Graph Maze. I've yet to be proved wrong (and that's not even possible since it's completely subjective) that coding something in Visual Studio + RS/VAX isn't easier than assembling the same logic in Antares Universe. Existing Visual Coding tools don't "scale up" well, when that should be specifically their number one advantage, helping the dev have a higher level control of what's happening and when. Too many games nowadays work okay during Prototype stage and fail to become real games simply because they've been built "from the leaves to the trunk". Developers focus too hard on getting the core mechanic(s) of the gameplay prototyped and fail very hard to integrate it smoothly into a higher level control of the gameflow. When that happens iterative development becomes prohibitive since you haven't planned for scale and modification. It's like trying to define a basketball game starting from the weight and size of the ball, instead of from the size of the field and number of players. You might eventually make it, but it's completely upside-down. In that critical aspect the current visual coding tools approach doesn't help at all, since it's mostly focused on small-scale behavior which is more adequate for traditional, linear coding.
- Visual Scripting (Visual FSM). Finally, there's the concept inherited from process engineering, of Visual composition of Finite State Machines. That's what playmaker uses, and it's definitely a game changer for game developers for the way it makes them think on a higher level and practically "teaches" them to compartmentalize their logic - low level logic blocks in linear text code fashion (actions) and high level logic in non-linear visual blocks (states). The way Playmaker encapsulates and present those actions in each state is ingenious, the more you work with it the more you feel like that's how an OOP editor should work. Nevertheless, it's a paradigm shift, takes some time to grasp, yet the more developers get used to that new way the more they'll realize how superior it is to the "old way". That's not to say that specific tool it's devoid of flaws though, it still lacks some nested/subFSM entity to better encapsulate tiny dependent states and clean up the view of larger FSMs, it lacks some more intra-state algorithm-ish actions (which, although demoted by the author for breaking the concept of FSMs, can be quite handy when used wisely) and better visualization tools. For instance, there's no way to open two FSMs side by side right now, so for any larger design you'll definitely want to use some pencil-and-paper or visio-like tool before implementing anything in PlayMaker. There could be more helpers like event/transition shortcuts (although it has 'global events' which can be used for that) and the ability to selectively turn some transition lines to circuit and others to bezier - currently there's only a global setting for that.
I'm not afilliated with Hutong games in any fashion by the way, but in my opinion if you can only afford one visual logic plugin for Unity, Playmaker is the right option for any serious Unity developer. If you want/need sidekick products to help it as action-generators, great, but really consider checking Playmaker's built-in action code samples, how clean and readable they are - 'look ma, no polymofo-whatever'! Trying your hand at a bit of copy+paste coding shouldn't hurt, not to mention the public actions library is only going to increase as time goes on.
Now, not saying I'd expect that to actually happen, since I know how hard it is, but if uScript has a function to convert its logic graph to standard C# code ready to be used as an action.. I will fricken buy this thing
0 comments:
Post a Comment