SDK manual

For developers using the Construct 2 Javascript SDK

Post » Fri Dec 12, 2014 2:38 pm

Hi,

I've read the sdk manual but didn't found what I needed at that moment (how to change dynamically a sprite frame in the plugin js)

In a post forum I've found this : "cr.plugins_.Sprite.prototype.acts.SetAnimFrame.call()"

Where can I found this kind of information? Is there a more comprehensive manual about the sdk?

Thanks for your help :)
B
4
Posts: 8
Reputation: 216

Post » Fri Dec 12, 2014 4:45 pm

Not really. It's assumed those who want to use the SDK are already well versed in Javascript and so can use the SDK templates in combination with all the built-in examples.

If you have specific queries, then Ashley or one of the other plugin gurus are usually quite good at answering.
If your vision so exceeds your ability, then look to something closer.
Moderator
B
131
S
29
G
81
Posts: 5,328
Reputation: 56,630

Post » Fri Dec 12, 2014 4:53 pm

You shouldn't do this. Plugins shouldn't go round making arbitrary changes to other objects. It should be up to the user to make that happen. Also the plugin condition, action and expression functions are written to be called by the C2 event engine, not any other code, so they may not even work correctly if you use them outside of the event system (depending on the flags or the event system customisations used). Plugins don't specify a more friendly JS API because it's not intended that you do this at all.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Post » Fri Dec 12, 2014 8:41 pm

@Ashley

The problem is NOT designer can not make it technically, but designer can not reuse these plugins in your framework.
Designer might copy the sprite plugin only for adding an action or something to reach his purpose. I do not think it is better.
So please provide more flexible framework for 3rd plugins rather than only said "you should not do that".

3rd plugins only could be used in c2, they all will be parts of c2. It worth to have a more powerful SDK.
B
108
S
26
G
258
Posts: 4,430
Reputation: 145,179

Post » Mon Dec 15, 2014 9:40 am

Thanks for your answers :)

I agree with rexrainbow, a more powerfull SDK can only benefit the c2 community.

But in this case (porting a game from actionscript to construct) I will try to find another way to do it without the SDK. :D
B
4
Posts: 8
Reputation: 216

Post » Mon Dec 15, 2014 9:55 am

@tet2brick

A plugin is a module only, it might not be suitable to place whole game logic into a plugin.

BTW, here is a possible solution to reuse ACE in plugins.
B
108
S
26
G
258
Posts: 4,430
Reputation: 145,179

Post » Mon Dec 15, 2014 11:29 am

I do not agree that plugins should re-use other plugins. They should generally be standalone and not depend on anything else, and the user should set up dependencies with events. For example if you go ahead and rely on calling the Sprite object 'Set animation frame' routine directly, you now:

- have a hard dependency on the Sprite object: if it's not in your project, that feature of the plugin will not work,
- lose control over the Sprite animation frame from events: either the plugin overrides it continually, or will change it based on its own logic which may conflict with normal animation playback or the user's events,
- breaks interoperability with other features, e.g. what if you wanted to use a Spriter animation instead? Or another third-party plugin?

Compare to simply providing an expression for the animation frame the plugin wants to set. This solves all the above problems, and the user can achieve what you wanted in the first place by simply setting the animation frame to that expression every tick, but with way more flexibility to implement their own custom logic around that.

Note very few official Construct 2 features depend specifically on other plugins or behaviors. For example you can set text to either Text objects or Sprite Fonts; you can use the Pathfinding behavior on any object, not just Sprites; data is provided through expressions instead of forcing you in to using WebStorage; etc.

So no, I see it as always a bad idea to do this, unless you somehow persuade me that your particular use case cannot reasonably work any other way.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Post » Mon Dec 15, 2014 1:41 pm

@rexrainbow

I did not place the whole game logic in a plugin, just the level parsing part. (my level are in a json file, but not formated for construct 2, I just did not want to make all the levels manually again)

@Ashley

So is there a simple way to import a json not formated for c2 and convert it to a tilemap?

Thank you :)
B
4
Posts: 8
Reputation: 216

Post » Mon Dec 15, 2014 2:35 pm

tet2brick wrote:So is there a simple way to import a json not formated for c2 and convert it to a tilemap?

Is that what you are trying to do? Why would you even want to use Sprites for that instead of the Tilemap object? Your plugin should probably just convert the format in to one the Tilemap object understands.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Post » Mon Dec 15, 2014 5:27 pm

@Ashley

I would like to separate this discuss into some parts.

1. If a segment of events appears usually in a kind of game / application, i.e. it is a template. It is worth to encapsulate this segment of events into a function, or pack it into a plugin.
A benefit of encapsulate events is to reduce the bug, even 1 action + 1 expression might have bug; another benefit is more readable.
A function might be easier to be made than a plugin. But "function" events might not be easier to copy to another project.

2. Which parts of event should build into plugin? Which parts should expose on event sheet?
I would analyze the behavior of usage - Which parts of events are changeful in every calling. Which parts of events is almost fixed.
If the event pattern of (1 action + 1 expression) is almost fixed in most of cases, I would like to build it into plugin (usually, but not always)
But what if this pattern is changed/not existed in some cases? Just provide another "manual" operation mode by leaving the expression for these kind of cases.
So my plugin will have more than one usage modes, one is simple mode for most of cases, one is manual mode to expose more control.


Edit
I agree @Ashley 's framework which all plugins are independent could cover all cases. I had this mode in my plugin if necessary, too.
"I can do it" is good, "I can do it with a more easier way" might be better, IMO. So I would try to provide more high level ACE in my plugin to cover more basic events for some specific applications.
This idea is also in official C2 plugin, for example, in platformer game, using platform behavior might be the first choice than using custom moving behavior.
Last edited by rexrainbow on Tue Dec 16, 2014 6:35 am, edited 7 times in total.
B
108
S
26
G
258
Posts: 4,430
Reputation: 145,179

Next

Return to Javascript SDK

Who is online

Users browsing this forum: No registered users and 0 guests