SDK manual

0 favourites
  • 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

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

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

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

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

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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

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

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

  • tet2brick

    I had made TMX importer plugin before. It is a parser for tmx string (XML or JSON format).

    It also provides two modes, one will create tiles automatically, including set position and set frame, and still could configure each tile under specific event; Another mode is just retrieving the data structure of these tiles in tmx string.

  • Ashley

    I was trying to do that because in the first platformer tutorial it's explained how to use sprite to make a simili tilemap. I discovered the tilemaps object yesterday.

    I will do something manually, it's more simple

    Thanks

  • rexrainbow

    Thanks! I will try that

  • Ashley - In the context of "plugins should be independent"... what you said makes sense to me, however I have become very tired with wiring objects together via events over and over, project after project. Since we can't package events together in a reusable way, that leaves only sdk to make behaviors do these things... How then can large scale projects reusing the same events be effectively managed? I need over 350 events simply to get my custom box2d platformer working... I have saved the basics of this to a template file, but its still a lot of tedium. I have also toyed with the idea of putting the code in the physics behavior as an enable-able constraint but that brings up many problems(I am sure you know what I mean here). The final, most sensible, thing to me would be to make a behavior that can call another behaviors functionality via actions, conditions, and expressions. Even writing an AI that then calls a behavior using another behavior attached to a specific plugin isn't a bad thing at all...

    And it's not like we all are writing for the community or trying to make behaviors that work in any way. Each game is it's own thing, but I am fond of not having to do the same work again and again.

  • Ruskul

    Ashley

    Agree.

    "You could make this feature in event sheet" is not enough. To put all features which might come from different project (capx file) together easily with bug free and is more important for product.

    Even packing events into plugins/behaviors could not solve whole problem, it only a little better solution than pure events.

    A more better way is - "package events together in a reusable way" like Ruskul said.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)