Possible to fix major weakness in Playmaker delegate event handling?

[DuaneDog]

Greetings,

I've had another post about this but I've learned a lot since then and want to ask Playmaker / C# experts if there is a possible solution to a weakness in handling delegates.

You only need to look at the NGUI / Playmaker integration to see the problem. Playmaker is unable to subscribe to the event delegates in NGui directly. Therefore there is an entire layer of other scripts required. I want desperately to make it so you could have an action in Playmaker that would allow you to directly subscribe to those delegate events in Ngui.

So for a simple example in a real world case, here is an example in C# of creating a delegate for one event in C#:

Code: [Select]

public class TGCConnectionController : MonoBehaviour {

public delegate void UpdateIntValueDelegate(int value);

public event UpdateIntValueDelegate UpdateMeditationEvent;

...etc
Now the code as it would be in C# to use this delegate.

Code: [Select]

controller = GameObject.Find("GameObjectHoldingTheDelegate").GetComponent<TGCConnectionController>();

controller.UpdateMeditationEvent += OnUpdateMeditation;

The goal here is to create an action equivalent of the code directly above that is generic and can be reused.

I picture an action that has the following properties:

GameObject : GameObject that holds the C# script (GameObjectHoldingTheDelegate)
Component : The actual C# component (TGCConnectionController)
Event : The event that we wish to subscribe to (UpdateMeditationEvent)
EventToCall: The event to call in the FSM (OnUpdateMeditation)


Now if it were easy to create this 'generic' action... I suspect it would have already been done. It maybe impossible, or yet it would have already been done. Certainly the parameters are the first challenge. In the example above the event pushes along an int (integer). I'm assuming that this is where things start to break down, making it impossible to really 'do this' in Playmaker.

Without this capability however, using Playmaker for professional game development becomes very challenging and poor, tightly coupled and brittle designs are virtually inevitable. For example, changes in NGui's delegates are going to require modifications in that middle layer and then perhaps could affect countless state machines that are consuming it. It borders on straight up bad design patterns.

As I said in my earlier email...I may be missing something simple. You only have to look however at the NGui / Playmaker integration scripts to see just how much code is required to tie these two  systems together.

I think part of the issue is that veteran developers often don't use Playmaker all that much because they find it limiting from the beginning. Even using Playmaker myself it wasn't until I started real professional game development work that this functionality was just not there. I had figured it was something I needed to learn how to do. Once I learned how it is done, (ie how Ngui and Playmaker tie together) I can't help but feel it is a deal breaker for using Playmaker for more than just hobby projects and perhaps some proof of concepts. 

I'm hoping that I can get someone from Playmaker's team to give me some insight on this issue and if there are long term plans to address it. I would think even it is impossible for Playmaker to do this alone, perhaps Unity can provide an interface in a future build that would make it possible. With Playmaker's popularity I think it is important to help developers create solutions that follow good design patterns. I've looked through every last scrap of code in playmakers/nugi script library and it is scary just how much work is required. So much so they even have you pay for the library! 

Another example is the Photon integration. It uses similar strategies to tie Playmaker to their events. As more products are built and wish to support Playmaker, this issue becomes quite important.

Can anything be done?

[jeanfabre]

Hi,

 Sorry, I replied to your other post before seeing this


Typically, I am using PlayMaker for very advanced serious games, and this is not really the problem actually. the problems lies elsewhere, in how PlayMaker supports variables. Indeed you mention this as well, such "delegate to PlayMaker event" action would be unusable in 90% of the cases simply because of variables.

 Your pseudo code will end up as a bridge essentially and not a generic one since you must explicitly bind a strongly typed class with playmaker. In that sense this isn't going to remove the need to write a bridge to begin with. Isn't it?

There is nothing wrong with bridges here ( I feel )

where would your "controller.UpdateMeditationEvent += OnUpdateMeditation;" be? on another monobehaviour right?

