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.  Such 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.

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.  With 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.

 

Here is the snippet of code used to get the properties of an object.
console.log(“this from a [location]”);
for(name in this){ console.log(“property: ” + name ); }

WARNING:
The properties listed are from this and this.inst, however “this” may have a difference reference value.

C2 Get Plugin and the start of a C2 SDK

Put this in the top of the runtime.js, but under
assert2(cr, “cr namespace not created”);
assert2(cr.plugins_, “cr.plugins_ not created”);

if( !cr.hasOwnProperty(“c2kit”) ) cr.c2kit = {}; // prep a c2 sdk kit

if( !cr.c2kit.hasOwnProperty(“getPluginObject”) )
cr.c2kit.getPluginObject = function(runtime, plugin)
{
var plugins = runtime.types;
var name, inst;
for (name in plugins)
{
inst = plugins[name].instances[ 0 ];
if (inst instanceof cr.plugins_[ plugin ].prototype.Instance)
return inst;
}
return null;
};

sample use:
// get the object first as the object is needed for running functions
var audioObject = cr.c2kit.getPluginObject( this.runtime, “Audio”);

// audio object is the memory run, the plugin is the functions
var audioPlugin = audioPlugin = cr.plugins_.Audio.prototype;

// when using a function, we need to pass the memory instance
// in a js call function. so that the function assigns this as the right
// memory object
audioPlugin.acts.PlayByName.call(audioObject, 0, “foo”, 0, 1, “”);

Instance
Memory Runtime from
Plugin – this
Behavior – this.inst

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.

property: type
property: runtime
property: recycled
property: uid
property: puid
property: iid
property: get_iid
property: toString
property: extra
property: instance_var_names
property: instance_vars
property: x
property: y
property: z
property: width
property: height
property: depth   < What is depth for?, usually this would be zIndex
property: angle
property: opacity
property: hotspotX
property: hotspotY
property: blend_mode
property: compositeOp
property: srcBlend
property: destBlend
property: effect_params
property: active_effect_types
property: active_effect_flags
property: bbox
property: collcells
property: rendercells
property: bquad
property: bbox_changed_callbacks
property: set_bbox_changed
property: add_bbox_changed_callback
property: contains_pt
property: update_bbox
property: update_render_cell
property: update_collision_cell
property: get_zindex
property: tilemap_exists
property: tilemap_width
property: tilemap_height
property: tilemap_data
property: updateActiveEffects
property: uses_shaders
property: bbox_changed
property: cell_changed
property: visible
property: my_timescale
property: layer
property: zindex      < Hey zIndes.. why depth?
property: collision_poly
property: collisionsEnabled
property: behavior_insts  < could be a behaviour objects?
property: properties
property: is_contained
property: siblings
property: onCreate
property: onDestroy
property: saveToJSON
property: loadFromJSON
property: draw
property: drawGL
property: getDebuggerValues
property: onDebugValueEdited

 

Object
List of Properties of  “this” from
Behaviour – behinstProto.onCreate & behinstProto.tick
Plugin – pluginProto.Instance

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.   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.

C2 Object – this
property: type
property: behavior
property: inst
property: runtime
property: recycled
property: properties
property: onCreate
property: onDestroy
property: saveToJSON
property: loadFromJSON
property: tick
property: getDebuggerValues
property: onDebugValueEdited
It would seem there are three levels to a Plugin, with behaviours exending the Plugin scope.

1. Root prototype
I didn’t list this any where in the post. But this would be the global Plugin initiator.

2. Core Object and Engine Functions
This is where the most basic object information sits. This often include the constructors, destruction and what would be your personal variables for the Plugin

3. Instance Properties and Gaming Function
This is where all the awesome fun stuff happens and most of the manipulation occurs here.

Alright with this foundation in hand. Go ahead are work on creating some awesome Plugins and Behaviors. I know I will be 🙂