Forums » Impact Engine » Thinking of buying..

...but it's difficult to evaluate since you can't get any kind of demo. I wonder if anyone can answer a couple of questions for me.

Is it possible to have more than one entity layer in the engine, and does the level editor support this. I have an idea for a game which will require some entities to live on one layer and some to live on a layer in front.

Secondly, I realise this may be hard to quantify, but are there any statistics available on engine performance, for example is it realistic to have fifty entities with collision detection, five thousand, five million?

Thanks, G!

Also, is there any way to use a cross-compiler to generate impactjs code?

You can't directly use more than one layer, though to be honest I'm finding it hard to imagine a genuine scenario where you would actually need it. That said, entities can have a zIndex for layering purposes.

Without knowing your use case it's hard to say for sure, but I'm going to go out on a limb and say the second layer of entities is GUI? I personally never bother creating entities for GUI items, solely because I can save processing by not making them entities.

This brings me on to your second point. Performance is relative. Entities overall are not a huge vast drain on resources, in the scheme of things. But having fifty entities with collision is fine, I've done into the hundreds without any significant problems.

The problem with collisions is that every entity gets updated every frame, and there's cross-notification of collisions where the types are set up as such (you notionally define 'type A' and 'type B' entities, where type A is usually the player, type B is usually the enemy and you define behaviours between them, so that things that are arbitrary have their own type which is excluded for collision purposes)

However there is still overhead attached, and again without knowing the use case (desktop? mobile?) it's hard to say whether you're going to run into problems.

What is certainly the case is that drawing invariably takes up a lot more effort than updating entities, doubly so on mobile. Drawing is where you can really save on performance issues, barring any really nasty computational issues. For example if you have a ton of entities all doing A* pathfinding, that's going to be a bigger killer than drawing them all.

The real test is what your use case is, anything else is purely speculative and general.

As for using a cross compiler, to what end exactly? I'm guessing you're going to say CoffeeScript at that point to build JS... honestly, don't. It's not worth the effort in making it play nicely with Impact since Impact does non-traditional things in JS like creating a proper object orientated structure to work with (unlike JS' normal behaviour of what feels like orchestrated madness)

Thanks for the very thorough answer!

The two layers do not include GUI. The idea I had is a kind of puzzle. The player is in front and moves around platforms to get to the different parts of the puzzle. Behind this is a second layer of platforms that entities move around, this is the puzzle itself. (Hope that made sense).

In terms of use case, I'm primarily interested in a web based application, but would be interested in making it work on mobile too. The large number of entities will be on the back layer and will work a bit like Lemmings. The 'lemmings' need to collision detect with each other, for instance to detect that the one in front has stopped. I was wondering whether having so many entities in close proximity would be a problem.

In terms of cross compiling, I was hoping to use a statically/strongly typed language such as Java, which would compile to minified js (which is essentially machine code for the browser). Using straight js wouldn't be a deal breaker though, if it's going to be much more straight forward than trying to get cross compiling working. I agree using a good object-oriented framework does make js a bit more bearable :D

Thanks again!

Proximity of elements is not really a huge deal, simply the number of them is. There is a process whereby it quickly goes through the entities to figure out which ones are within a given zone of proximity to others and then manually compares those.

On mobile, as a rule, I'd keep it to no more than 100 entities, simply because those 100 entities are going to translate to 100 draw calls, which is definitely stretching the capability of the canvas on most mobile devices.

Also, the player will be an entity themselves... but I'm not sure I understand the use case well enough to understand whether what you're really dealing with is entities or some kind of collision map in the level editor, or both, potentially.

Oh, and no, minified JS is not 'essentially machine code for the browser'. Minified JS is handled exactly the same way regular JS is - the difference is that there is a reduction in bandwidth use... there is definitely a space saving but from a performance standpoint the difference is marginal at best and negligible at worst. There are arguments that it making parsing faster (by a fraction of a percent of parse time, possibly) and that it makes runtime faster by having smaller variable names (unlikely, the performance of the hashmaps used in the different JS engines means you're not talking about linear increases in speed relative to reduced variable names)