Playmaker or advanced CSharp messenger patterns

[tzamora]

Hi people, I dont know if this is the place where I can ask this but, Why isnt everybody using playmaker?

I mean, I have been working playmaker only for this whole week, and watching videos and learning the patterns associated to FSM and other patterns when using playmaker and other whistles about it and I need to know why.

When I started using unity I wanted to use a simple but consistent framework which allowed me to mantain patterns when programming. Programming a game is different but there is marked patterns (taking a item would be the same in a game like mario or like crysis) that I would like to always do in the same way.

Searching for an answer to this I found http://wiki.unity3d.com/index.php?title=Advanced_CSharp_Messenger

The advanced CSharp messenger helped me a lot. I come from a as3 background before and I used robotlegs that is an MVC framework that I liked a lot.

When comparing the unity’s GameObjects communication between other Game objects and components I instantly thought in robotlegs and then began my search for this kind of patterns.

The Advanced CSharp messenger allowed me to decouple the gameObject dependencies with other gameObjects and the game classes took a new whole structure that I have never though would gain.

So, the GameObjects and Managers would communicate between them in a way I could not be more happy. But then I knew about playmaker.

I know that the FSMachines where something that were used a lot in games, but I never thought it would be so easy with playmaker, the way he created the logic associated to one gameObject and the way it encapuslates FSM for actions in the game seem good. I’m still with a lot questions but it seems that using playmaker at long term could help in the developing process.

Usually the people says: “Use what you like more” … no no no, there are millions of developers out there, programming games everyday, there must exist a pattern that helps … a pattern that allows me to get the best way to organize my gameObjects and Components, be it a simple messenger system like advanced CSharp messenger or a FSM framework based like playmaker or other patterns.

If all the whistles of playmaker are true, I would like to know if somebody could confirm this or share another pattern that maybe could be better than this.

Thanks

[zombience]

Well, I’d fall into the “Use what works for you” camp. When I started Unity, I didn’t have a lot of experience coding, and so I began working with PlayMaker because it was what my boss had experience using.

I come from a background of using MaxMSP (which is a visual programming environment, like Quartz Composer, where you can drag boxes of “functions” around and connect them with lines to indicate program flow), so I thought that PlayMaker would be an easy step. I found it to be very cumbersome, hard to duplicate many behaviors with minor changes between them, and just entirely too much clicking for the reward. That was my impression.

So, I got into coding for C# (I also had a little bit of AS3 experience, though only a few months), and I found it to be far more flexible, repeatable, modifiable, and just so much faster to work in. I have written my own FSM classes in C# and used them to great success. In fact, writing code in C#, I have the whole book of Object Oriented Patterns to work with and to code by. I’m not sure how I’d make a factory pattern work in Playmaker. It might be possible, but I’d have to figure it out. In code, it’s directly applicable from reading examples about design patterns. In Playmaker, I’d have to “translate” how to make patterns into it’s design.

The main reason I prefer C# over Playmaker is that if, in the future, I move on to a different career path, C# is a translatable skill to other environments such as application programming or web coding. If you learn C# in Unity, you are learning .NET, which is widely used. Playmaker has no use outside of Unity. That, for me, is the biggest selling point for C# over playmaker (and, incidentally, over “javascript” in unity).

That’s my preference, and it works well for me. If you like playmaker and are getting good work done, by all means, stick with it. At the end of the day it really does boil down to what works and what you like.

[DiskobolosCZ]

Hello,
I have a corporate Java programmer background and new to game development, but I think I can help.
I love playmaker for its simplicity and ease of use, BUT I am just like you trying hard to use it more conceptually. I planned to start some kind of playmaker design patterns book or initiative because that’s what is playmaker seriously missing to be great.

However, even if such resource would exist, I rejected the idea of playmaker being the main tool for game logic development for now. That’s because it lacks the tried and true patterns approach you are mentioning and any complex use of FSMs is a puzzle for me.

A win for me would be to use playmaker in these cases:

1. simple cases where logic in a single FSM would suffice, i.e. level scripted elements - doors, cutscenes, etc.
2. prototyping for quick ideas tryout
3. just as a FSM logic for states in more complex scenarios (where states are needed and coding them in C# would be unproductive) and the rest of the logic in C# scripts.

The third step is what I am currently evaluating - how to connect the FSM world with the scripting world in a conceptual and manageable way. This is not an easy step as it may seem and IMHO needs some thought. But I’d like to make it happen because I don’t want to leave the playmaker’s FSM goodies just like that.

Well, like I said, I am new to game dev, so there may be some other valuable resources already available and if so, please post references here.

As for the messaging framework - I read a lot about it being performance heavy and it is not recommended for larger use. They suggest using the C# event features (publish-subscribe design pattern).
The messaging in unity uses reflection + classes inspections and thus has a performance penalty.

[ScottPeal]

I am a senior C# developer and architect. Having played with PlayMaker for a week now, I love it! Not for the ability to write code, but the ability to visually see my logic flows and debug the flows. To sit in front of a project with team members to discuss the flows.

Of course this is for rapid prototyping, so if we see a performance issue, we will gladly convert our code to C#. At least at that point we have the logic determined and it should just be a transcription effort.

[WizardGameDev]

As an experienced developer myself I think Playmaker is an extremely valuable tool for prototyping. I’ve also found it quite easy to extend with C# actions if I need more complexity. Sure I can build my own state machines in C# and I have many times.

One person pointed out a massive benefit. When you are working with teams where you don’t people that really understand C#, playmaker provides a working interface for the team that people can get their heads around. It is far easier to sit down with a group of four or five people and conceptually wire together the basic structures for your game design. The states often just serve as stubs and place holders where you know certainly C# specific scripts are required to encapsulate complexity… but that can often wait until later.

More so than sub-classing and reusability what I miss most over C# and ‘rolling my own’ is how I work with collections of objects. Ironically it has probably helped me design better and encapsulate better where is I would have had gone to my handy collections skills classes end up having more dependencies that less. I believe now prototyping in Playmaker makes a ton of sense because it’s limitations are what force me to reconsider many approaches that would end up being equally poor in C#… but with C# I always have a way out and can do so much by brute force.

Another conviction though is that for good design you need to know when to go to C# actions and stop trying to add complexity to state machines in Playmaker. I think Playmaker is not a total solution but in very narrow game designs. I think for board games, puzzle games, light weight RPG’s… I’m not sure you would need to abandon Playmaker as a core state machine engine. For that purpose it could actually work combined with calling out to C#. Likely for FPS or RTS with lots of objects and lots of complexity you will want to strip out playmaker except for some ancillary routines.