Problem Description

Top/bottom collision between a falling player controlled object (Platform behaviour) and a static Solid object consistently does not trigger when the Solid object is at a very specific location

Attach a Capx

Minimal capx with only 3 object types and 5 instances :

https://dl.dropboxusercontent.com/u/526 ... onBug.capx

Description of Capx

Minimal sample scene : 1 ground, 1 player, 3 blocks

• brown = static Solid used as ground
• yellow block = player controlled, uses the default Platform behaviour
• red block = static Solid (could be an enemy, a platform, etc.) to demonstrate the bug

Logic is simplistic : flash the player object (1second) when an Enemy/Player collision is triggered

Steps to Reproduce Bug

• Move right and jump on the first block (#1) ; notice a collision is triggered and the player object flashes as expected
• Wait for the flash to stop
• Jump right onto the next block (#2) ; notice the player object doesn't flash as a collision is NOT triggered
• Jump right onto the last block (#3) ; notice a collision is triggered and the player object flashes as expected
• In the editor, move red block #2 (the one not triggering the collision) up or down a bit ; test again, this time it does trigger the collision properly

Also notice that collisions from the sides (left/right) or from below (player jumping into red block #2 from below) always work consistently

This unexpected "falling/top collision" behaviour only happens when a red block is at y=524 ; there are other specific y values showing the problem as well but I believe they are all instances of the same issue

Observed Result

Collisions are not triggered consistently depending on the position of the objects

Expected Result

Collisions should be triggered consistently regardless of the positions of the obects

Affected Browsers

• Chrome: YES
• FireFox: ? (don't have)
• Internet Explorer: ? (don't have)

Opera: YES

Edge: YES

Operating System and Service Pack

Windows 10 Pro 64b

Construct 2 Version ID

212.2 64b Steam

Edit: updated affected browsers

Very limiting indeed, though it's unlikely to change ; from the manual :

"Limitations

Unfortunately due to the architecture of the Construct 2 engine, breakpoints cannot be placed in the following locations:

• Anywhere inside a triggered event, including any sub-events to a triggered event
• Anywhere inside a looping event (such as Repeat or For each), including any sub-events to a looping event

In other words, only non-looping events which are checked every tick can have breakpoints set on them, or be stepped in to."

Something to consider for C3

It is to do with the nature and architecture of every engine, they all have their limitations. You can still use the JavaScript console of your browser if you know your way around it, and revert back to "old" debugging techniques such as outputting infos to a debug log / array / xml / etc. that you can inspect

As for performance, it is expected with any tool or language that debugging will impact performance negatively ; simply due to the overhead of the debugging itself.

If I understand the problem correctly, this seems to be typically what is referred to as "tunnelling", i.e. solid objects moving at relative high speed going through each other.

This can happen if the size and speed of Bob and Bar, and the framerate, are in a configuration when at frame n Bob is totally above the bar, and at frame n+1 bob is totally below Bar ; in this situation, Bob and Bar are never really in collision, since they move too much in one single frame

The usual solutions are time slicing (moving multiple times in smaller increments in one frame) and continuous collision detection (CCD, using swept volumes), though I'm not sure how you would solve this in C2...

You might try using a bigger hitbox to detect possible tunnelling, and then the accurate hitbox, in case of possible condition

I haven't used it myself, but you can try GreenWorks :

And congratulations on getting a game greenlit

>

> Unity is pretty easy too, especially with playmaker

>

As far as I know Unity doesn't use the node system for programming, you can only do that with 3rd party plugins

Well that's exactly what PlayMaker, mentioned above, does ; visual scripting

I think this would be a bit restrictive, in the sense we would lose some flexibility ; the layer system means we can split and mix & match bits of global layers the way we want, so that we can "include" relevant bits of gui/inventory/options depending on the context / levels / etc. To keep this functionality, we would still need a place to define what to include/display in each layer, which would make "automatic" global layers clunky

Technology did speed things up - the productivity has significantly increased. It's now possible with very limited knowledge, resources and time to create games that would have taken teams of experts years in the past. Think Super Mario on the NES ; it's now possible for a single person to create something better using modern software. Of course this example is a bit extreme and we usually want to do "more", but this in itself proves things are moving forward.

If stability is the key, focus on mature platforms and technologies ; though while this mitigates the risk of "innovation" this also adds the risk of "obsolescence"

No "power of 2" "magic" involved here ; it's just pixel rounding, which does exactly what it says.

As for n^2, it works "better" since content designed to work in n^2 can easily be accessed with data encoded on 8/16/32/64 bits, which are native data types, without waste, memory alignment or performance issues

Nowadays 2D applications are handled as a special case and subset of 3D to benefit from hardware acceleration (using pre-transformed vertices, etc.) ; sprites are textured quads, and so on.

This makes handling 2D, 2.5D and 3D games very similar, in terms of internal resources (vertex buffers, textures, etc.).

As with any application, it's up to the user to set the rendering settings correctly to achieve the desired style (filtering, scaling, sampling, etc.). Pixel art (e.g. sharp blocky style) is not "more" difficult in any tool, it just requires the appropriate settings.

It's like cell shading in 3D ; the scene is the same as a traditional 3D scene, but the samplers and shaders are different.

Hi -

1. You export a project as HTML5, which actually is (HTML 5 + CSS + Javascript) ; publishing to web sites is trivial, but it's also a very portable technology, so with a few additional exporting steps, plugins and wrappers you can get your HTML5 game to work "as" a desktop application (wrapped in "simplified" browser/renderer that presents itself as a normal window to the user) or mobile application.

As long as your target platform can process HTML5 content, it's all good ; this includes Windows/MacOS/Android/iOS/WiiU. Note that depending on the platform, the export process might not be trivial, and sometimes you have to fiddle with 3rd party development tools.

2. Java is not Javascript. Javascript is light weight and browsers are very efficient at processing it. The language will not be a limiting factor ; knowing the platform, understanding performance and dealing with restrictions (resources sizes, etc.) will be essential though ; it's very easy to create very inefficient content even with very efficient technology.

Also, big companies are investing massively on Javascript these days ; Google are going with native compilers and javascript subsets focused on performance, while Microsoft is going with TypeScript, a superset that compiles to javascript to facilitate the job of programmers. All in all, while that won't affect you directly, it means in the long run it's a pretty safe bet.

3. Yes

4. Nothing comes to mind ; other interesting technologies are either lower level (frameworks for programmers), more complex (e.g. Unity, with a much steeper learning curve), or slightly dated. C2 is the right balance in terms of functionalities/accessibility and has incredible productivity. Just be aware that "events" are very similar to "programming" in terms of logic ; it removes a lot of the complexity but you'll still need to understand how to create your gameplay logic. For "big" projects, a "programmer mind" can help to structure the events in a maintainable way.

Hope that helps

You still get all the hardware acceleration via wrappers like WebGL, popular libs use instruction sets that map nicely to low-level concepts (simd for physics, etc.) and so on. HTML5 (html/css/js + wrapper + apis + libs) is not responsible for bad performance.

Native and platform specific optimisations always come last in terms of cost/benefit ratio ; there's usually a lot to be gained from higher level optimisations first (resource management, entity lifecycles, naive algorithms and sub-optimal logic, etc.)

So I'm not too sure what the problem is If you're targeting only one specific platform and want the absolute best performance (at the cost of iteration time, design time, prototyping time, etc.) why bother with high-level tools at all, and why not go low level in the first place ?

Thanks to the people who took the time to read the document and provide feedback ; I will try to improve the guide with the various suggestions I received.