 typically, this is exactly what I am doing to support Input.touches framework which is heavily based on delegates.

https://hutonggames.fogbugz.com/default.asp?W961

if you get that package, you'll see how this is all done.

-- I have a prefab acting as a "singleton", so one per scene, totally isolated
-- It registers to each and every Input.touches delegates
     

Code: [Select]

Gesture.onSwipeE += OnSwipe;-- "OnSwipe" is the following

Code: [Select]

void OnSwipe(SwipeInfo sw)
{
if (debug)
{
Debug.Log(sw.angle);
}
LastEventPosition = sw.endPoint;

LastSwipeInfo = sw;

PlayMakerFSM.BroadcastEvent("INPUT TOUCHES / SWIPE");

IF you want to target a specific gameobject or FSM to send a local event, it's possible too using my PlayMakerUtils:
http://hutonggames.com/playmakerforum/index.php?topic=3438.msg15764#msg15764

in there you will have code like this:

Code: [Select]

public static void SendEventToGameObject(PlayMakerFSM fromFsm,GameObject target,string fsmEvent,FsmEventData eventData)
{
if (eventData!=null)
{
HutongGames.PlayMaker.Fsm.EventData = eventData;
}

FsmEventTarget _eventTarget = new FsmEventTarget();
_eventTarget.excludeSelf = false;
FsmOwnerDefault owner = new FsmOwnerDefault();
owner.OwnerOption = OwnerDefaultOption.SpecifyGameObject;
owner.GameObject = new FsmGameObject();
owner.GameObject.Value = target;
_eventTarget.gameObject = owner;
_eventTarget.target = FsmEventTarget.EventTarget.GameObject;

_eventTarget.sendToChildren = false;

fromFsm.Fsm.Event(_eventTarget,fsmEvent);
}
Yes, you will need give a reference of an Fsm to fire non global events, but that's easily solved by having an empty ( totally empty, no variables, no logics, no actions, just an empty start state), in your singleton prefab. but that's not really a limitation to provide all these features.

So currently, I think that what you are asking is available. The PlayMakerUtils class may be your missing link I guess.


Am I correctly understanding your situation? what would you want to do differently in this case?

 In the case of Photon, the problem is different, Photon framework doesn't provide any delegate, it only sends Unity messages. But that doesn't really make a difference here cause still, Photon and Playmaker will need bridges to communicate together, so I had to create the photon bridge this way. Very much like if you want your character to work with photon, you will have to create specific monobehavior and comply with how photon is working and the way to communicate. Typically, taking PlayMaker out of the equation, you would still need to create bridges between say photon/ngui/GameAnalytics trio. isnt'it? None of these frameworks know about each other, so the only way to make them work together is to create specific codes and act as the middle man ( binding a photon connection message to a gameanalytic event and translate this visually as a text you show on screen using ngui).

Maybe I got carried away this morning but this is an interesting conversation indeed! so feel free to correct me on my assumptions as for sure, since I am writing a lot of bridges, finding other possibilities is of high interest for me.

bye,

 Jean

[DuaneDog]

It is really great to get such a well thought out reply. I'm still very dedicated to working with Playmaker but I must admit it is going to be more so I can provide tools to others to build games. After diving back into pure C# development and setting Playmaker for aside a bit I realized that my best path is so focus on rock solid design patterns first and make sure I can execute them cleanly.

So I think I can best serve the Playmaker community coming first from solid C# solutions for game design, then determining how they can best map to Playmaker. Even just yesterday working on a spell system I had quite a bit of code written when I realized a far better design pattern for that solution. Then as I was implementing that I saw other opportunities to improve the design.

If I were on some sort of R&D team I would certainly be looking at things like "Heads First Design Patterns" and then begin studying how to map those concepts into playmaker. A huge scope increase obviously but the exercise may reveal possibilities that were previously not considered.

In the upcoming weeks I have some ideas on how I may create some design frameworks that would integrate with Playmaker.

[jeanfabre]

Hi,

 I think both approach are good as long as you have a logical mind. Knowing c# helps you with PlayMaker to solve some problems, but really, the way you approach Fsm design is very different then put c# scripting. However, it's always better to know c# to provide support for people getting lost on how to work with Playmaker, that's for sure, otherwise it can go in very odd directions, and miss some important points on performances.

The same is true with Unity itself, PlayMaker is something on top of Unity, Unity should/must be mastered somehow before taking PlayMaker to its full potential.


bye,

 Jean