Call me dumb, but for the life of me, I can't figure out wtf half these files are doing in the template and why they are arranged that way. The addon sdk doesn't really help either. Ideally there should be some more pictures and break down whats going on. Instead, the manual is like, "Make sure you change this line here, and here, and here, to match this line over here... What is this? American tax season? I shouldn't have to waggle around 12 files to follow what a SINGLE behavior is doing. Its ridiculous.
You think you could just read them, and they would have comments explaining what they are doing, but not really, they more or less just warn you you can break a behavior just for doing things wrong... In the c3 runtime folder in behavior.js is this:
"use strict";
{
const C3 = self.C3;
C3.Behaviors.MyCompany_MyBehavior = class MyBehavior extends C3.SDKBehaviorBase
{
constructor(opts)
{
super(opts);
}
Release()
{
super.Release();
}
};
}
But one folder up is a file named the same thing and it has this:
"use strict";
{
const SDK = self.SDK;
////////////////////////////////////////////
// The behavior ID is how Construct identifies different kinds of behaviors.
// *** NEVER CHANGE THE BEHAVIOR ID! ***
// If you change the behavior ID after releasing the behavior, Construct will think it is an entirely different
// behavior and assume it is incompatible with the old one, and YOU WILL BREAK ALL EXISTING PROJECTS USING THE BEHAVIOR.
// Only the behavior name is displayed in the editor, so to rename your behavior change the name but NOT the ID.
// If you want to completely replace a behavior, make it deprecated (it will be hidden but old projects keep working),
// and create an entirely new behavior with a different behavior ID.
const BEHAVIOR_ID = "MyCompany_MyBehavior";
////////////////////////////////////////////
const BEHAVIOR_VERSION = "1.0.0.0";
const BEHAVIOR_CATEGORY = "general";
const BEHAVIOR_CLASS = SDK.Behaviors.MyCompany_MyBehavior = class MyCustomBehavior extends SDK.IBehaviorBase
{
constructor()
{
super(BEHAVIOR_ID);
SDK.Lang.PushContext("behaviors." + BEHAVIOR_ID.toLowerCase());
this._info.SetName(self.lang(".name"));
this._info.SetDescription(self.lang(".description"));
this._info.SetVersion(BEHAVIOR_VERSION);
this._info.SetCategory(BEHAVIOR_CATEGORY);
this._info.SetAuthor("Scirra");
this._info.SetHelpUrl(self.lang(".help-url"));
this._info.SetIsOnlyOneAllowed(true);
SDK.Lang.PushContext(".properties");
this._info.SetProperties([
new SDK.PluginProperty("integer", "test-property", 0)
]);
SDK.Lang.PopContext(); // .properties
SDK.Lang.PopContext();
}
};
BEHAVIOR_CLASS.Register(BEHAVIOR_ID, BEHAVIOR_CLASS);
}
There are also several other duplicate named files. and those duplicates have nothing going on in them other than the un-commented default. In total there are 12 files to edit in order to make a single behavior. Not to be the person who keeps saying, "Unity this, and unity that"... but in unity, you make one script, and maybe one more to define how properties are displayed in the editor, and that's it, not unlike many other engines out there.
I mean, all this extra data should be generated by c3, and editable in editor. There is no reason to have to wade through 12 files, regardless of how 1337 your single ACE is. Imagine if you had to create 12 files in Unity, just to move a transform every tick. Rar,
/rant