Working the C2 SDK is not elegant. In fact I would say that the C2 engine was not designed for other developers. There is a lack of documentation and overall a lack of an SDK engine. Instead most of the work with C2 engine is through a small set of callbacks and properties. Often Scirra(Ashley) encourages that Plugins and behaviors have little interaction with others of similar type. \u00a0Such as no Plugin to Plugin interaction and no Behavior to Plugin interaction. Also no Plugin to Behavior interaction, but Behavior to Plugin interaction is encouraged… whew.<\/p>\n
however making anything advanced requires either an SDK or just plain ignoring all this direction. Developers such as RexRainbow and R0j0hound are two in the community that do so regularly. \u00a0With a lack of documentation I have been repeating a simple code that logs the properties of an Object, but this is becoming tedious so I’m going to post the property names in this post. I’m also going to post a piece of code snippet that I use to grab another Plugin… not behavior.<\/p>\n
<\/p>\n
Here is the snippet of code used to get the properties of an object.
\nconsole.log(“this from a\u00a0[location]”);
\nfor(name in this){\u00a0console.log(“property: ” + name ); }<\/p>\n
WARNING:
\nThe properties listed are from this and this.inst, however “this” may have a difference reference value.<\/p>\n
Put this in the top of the runtime.js, but under
\nassert2(cr, “cr namespace not created”);
\nassert2(cr.plugins_, “cr.plugins_ not created”);<\/p>\n
if( !cr.hasOwnProperty(“c2kit”) ) cr.c2kit = {}; \/\/ prep a c2 sdk kit<\/p>\n
if( !cr.c2kit.hasOwnProperty(“getPluginObject”) )
\ncr.c2kit.getPluginObject = function(runtime, plugin)
\n{
\nvar plugins = runtime.types;
\nvar name, inst;
\nfor (name in plugins)
\n{
\ninst = plugins[name].instances[ 0 ];
\nif (inst instanceof cr.plugins_[ plugin ].prototype.Instance)
\nreturn inst;
\n}
\nreturn null;
\n};<\/p>\n
sample use:
\n\/\/ get the object first as the object is needed for running functions
\nvar audioObject =\u00a0cr.c2kit.getPluginObject( this.runtime, “Audio”);<\/p>\n
\/\/ audio object is the memory run, the plugin is the functions
\nvar audioPlugin =\u00a0audioPlugin = cr.plugins_.Audio.prototype;<\/p>\n
\/\/ when using a function, we need to pass the memory instance
\n\/\/ in a js call function. so that the function assigns this as the right
\n\/\/ memory object
\naudioPlugin.acts.PlayByName.call(audioObject, 0, “foo”, 0, 1, “”);<\/p>\n
This is from a WORLD only object. There are no positional, sizing or other such flags. So it’s surprising there is so much junk in the this. World seem that this is the level where behaviors would be attached. but there is reference to Tilemaps, even if tilemaps aren’t used. Sorry Ashley, but this seems poor design architect that everything including the kitchen sink get’s thrown in even when it’s not needed.<\/p>\n
property: type
\nproperty: runtime
\nproperty: recycled
\nproperty: uid
\nproperty: puid
\nproperty: iid
\nproperty: get_iid
\nproperty: toString
\nproperty: extra
\nproperty: instance_var_names
\nproperty: instance_vars
\nproperty: x
\nproperty: y
\nproperty: z
\nproperty: width
\nproperty: height
\nproperty: depth \u00a0 < What is depth for?, usually this would be zIndex
\nproperty: angle
\nproperty: opacity
\nproperty: hotspotX
\nproperty: hotspotY
\nproperty: blend_mode
\nproperty: compositeOp
\nproperty: srcBlend
\nproperty: destBlend
\nproperty: effect_params
\nproperty: active_effect_types
\nproperty: active_effect_flags
\nproperty: bbox
\nproperty: collcells
\nproperty: rendercells
\nproperty: bquad
\nproperty: bbox_changed_callbacks
\nproperty: set_bbox_changed
\nproperty: add_bbox_changed_callback
\nproperty: contains_pt
\nproperty: update_bbox
\nproperty: update_render_cell
\nproperty: update_collision_cell
\nproperty: get_zindex
\nproperty: tilemap_exists
\nproperty: tilemap_width
\nproperty: tilemap_height
\nproperty: tilemap_data
\nproperty: updateActiveEffects
\nproperty: uses_shaders
\nproperty: bbox_changed
\nproperty: cell_changed
\nproperty: visible
\nproperty: my_timescale
\nproperty: layer
\nproperty: zindex \u00a0 \u00a0 \u00a0< Hey zIndes.. why depth?
\nproperty: collision_poly
\nproperty: collisionsEnabled
\nproperty: behavior_insts \u00a0< could be a behaviour objects?
\nproperty: properties
\nproperty: is_contained
\nproperty: siblings
\nproperty: onCreate
\nproperty: onDestroy
\nproperty: saveToJSON
\nproperty: loadFromJSON
\nproperty: draw
\nproperty: drawGL
\nproperty: getDebuggerValues
\nproperty: onDebugValueEdited<\/p>\n
<\/p>\n
Examining the properties. This would look like a the prototype and not a run memory values… however it seems overall there is a lot of mixing. \u00a0 What really throws a strange wrench into this is that “this” when access from the initiator on Plugin.Proto.Instance a location where you create variables; this is not the same as the above Plugin memory run time.<\/p>\n
C2 Object – this
\nproperty: type
\nproperty: behavior
\nproperty: inst
\nproperty: runtime
\nproperty: recycled
\nproperty: properties
\nproperty: onCreate
\nproperty: onDestroy
\nproperty: saveToJSON
\nproperty: loadFromJSON
\nproperty: tick
\nproperty: getDebuggerValues
\nproperty: onDebugValueEdited
\nIt would seem there are three levels to a Plugin, with behaviours exending the Plugin scope.<\/p>\n
1. Root prototype
\nI didn’t list this any where in the post. But this would be the global Plugin initiator.<\/p>\n
2. Core Object and Engine Functions
\nThis is where the most basic object information sits. This often include the constructors, destruction and what would be your personal variables for the Plugin<\/p>\n
3. Instance Properties and Gaming Function
\nThis is where all the awesome fun stuff happens and most of the manipulation occurs here.<\/p>\n
Alright with this foundation in hand. Go ahead are work on creating some awesome Plugins and Behaviors. I know I will be \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
Working the C2 SDK is not elegant. In fact I would say that the C2 engine was not designed for other developers. There is a lack of documentation and overall a lack of an SDK engine. Instead most of the work with C2 engine is through a small set of callbacks and properties. Often Scirra(Ashley) … Continue reading Working with the SDK – Object Properties<\/span>