Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Alex Chouls

Pages: 1 ... 202 203 [204]
User Showcase / Hero Test – A 48 Hour Game
« on: March 30, 2011, 02:35:36 PM »
My good friend Steve Gargolinski recently made a game in 48 hours using Unity and Playmaker:

You can play the game on his blog (it's very funny) and also download the project files.

He also made a cool timelapse video of the development:

Feature Requests / Re: Action filter field
« on: March 28, 2011, 02:14:33 PM »
1.1 is in beta now. Hopefully we'll get it out this week...

iOS Help / Re: Touch Control for iOS
« on: March 28, 2011, 02:12:04 PM »
1.1 is in beta now. As long as there are no show-stopping bugs we should release this week... (working on more sample scenes now).

Action Requests / Re: Sprite Manager 2
« on: March 28, 2011, 12:06:13 PM »
I think you're right iTween Actions and SM2 sprites could be a killer combo!

I'll contact Brady to see if he has any ideas.

Also if current SM2 users have specific actions they'd like to see that would be very useful! I suspect the actions will be fairly easy to implement, but I'm not familiar enough with SM2 to know what would be useful...

Playmaker Help / Re: RunThisFrame Boolean suggestion.
« on: March 28, 2011, 11:55:17 AM »
eKo is co-founder of Hutong Games - I was reading on her computer and accidentally posted with her username. I'm sure eKo will introduce herself on the forums when she has a free moment... :)

Being able to see FSMs side by side would be very useful. We'd also like to have a project style view, one level up from the FSM graph view, that shows all FSMs in the project and their relationships...

It's often useful to understand the design problems/choices that drove the development of a tool - it can give you a better mental picture of how to use it. So here's a quick overview:

The State Inspector was designed to work like the Unity Inspector, so it feels familiar. The Unity Inspector is great, but it has no concept of state -you set up and tweak all your behaviors for one implicit state (e.g., run around and shoot) and then have to come up with some system for changing state (what happens when I'm climbing, or falling, or dead...), which mostly means hard-coding state changes in scripts where they're hard to visualize and maintain.

Most games have to manage a lot of state changes - input, AI, animations, game modes, object states etc. Really it's all these state changes that add up to a game! So the goal with Playmaker was to expand the Inspector panel idea to allow easy authoring of state changes. That's the model that drove the Graph View and State Inspector - the ability to author a set of Actions to perform when in a state, with clear transition events to other states.

Making the actions more modular and executing them in sequence allowed Actions to be combined in interesting ways, while retaining a familiar simplicity - basically if you can use the Unity Inspector, you can build states in Playmaker - at least that's the idea!

I like how simple (yet powerful) this model is in practice, but obviously we will continue to enhance it as Playmaker evolves. Thinking about multiple simple FSMs that talk to each other is definitely the strategy I would pursue - and then when Playmaker supports hierarchical FSMs you'll be well placed to take advantage...

Playmaker Help / Re: RunThisFrame Boolean suggestion.
« on: March 25, 2011, 08:57:42 AM »
One quick trick to embed some boolean behavior into a state is with Convert Bool to XXX. E.g., Convert Bool to Float could set a deltaPower variable to 0 or 10 depending on the value of a Paused variable.

Another more flexible strategy is to split it into 2 FSMs. E.g., a View FSM and Controller FSM to use the view/controller pattern. I often find I have more visual states than logical states, so rather than tying them together, make it 2 FSMs that talk to each other. Or another way to look at it: when you find yourself copy/pasting code you think about refactoring that code into a method - when you find yourself duplicating actions, you might want to consider making a separate FSM.

A third strategy would use the Next Frame action to execute a few states all in one update. E.g., Calculate deltaPower state, goes to draw power state, and at the end of the draw state a Next Frame action goes to the deltaPower state to kick the loop off again in the next frame. So every frame you're executing the calculate and draw states. To be honest I don't use this pattern myself very much - it fights a little with the FSM idea of one active state. I tend to prefer the multiple FSM approach, it feels cleaner to me... but it's good to know your options.

Actually this topic got me thinking about FSM patterns. It would be cool to collect common FSM patterns in a thread (with diagrams and explanations). Eventually those could make it into the tool as templates...

Playmaker Bug Reporting / Re: Time Scale Zero and event firing
« on: March 25, 2011, 08:40:00 AM »
Hmmm, what actions are you using? Those actions may need a "RealTime" option... in fact, thinking about it Send Event should probably have a real time option. I'll look at that for 1.1.

Feature Requests / Re: Action filter field
« on: March 25, 2011, 08:17:59 AM »
It's in version 1.1. Complete with 'x' as you describe!

It doesn't currently search the parameters/description... maybe in a future update.

Playmaker Help / Re: Some questions
« on: March 24, 2011, 12:55:59 PM »
In "GetChildNum", what does that "Index" refers to in Unity terms? Is that the order in which the object is listed in the Unity list?

Yes. It lets you iterate through children. You can use the scene hierarchy as a form of object collection, grouping related nodes under a parent. E.g., waypoints, spawnpoints etc.

In MoveTowards, does TargetObject take precedence over TargetPosition? Not sure if both are visible at once, since I don't have PlayMaker in this machine, I'm just asking because as it's shown in the site it's confusing. In any case, how would you add an "error factor" to MoveTowards (suppose it's a simulated shot), copy the object position to a variable then manually add the error? BTW, one thing that would be *extremely* handy for gameplay design is having a "prediction" boolean setting here. When turned on, the object would move towards not the current position of the object, but the predicted position of the gameobject supposing it doesn't change its current trajectory. I know that can be built with some Custom Action coding effort, would just be nice having that as a default.

The online docs are a little out of date. The in app tooltips give more info: "The Target can be specified as a Game Object or a world Position. If you specify both, then the Position is used as a local offset from the Object's Position."

This is a common pattern used whenever you see Object and Position together like this. It can be handy to give a little offset from a node in the world.

I'm working on a TrackObjectMotion action that keeps a history of an object's motion and lets you get things like: starting point, average position, starting velocity, recent velocity, predicted position... I think it will be very useful!

In "Create Object" description: 'Instantiates a game object/prefab at a spawn point. Optionally parents the new object to the spawn point.' Yet no "parent" option is visible and later in the text you hint that you can store the object in a variable to later parent it. What's the right one?

The docs are out of date. "Optionally parent" is gone - just store the object and do anything you want to it!

In "Get Collision Info" there's no description for "Contact Point" and "Contact Normal", could you elaborate?

Added some detail to the docs. It can also be helpful to check out the Unity docs on systems like physics. I try to use the same terminology...

"Random Event" has no way to select from a specific list of events, it would be nice being able to specify a list of possible events to be chosen randomized 'coz rarely you'd want every event in the FSM to be valid for a certain action, except if the FSM is built specifically for that - eg. an attack FSM split from a move FSM in an NPC.

I agree. Random Event was one of the first actions I wrote, back before I had arrays in the Action Editor! I'll add an events list...

How would you fire up an FSM Event from an Animation Clip Event?

You can actually send the event directly to the FSM. See

I don't see any "HasComponent" action...

It's in the 1.1 update. :)

SetMaterial as it is just changes the whole material...

There are other actions that target material properties. E.g., Set Material Color, Set Material Texture, Set Material Float...

1.1 also adds a Material Index so you can target any material on an object.

I've noticed you have a 'collections' data type but so far we have no documentation on it.

Quite a few actions let you define an array of choices. E.g., Select Random Game Object.

You can also use the scene hierarchy to organize things like spawn points. And use actions like Get Child Num to iterate through them.

There is no array or list Fsm Variable type yet, that you can define at the FSM level (e.g., in the PlayMakerFsm inspector). That would be nice, letting you define an array once and share it across actions.... Will probably find its way into a future update.

Also working on an Object Pool system that is good for performance, and can be used as a collection of objects. This will let you pre-populate Object Pools with game objects that you then pull from in the game loop. And you can specify what happens when the pool is empty (kill oldest etc.).

Good questions! I need to go through the docs and bring them up to date, and add all the 1.1 docs too!

Playmaker Bug Reporting / Re: Painful registration process
« on: March 23, 2011, 07:02:58 PM »
Sorry about that! We had a booming bot party going on in the first forum we set up - just a bunch of bots shouting at each other over drinks - if a human had walked into the bar they all would've turned to stare...

So maybe we overcompensated a tad... :P

iOS Help / Re: Touch Control for iOS
« on: March 23, 2011, 06:44:37 PM »
Yes we have iOS actions in the 1.1 update.

There are also iTween actions that are very powerful - great for moving characters/cameras around.

The scenario you describe will definitely be possible. In Playmaker you'd do this with a few states and events. For example:

Character FSM:

Idle: Random idle animations, waiting for a command. A MoveCommand event transitions to MoveToTarget.
MoveToTarget: Get target position from the event data and move towards it. A Finished event when the target is reached triggers a return to Idle.

Then you'd have a Controller FSM send the MoveCommand event on touching the world.

The cool thing about an FSM is it can start simple like this, but then you can quickly add states as needed to really flesh out the behavior (as opposed to a single script where all the logic is hidden and harder to change).

For example, lets say you want the character to acknowledge the MoveCommand - just add an Acknowledge state between Idle and MoveToTarget and have it play an animation/sound.

Playmaker Help / Re: Sharing a FSM with multiple prefabs
« on: March 23, 2011, 06:22:44 PM »
Hi Jason,

Assembling a creature from a collection of prefabs is probably the best way to do this at runtime right now.

At edit time you can copy/paste FSMs and create Templates that can be quickly applied to objects. Copy/paste and templates are much improved in the 1.1 update - you can copy/paste whole FSMs, and even select multiple objects and apply a template to all of them in one step. And the variable copying bugs have been fixed!

We are looking into some runtime equivalent of adding a template (e.g., an Add FSM action). I'll keep you posted as we investigate that...


Pages: 1 ... 202 203 [204]