A better interface for objects suggestion.

[droberson]

Problem Description: If I add an object to a frame, for example the edit object, and then I want to access the properties, functions, actions, methods, or help files I have to access this information in several different ways and different screens.

For example, what is the interface for the edit object. We need to search help. In this case there is a help file that lists actions, conditions, expressions, and properties. What if no help file is available? Then it becomes a guessing game. First you need to go the event editor and set a condition like "start of frame" and then check the list of actions. Then if you don't find what you want, you then can go back to conditions and search for a list of conditions. Then if you don't find what you want, you try to find an action that brings up the expression editior an you use "get data from object" and see if there is some function. So far that four different areas to search to try find what you are looking for. Last of all you can issue a post and see if anyone else knows the answer.

Let's consider the edit object and see if the is an expression, action, or condition that allows the user to
tell if the "multiline" is turned on. Well I can see in the properties are that it is but I need to have the program check it at run time. So we look at actions - no not there,
we look at conditions - no not there, we check expression edition functions - no not there. We check the help file yes there is a help file but that is not always the case for all objects.

Another problem is the in some cases actions or conditions may use "get x value" or just "x value". It varies also leaving the user wondering what does x value mean. Get x value is clearer what is happening.

Overall this interface also causes a user problems in trying to connect objects together because the interface is spread out. If I am clicking on a drop down of actions I really would like to get a complete list of everything: actions, conditions, or functions I can call.

Functions in the expression editor area are also a source of confusion. Sometimes you are unsure what is being requested you type in. Not in all cases however.

Here is another example, lets say I set a condition of "start of frame" and then I go to actions to and want to check if "is font bold?" Well it is not in actions. So now I have to change my logic. "Is font bold?" is part of conditions. Why can't conditions functions be part of the actions dropdown? Then I could write a condition "Start of frame" and action "Is font bold?"

I know that in the beginning the idea was for objects to have conditions, actions, expression, functions. But this spreads out the interface so much as to cause problems. The "Is font bold?" function should be available in conditions or actions or expressions or functions no matter what screen you are at.

This is not a complaint against Clickteam or MMF. Just an opinion after using MMF and other programming languages. Objects are great but put more pressure on ensuring the users can understand the interface and what it provides to you can logically link it to other object and their interface.

So in summary:
1. Use consistant "get" and "set" from getting and setting properties like text, x values, y values etc...

2. Make all properties and functions available in conditions and actions.

3. Allow help files to be added to by users with examples like a wiki.

Well just some ideas to consider.

[Harvy]

"Why can't conditions functions be part of the actions dropdown? Then I could write a condition 'Start of frame' and action 'Is font bold?'"

That doesn't make any sense semantically. "Is font bold?" is clearly a condition, not an action. What would the action do?

MMF breaks down the interface into 3 parts: conditions, actions, and expressions. That's it. We've discussed (in different threads) how better logic flow could be supported, but I've never had trouble figuring out the interface of an object. Most objects have built-in help, if you go to the About tab in properties.


I will agree that a streamlined interface for getting and setting properties would be nice. Right now the extension writers have to manually write those. For example, for a long time you couldn't change the Acceleration or Gravity at runtime; you still can't change Jump Strength. But I don't think it's one of the more pressing issues, unlike the major limitations on qualifiers or the fact that MMF doesn't bind actual object data to Create Object actions (when you copy & paste, or use it in global events).

[droberson]

I was thinking that this would follow normal thinking patterns better. The "Is Font Bold?" action/function would return a true or false. My next condition could be an "IF object" or "DoWhile" loop or "Is Font Bold? = True" condition then followed by another action/function call.

This would help in being able to use psudocode or perhaps in the future have a flowchart graphical programming interface for MMF in addition to the point and click. The flowchart or decision tree interface would be far easier to understand if you are using a lot of "if" statements for example than the current list of condition/action statements. Also for adding AI interfaces to build more intelligence gaming objects a decision tree interface is easier to understand what is going on and how the logic of the program is working.

Also take for example a class defination like in c++. You have properities and a set of methods for getting and setting properties and you have additional methods for getting other things done.

[droberson]

Harvy, I was giving some more throught to your comment.
The condition/action events are really just a if-then statements.
IF Start-of-frame then <do something>
Next event
Next event
etc.

Each of the above is really just an if-then statement that MMF2 engine ckecks in order from top to botton on each loop.

So what I am saying is that by allowing the "condition" to be use in the action part you are creating nested if statements.

Condition=Start of frame then action=Is font bold = true
Contition=Is font bold = true then Print

This is the same as:
If "Start of frame" and Is font bold? = true then
ect.....

I know there are nested-if objects and dowhile objects etc...but this is due to fact of MMF2 not having buildin logic flow like what I am discussing.