Can my c2-project be a co-platform for mainstream web-features?
I spent 370 hours in 3.5 months of 2014 to make this c2-prototype (ELGG hours not-counted).
Should i make a u-turn or continue with c2? The desired features are:
mixing with custom HTML, custom JS,
using JS to port to database backend,
making forum-based games:
authentication, groups, blogs;
The c2 greatly aids in helping non-programmers.
What about mature-c2-beginners?
I need an advice of mature c2-developer.
I was not able to attach caps file and text files here. They are linked.
Live link: Added plugins: Capx-file: Short video: This file: Graphics is blurred to comply stakeholder-copyright.
Before narrowing the question, here is what app does:
1. it loads only part of images for the first screen;
2. at load, narrator appears; he throws messages from his mouth;
narrator scenario is set as json file ( editable from CMS outside of c2);
this file loads as an arbitrary c2 JS object, not an c2-array;
plugin "jsob" is created to port such objects to c2;
3. game contents loads from database and authenticates from ELGG.
jsob is used again to talk with db;
in given demo this talk is "shortcurcuited" to json file;
upon login friends info is provided which visualizes like
these thumbs are located on four pluzas, can be drag-drop-snapped;
the JS scenario, config, and functionality for drag-drop-snap is
downloaded via jsob;
We felt lack of access to raw JS and made up a plugin, "btb":
access to functions and objects in window-namespace
right from c2-event-sheet.
4. land-layers can be zoomed; done via c2-event-sheet;
5. three HTML-pages merged with c2: game-room, activity, and video;
We felt lack of HTML-element plugins ( only button, textbox, ...
existed in c2-core few months ago )
We made "html" plugin.
So, when user click on "games" icon, the html-page appears on the
top of c2-canvas which optionally can edit game-json scripts ( if
admin is logged ).
These 3 plugins are messy, overlapping, and need polishing.
Again, the question is:
I. Is this fair to spend so much time on this? Would be the result accomplished with other platform faster?:
II. Below are the specific areas of concern:
* port other JS-libraries:
we had to do this to port narrator-dialog-script with
text bubbles coming from the mouth,
this dialog is configured as json text;
this json text is editable through CMS outside of c2;
* JS-library for baby-house thumbs
drag-drop-snap on 4 pluzaz,
popover on them,
click on them,
magnification of them when their layer is zoomed-in;
* concern: some libraries do mix object.property and object[ 'property' ] notations;
it this a serious road block in using c2? we cannot use c2-V8-minifier;
for example, jQuery is not c2-minified by the same reason (?);
moreover, because of our plugins are not minifiable, they cannot claim c2 support,
* c2 seems HTML-elements-agnostic:
before r178, there where quite less controls: button, textbox, ...
in r178 there are more, ...
but the appoach is alarming: they still look like "foreign" things in c2,
we had to add generic-type HTML-control plugin ( html ), but not sure ...
the rules of adding such plugins seems still obscure and understanding full
plugin machinery is obscure and time-consuming ...
(click on "GAMES" button on the right)
* c2 seems HTML-project agnostic:
Little tools to manage additional web pages:
The great addition is "Files" option in project tab.
It allows folder there and files directly editable right from there.
But, folder structure is destroyed when project is published.
So, no way to merge 3d party app. by copy-paste into c2-root at edittime.
Developer, must take own care in merging c2 and HTML-projects
after c2-project is exported. So, there is no single-click button
which deploys project which is a great time loss.
* c2 seems JS-agnostic:
there are no controls to access JS-features effectively:
For example: Array-object is non-practical.
In order to communicate with ELLG, we had to add a plugin to implement an
these plugins take time, based-on-our-obscure-understanding, and create production risk;
* the c2 is designed to help beginners and non-programmers;
this implies that subtle things, exact syntax, exact details are called "advanced" and
hard-to find; on top of this, the forum is not effective and time-expensive in finding advanced stuff.
A. For example: it took few days to discover that instances of sprite-obect can use different
frame to be set from single spriteset.
Many attempts failed in vain. Dev. had to create a family of sprite-objects and assign
separate picture for each of 20 objects manually.
The solution was accidentally discovered in tutorial about "platform game": set animation speed to 0.
This allows separate frames.
Apparent trend to "cut corners" for beginners harms precise development.
B. For example, it took a while to understand that sprite.visible has nearly nothing to do
with actual visibility of this sprite, but is just an attribute: a hidden sprite can have this attribute set to true,
and even if sprite.visible == false, it is still clickable in contrary to HTML-programming-experience.;
C. It is still unclear are c2-events fully single-thread-safe: for example: can they interwove and conflict in
Because of "polished" manual good for beginner or non-programmer and the real meat
is to be found as "tricks", this creates great inconfidence. Because of using "tricks" and "hacks" is
dangerous for production-app.
Trick or hack is something outside of master docs, so a subject of disappearance from version to version or
a subject of an imprecise guess.
Good hack and dissecting of c2-engine-source code is a good thing shedding light on how mind of c2-author works,
but this "mind" can change the c2-engine-source code without warning and in invalidate the hack.
So guess, should take in account the probability of the guessed feature will be prominent or become a "cow-path" which
c2-authors would find hard to challenge.
* The great thing about c2 is there seems a rigorous and consistent logic behind of how it works.
The only concern is that logic is not in docs.
For example, we guessed that formula for LayerShifX = max( wb + min( wc, 0), wd ).
(This is a shift for a background sprite when layer is zoomed in. The sprite belongs to this layer.
Because it is guessed that center of layer is not shifted by changing its scale, sprites shifts at scaling, and
position pointed by mouse must be corrected with LayerShifX. To test, click on planet bg. )