Feedback

Beta Testing Composer GUI Beta Testing
#1

Hi.  This is Ed Maurina (ignore the badge to the left) and this is my feedback.

Oh, before I start, I’m treating this as if it were a released product.  In which case, these are my ‘stream of conciousness’ comments…

My #1 input (to me the most important) is Feature Request #3 ’ Allow User-Scripting/Extension Of Editor’. 

Bugs

  1. Drag Placement Not 100% Saved - Occasionally I’ll drag an object and hit ‘play’ button only to see the object position is wrong.
  2. Top Bar Corrupts - Sometimes the top-bar gets squeezed together. i.e. The part with
    Name:, W:, H: etc.  The labels are hidden under the fields on occasion.

General Thoughts

  1. Keyboard Input - Awesome.  Glad you used key mapped editing.
  2. Re-Sizing Not Allowed - If this were a finished product, I’d definitely expect the editor to be
    resizable to the entire screen.  I want to use all of my screen-space
    when editing.
  3. Quick Positioner - Nice.  I like the ability to quickly snap objects to corners, sides, and centers.

Feature Requests

  1. Hover Tips - All interface elements need hover tips. Ideally, the hover tip would be a short title or blurb and the key-map for that action if it has one.
  2. Custom Keymapping - Allow users to modify keymapping to suit their own usage.
  3. Allow User-Scripting/Extension Of Editor - Allow users to write add-on or plugin Lua (or other language) modules to modify default editor behaviors and to add new ones.  This will take some of the onus for adding features to the editor off the Corona team.  As well, it will allow users to build up a free and paid ‘add-ons’ marketplace for editor features.  Let users make their own dog-food.
  4. Custom Fields - Allow inspector to detect, add, and remove custom fields on all objects.  This will go a long ways to meshing game-specific behaviors with the editor.
  5. User Specified Fields - In addition to #4 above, having the ability to specify allowed values for custom fields would be nice.  i.e. Support standard Lua field and an additional field-type where users can script the acceptable values.  An example of this in the current implemenation is the ‘Body Type’ field.  It only accepts specific values.
  6. Folder Tree - A folder tree (instead of current method) would be nice. 
  7. Scene Quick Switch - Having the ability to switch between scenes rapidly will greatly improve editing speed for large (multi-scene) projects.
  8. Group Selection - It would be nice to group select objects and to then be able to move them by a common center and even to group and ungroup them. Subsequent addition of scaling, rotation, and other complex group modifications would also be a plus.
  9. Alternative Output - Right now the edited scene file is saved as what looks like a JSON encoded table containing the entire scene.  This is fine for re-loading in the editor and even for loading in a game.  However, providing the option to generate actual Corona code instead would be a great big plus.  Yes, I know this is complicated, but hey this is my wish list.
  10. Zooming - I must be allowed to zoom in and out on objects for micro-positioning, especially if my screen is small.
  11. Snap-Grid - A fully-adjustable snap grid that supports these features: toggle-on/off, drag snapping with shift-key or other keyboard activator, optional visible overlay with configurable color, and programmable x and y grid size.
  12. Select All - Yes, sometimes I want to select everything and delete it.  Keyboard and menu based of course.
  13. Context Sensitive Right-Mouse Menu - I’m a 3-button mouse user and I always use context sensitive menus off the right-mouse button. 
  14. Transitions Editor - You’ve got part of the interface already.  The group tree at the bottom has many of the same elements you’d want/need to configure time-based transitions.
  15. Assets Sub-folders - Big projects have lots of assets.  I suggest representing one-level of sub-folders as a fold-able set of asset blocks, sort of the way you allow a fold-able area for the object inspector fields. Example here.
  16. Sprites Editor - I suggest a separate pane for creating, deleting, and editing sprites sort of like this.

Please note, I think that the Torque guys did a pretty fine job putting together the editor for their engine (Torque 2D), but fell down in one place.  It was possible to modify the editor, but because they never made the spec official, you couldn’t rely on your own changes being future-compatible.

#2

Thanks Ed. This is some really good feedback. 

