Unity3D is a powerful suite of tools (Project IDE, Code IDE, run-time) for game development. In Unity3D Game Architectures I present six different techniques for setting up your game. Depending on the size and maturity of your team, you are probably doing some form of those. I recommend checking that article out first, then read below. In Unity3D MVCS Architectures: StrangeIoC (recommended reading before continuing) we dove deep into the great, free framework. I also explored an idea I had for an extension called PropertyChangeSignal. Here is more;

PropertyChangeSignal

To aid my work with StrangeIoC, I created a few classes that function together to reduce the workload. I call this the PropertyChangeSignal. Again we saw above that signals are used for many things. Speaking from a model’s perspective for every property (variable) you want to update in your model you may need SEVERAL signals. That is fine in my demo above with exactly one property, but imagine a ScoreModel with 5 variables, a TimerModel with 3, and a GameLogicModel with 25 more variables. You can quickly grow a HUGE list of signals. Now, creating a signal is super quick. It takes 30 seconds to create, and another 30 seconds to optionally bind it to a Command. Its certainly possible to grow your app in this conventional way (or some variety of this conventional way). Most people do exactly that. But I wanted a start a discussion on a different way.

Here is an example.

Let’s say we have a public message string in your data model and the whole app needs to interact with it.

A. Conventional Signals Per Property (4)

• 1. requestMessageSignal.Dispatch() – If a mediator arrives on the scene late and wants to KNOW the current value of message.
• 2. clearMessageSignal.Dispatch(targetValue) – If a command wants to CLEAR the current value of message.
• 3. updateMessageSignal.Dispatch(targetValue) – If a command wants to SET current value of message.
• 4. updatedMessageSignal.Dispatch(newValue) – After any updates happen, the model sends this out to those listening who can GET the value.

B. PropertyChangeSignals Per Property (1)

• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.REQUEST) )
• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.CLEAR) )
• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.UPDATE, newValue) )
• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.UPDATED, currentValue) )

So in B, we see far less signals used (1 vs 4), but an longer syntax for the call. Soon I’ll request your feedback based on the source-code.

Update:  Download the full source below.

Syntax Example

1. CONTEXT – SETUP BINDING

commandBinder.Bind<GameListPropertyChangeSignal>().To<GameListPropertyChangeCommmand>();

2. COMMAND – HANDLE BINDING

public override void Execute()
{
	switch (propertyChangeSignalVO.propertyChangeType) {
	case PropertyChangeType.CLEAR:
		//ASK TO CLEAR THE MODEL
		iCustomModel.doClearGameList(); 
		break;
	case PropertyChangeType.UPDATE:
		//ASK TO UPDATE A VALUE IN THE MODEL
		iCustomModel.gameList = propertyChangeSignalVO.value as List<string>;
		break;
	case PropertyChangeType.UPDATED:
		//FOR THIS PROJECT, THE VIEW LISTENS DIRECTLY TO 'UPDATED'
		//OPTIONALLY, WE COULD ALSO DO SOMETHING HERE IF NEEDED
		break;
	case PropertyChangeType.REQUEST:
		//FORCE THE MODEL TO RE-SEND 'UPDATED' (WITH NO CHANGE)
		//THIS IS VERY COMMON IN APPS (E.G. A TEMPORARY A DIALOG PROMPT)
		iCustomModel.doRefreshGameList();
		break;
	default:
		#pragma warning disable 0162
		throw new SwitchStatementException(propertyChangeSignalVO.propertyChangeType.ToString());
		break;
		#pragma warning restore 0162
	}
}

3. MODEL – DISPATCH CHANGES

private List<string> _gameList;
public List<string> gameList 
{
	get 
	{
		return _gameList;
	}
	set 
	{
		//TODO: CONSIDER ALTERNATIVE THAT CHECKS "_gameList != value" BEFORE DISPATCHING
		_gameList = value;
		gameListPropertyChangeSignal.Dispatch (new PropertyChangeSignalVO(PropertyChangeType.UPDATED, _gameList) );
	}
}

4. VIEW – HANDLE CHANGES

private void _onGameListPropertyChangeSignal (PropertyChangeSignalVO aPropertyChangeSignalVO)
{
	if (aPropertyChangeSignalVO.propertyChangeType == PropertyChangeType.UPDATED) {
		doRenderLayout(aPropertyChangeSignalVO.value as List<string>);
	}
}

Video

Member Resources

Members can access the full source-code for this post. Membership is free.

[private_Free member]Enjoy this members-only content!

• Download Source-code ( StrangeIoCTemplate2 )

[/private_Free member]