Construct 2 SDK - Advanced use

Hi

Construct 2 evolve nicely and the tools seems to be quite pleasant to use. But I'm a bit lost with the features page.

Lately I create my own game engine, but for various reasons I'm always searching for something more easy to use.

Coming from a development side, I need to have a full access to every aspect of the engine.

I read somewhere that Construct 2 SDK would allow javascript to write plugins and behaviors.

• Is javascript fast enough to drive all the game logic ?
• Can you create OO plugins that interact with low level part of the engine ?
• Does every features of Construct 2D are accessible from javascript ? (for example box2d)

Thanks for your answer.

Micha?l

The SDK manual should answer some of those questions.

The plugin Physic is based on box2D.

You also can check out the custom plugins/behaviors.

I also recommand this blog's article with a lot of insights on C2.

Modern Javascript is compiled to machine code so it's definitely fast enough. I'm not sure what you mean by an "OO Plugin" (aren't all objects in C2 "OO"?) but they can definitely interact with the low level parts of the engine, mainly because Javascript doesn't support encapsulation. All the pre-supplied plugins and behaviors are written in the SDK as well, so all features in Construct 2 are exposed to the SDK.

You might also be interested in this blog post on Construct 2's architecture.

Thanks for the answers.

I had a look at the provided links and the architecture looks really nice !

What I was meaning by OO design was strictly a manner of organizing my game objects, but if I correctly understand Javascript does not allow this feature the way I want and you must use a few tricks to do it correctly. It's a bit a mess but ok for me.

As an example, I know that one of the potential bottleneck of using Box2d is when you solve/pre-solve/post-solve the Contact Collision by Yourself.

• First, I don't know if using these callbacks are possible within the current architecture
• Second, isn't javascript a bit slow regarding to this task ? I ask only because I don't know much about this language and I'm nearly sure that I will have at least 50 or 100 collisions points to proceed each frames which is CPU intensive.
• Same think with the AI using Finite State Machine for every objects on every cycles.

I'm only asking this from a processing speed point of view. I know that HTML5 rendering still need a bit of power to talk about graphic speed right now.

Thanks for your support.

Well I did not get answers to these questions but since HTML5 is still a promise, I bet on scirra and construct 2 as my first tool in that new area. Time will tell me if I was right <img src="smileys/smiley2.gif" border="0" align="middle" />

In any cases I can still use it to build web stuff or simple things.

Hard questions to answer, as I don't believe anyone went for such advanced/specific use yet.

For the question about collisions, as I said previously the built-in physic behavior is based on box2D.

You can check this demo that shows quite a few elements on screen with physic behavior. It's perfectly fluid on my FF 9.0.1 on win7 (NVIDIA GeForce GTX 560 Ti).

So I guess JS via C2 sounds powerful enough on computation level (I'm not sure if the webGL rendering helps in any way with the computing of physic though).

And for the AI part, same thing I guess. I think I'm not knowleageable enough on this.

The furthier I went as for "AI"/computing is the pathfinder behavior and it has always appeared to work pretty good on my computer (I started it on XP with a dual core 2.5Gh and finished it on win7 with a quad core 3.5Ghz).

I guess if you really push it you will hit limitations, but hard to precisely tell you "you can do up to X collision at the second" for now 'cause it sounds it depends so much on the gear/OS/browsers/etc...

As you said, at worse you can always do "simpler" thing with C2 it is not totaly wasted money.

Keep us informed about your experimentations/results <img src="smileys/smiley1.gif" border="0" align="middle">

Also moved to the SDK forum, it is less likely to drown answerless.

Armitage1982, I'm not sure what your question was from your last post. Could you clarify what you were asking?

Javascript can be coded in an object oriented style if you choose, just because the language doesn't have the keyword 'class' doesn't mean you can't. And I already mentioned javascript is compiled to machine code these days so is pretty fast, although obviously not as good as C++. Performance varies depending on your machine and browser so you should just try stuff out to see if it's fast enough for your purposes.

I will !

Thanks for the replies.

I guess it all depends on the project. But if Construct 2 deliver his promesses then it will be a nice tool for fast prototyping and handy to quickly publish/update research on a game.

The physics demo you send me Kyatric is working smoothly too so who knows...

Box2d only compute things, actually you can use it without the need of any rendering stuff, so it will go as fast as the javascript engine goes. But it's always possible to create a huge array of games without relying on physics engine, so like you are saying it's not waisted money at all (and certainly not for that price). I can also probably learn a few things from C2 plugins source code too :)

As far as you keep a little room for the developer side of game making and avoid locking everything with too much UI tools, you can only enlarge your experienced users base (not that I am experienced at all but many have a rude approach of game maker tools. They think they can do everything... Yes but in 4 years ^^).

Thanks again, keep up good work ;)

I'm nearly sure that I will have at least 50 or 100 collisions points to proceed each frames which is CPU intensive.

Umm... I am pretty sure somewhere in C2 I read that no more than 8 collisions points are recommended? And you want 50 to 100??? Am I misunderstanding what he is saying? O .o

—: With the built-in behavior, the way things are coded yes, it's better to stick to 8 points.

Ashley had to code the physics behavior so it can be widely used, in many cases.

He had to make decisions to manage this.

But Armitage said he wanted to develop his own plugin based on box2D. So after all, maybe a specific implementation may help raising the possible number.

A plugin specificaly coded for a game could handle only issues of said-game.

I think in theory that makes it possible.

Now to see it actualy done is yet to be seen.

—: With the built-in behavior, the way things are coded yes, it's better to stick to 8 points.

Ashley had to code the physics behavior so it can be widely used, in many cases.

He had to make decisions to manage this.

But Armitage said he wanted to develop his own plugin based on box2D. So after all, maybe a specific implementation may help raising the possible number.

A plugin specificaly coded for a game could handle only issues of said-game.

I think in theory that makes it possible.

Now to see it actualy done is yet to be seen.

I see, so I did misunderstand. So, in the case that I need a bit more than 8 points, how many points it's a bad idea?

It really depends on the context of the contact point.

Let's make the distinction between the maximum collision pairs Box2d can handle and the maximum proxies (objects) you can spawn in a single world.

By default the only 8 limit number I remember to see in Box2d was the maximum number of polygon vertices a shape could have... Which is probably enough considering you can build complex object from many shapes.

If I do recall correctly the maximum default number of object you can spawn in box2d was 1024 but you can easily push this up to 2048 without any slowdown. That's what I did in my engine because I'm using the edge shapes that generate a lot of proxies. Actually if the physical engine is a key feature of your game you will easily reach that given limitation but since Box2d is only about processing data, it's not a real problem (you would probably have to focus way more on the rendering part).

The pair number is 8 * proxies by default. If you go over this default number, Box2D throw an exception (that I guess Construct 2 handle to avoid any crash ?).

Maybe the suggestion of 8 collisions point per objects comes from this factor ? That would simply mean that 1024 object can have safely up to 8 collisions points at the same times. Hopefully this will probably never happen !

The contact point is something you handle on your own, personally I store them in a pool and use them to process specific collision.

But trust me, there is many situation where an object will generate more than 8 collisions at time (for example 10 balls on the ground :).

So except if the Construct 2 Team did some weird optimizations in that area (why ?) you probably don't have to "count" the number of contact point your game will have to handle at max but rather know how many object can be displayed at the same times, if you really need that much and finally if you can group them in various Bit Mask to avoid as much as collision and awaken object in your simulation.