Can you give examples of the type of extensions you’d like to provide?

Also, after #3, what’s the next most important one for you?

#3

@Walter,

With regard to #3 (extensions).  When I worked with the Torque 2D game engine, I was able to edit and add to the editor.  Thus I could add new tools and tools that could detect details about objects and treat them differently or provide more editing options.  This allowed me to do two things:

  1. I could make custom mods for use in my own game and app developement.

  2. I could (and did) make a custom toolset to add extra editing tools which I then released to the community.  I made a tool kit that allowed users to generate ‘behavior’ code in the editor and then to strap that code onto their objects.  I then supplied a library of behavior ‘atoms’ that could be combined in the editor. 

http://roaminggamer.com/wiki/index.php/SSK_-_Generating_Behaviors

The real point of #3 is that, with the ability to add new panes, sections, edit fields, menus, etc. The user is able to make anything they want, need, and are capable of making.  The sky is the limit.

As far as my next most imporant… That is hard, but I’ll go with #4.  This would, as I mentioned, allow folks to customize the behavior of their games immediately, by editing field settings in the editor and using those settings in their code.

Thanks!

PS - This makes me think, that I should revive the Green Kit (my final name of the Torque 2D behavior kit) and port it to Corona.  At its peak, there were enough atoms and combinations to generate over 7000 complex ‘behaviors’ which could be strapped onto game objects in one line of code.  i.e Drag and Drop, Click to change image, On-Enter Trigger do … whatever, etc. etc.

#4

Right, all of this sounds great.

So with this atom/behavior stuff, there’s infrastructure that supports this, so I’m trying to wrap my head around what the specifics of that infrastructure are.

Do you happen to have a bare-bones “atom” in Corona that we could look at? That would help us understand the hooks that you need at the Lua level, and also what UI (panels, etc) would be needed to use the atom.

#5

@Walter,

I think I’ve been confusing thus far.  So, give me a little time to put together a proper example of what I’m talking about and I’ll post back. 

Note: This may take till later Friday (April 4th).

#6

Thanks Ed. This is some really good feedback. 

Can you give examples of the type of extensions you’d like to provide?

Also, after #3, what’s the next most important one for you?

#7

@Walter,

With regard to #3 (extensions).  When I worked with the Torque 2D game engine, I was able to edit and add to the editor.  Thus I could add new tools and tools that could detect details about objects and treat them differently or provide more editing options.  This allowed me to do two things:

  1. I could make custom mods for use in my own game and app developement.

  2. I could (and did) make a custom toolset to add extra editing tools which I then released to the community.  I made a tool kit that allowed users to generate ‘behavior’ code in the editor and then to strap that code onto their objects.  I then supplied a library of behavior ‘atoms’ that could be combined in the editor. 

http://roaminggamer.com/wiki/index.php/SSK_-_Generating_Behaviors

The real point of #3 is that, with the ability to add new panes, sections, edit fields, menus, etc. The user is able to make anything they want, need, and are capable of making.  The sky is the limit.

As far as my next most imporant… That is hard, but I’ll go with #4.  This would, as I mentioned, allow folks to customize the behavior of their games immediately, by editing field settings in the editor and using those settings in their code.

Thanks!

PS - This makes me think, that I should revive the Green Kit (my final name of the Torque 2D behavior kit) and port it to Corona.  At its peak, there were enough atoms and combinations to generate over 7000 complex ‘behaviors’ which could be strapped onto game objects in one line of code.  i.e Drag and Drop, Click to change image, On-Enter Trigger do … whatever, etc. etc.

#8

Right, all of this sounds great.

So with this atom/behavior stuff, there’s infrastructure that supports this, so I’m trying to wrap my head around what the specifics of that infrastructure are.

Do you happen to have a bare-bones “atom” in Corona that we could look at? That would help us understand the hooks that you need at the Lua level, and also what UI (panels, etc) would be needed to use the atom.

#9

@Walter,

I think I’ve been confusing thus far.  So, give me a little time to put together a proper example of what I’m talking about and I’ll post back. 

Note: This may take till later Friday (April 4th).