Layers still exist in the scope of game logic. Turning off a layer does not exclude logic processing, collision etc.

Layers should be used for visual distinction and parallaxing

Layout should be used for gameplay distinction.

Major screen changes

different levels

I think you should aim to have 5 animation frames per second. Or aim to have 5 frames for any particular animation. Otherwise I suggest using Spriter. A lot of games are made in a less than 10 frames per animation constraint. Most games even when they run at 30/60fps don't actually have 30/60 frames. They often range from 3 to 12 per animation. 3 for quick animations and 12 for really smooth animations, but those smooth ones are aimed at very few objects on the screen.

Otherwise I suggest Spriter.

Now that I understand your art a little more I can see the desire to maintain a higher quality retro style. good luck. There is a colour plugin you can try. It shifts specified colours to a different range. May or may not have a range level to it to effect close colours. may be one of Podes plugins.

Alright here is our entry into the Ludum Dare 32. We spent about 16hrs on the project. More of the fun of it rather than anything else <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

http://ludumdare.com/compo/ludum-dare-3 ... &uid=52614

newt is suggesting using a webgl shader. If you used a shader to change the colour you can avoid the impact of extra colour changed versions of your sprite.

Can I ask. What is the resolution of your character. I can imagine 16x16 based character sprites running at 200+ frames. But I can't image much larger using 200+ frames. I can barely think of any games that need so many animations. And the few that I do know tend to very limited graphicially. Such as fighting games which are just 2 characters and a background set pieces.

So you have a sample of what needs 200+ frames.

If I may suggest. Use Dictionary for active data. And save the JSON to local storage at reasonable increment times. Then you only need to load data from local storage at the beginning of the game. You will also have access to the standard data check features.

As everyone said C2 is built to run at 60fps. dt should in theory cope for dropped frames. However that does not seem to be the case.

I linked to a article that was about fixing the dt and putting the game to 30fps. The theory runs on the idea that the engine loops as fast as possible. The game also tracks the dt difference. however logic only updates every 30fps. So even if the game dips below 60fps the logic already at 30fps anyways so you will never see the dip. however as always. it's not 60fps so there is no value in the design choice.

I realized today that there is nothing wrong with the way the new storage is.

Just use Dictionary for your data. When you want to save long term use the new LocalStorage. When loading use a splash screen and when it's loaded from local storage into dictionary your all good. Honestly this is how I do saving loading in Java/C++/Unity anyways.

I agree with Rex. When I suggested a model to deal with the change for Android and to switch over to a memory management similar to AJAX triggers. I suggested a cache. I still suggest a cache.

Since session is removed as it does seem redundant. Why not offer Cache storage as part of LocalStorage. When using cache storage there is always a running memory copy that is like a dictionary and behaves just like webstorage. Cache storage is loaded at the beginning of the app and regularly writes to storage location. So now you get the benefit of the immediate old style, but deals with work around of using the DB styles. This then means you don't need "Then" as a follow up.

Also add save frequency based on how often the cache should save. A sample would be "Data Change, LayoutEnd, Once a Minute, Never". Then also have an option to "save cache".

So now you get the best of both worlds. high memory data should not be in cache. where as small memory data would be.

http://en.wikipedia.org/wiki/Duff's_device

https://jsperf.com/duffs-device

The current loop is

foreach Object, then foreach behaviour.

And it's not the best way. As previously addressed the CPU optimization is similar to a GPU optmization in concept. Handling the same code in scope in chunks allows for better optimization and performance. Running through a ForEach(object) then ForEach(Behaviour) results in the object at the top. So the loop starts with object, then goes to the first behaviour, however since all following behaviours are never the same the CPU never optimizes as well as saying just handling all the same behaviours at once. As for ignoring Duff's device. I would do so in non game programming, but in game engine programming. It's all about finding optimal performance. Games are intensive and there is no reason not to take advantage of any and all coding tricks.

Unless your relying on IRQ, all listeners are still based on loop. An event happens, then the event loops through the listener firing off the event. In this case everything. Which as you point out would be chaotic. Since this would be a chaotic loop that would result in little to no optimization of runtime.

As for parallel loops, this might as well call it threading. In this case that would be done with a webworker. This is doable, but the this comes down to managing effective data transfer between the different threads with no conflict. I would love to see threading implemented in a game loop, but since memory needs to be transfered. I'm not entirely sure if the memory moving would save on time. It could do so in large memory batches.

on a note. I did forget to write that there is a post and pretick loops. Which also again would take advantage to scope cache in a DuffDevice.

I like the idea of clicking on a function. which then take you to the defintion. That's good <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

I wrote this as an update to the document draft. However I think this could improve game performance overall going forward.

https://docs.google.com/document/d/1pNR ... ZGe8/edit#

it's better formatted at google docs

Engine Runtime Code execution

Having spent some more time in the main game loop and ways to take advantange of memory, cache optimization for Duff’s Device(below) has led to a different suggestion. The current design of C2 main game loop for objects is

Current Loop

loop through all objects types

loop through instances of Object type

do object pre tick

do update

loop through behaviours

execute behaviour update

do object post tick

This is the actual loop. The loop is repeated twice.

for (i = 0, leni = this.types_by_index.length; i < leni; i++)

{

type = this.types_by_index;

if (type.is_family || (!type.behaviors.length && !type.families.length))

continue;

for (j = 0, lenj = type.instances.length; j < lenj; j++)

{

inst = type.instances[j];

for (k = 0, lenk = inst.behavior_insts.length; k < lenk; k++)

{

inst.behavior_insts[k].tick();

}

}

}

for (i = 0, leni = this.types_by_index.length; i < leni; i++)

{

type = this.types_by_index;

if (type.is_family || (!type.behaviors.length && !type.families.length))

continue; // type doesn't have any behaviors

for (j = 0, lenj = type.instances.length; j < lenj; j++)

{

inst = type.instances[j];

for (k = 0, lenk = inst.behavior_insts.length; k < lenk; k++)

{

binst = inst.behavior_insts[k];

if (binst.posttick)

binst.posttick();

}

}

}

In the above loop the loop is jumps into a multi embedded function. because the loop goes down, then back up the system is constantly clearing cache for a new behaviour, then going back to the behaviour for the next instance. There is little opportunity for the JIT to truly optimize cpu cache for both function variable cache, or object function cache.(as related to Duff’s device). As an analogy GPU/WebGL/GPU in general. Part of efficient rendering is to package sprites together on a texture. That way there is less swapping textures, which reduces memory transfer to the gpu cache, less draw calls and overall way better performance. Which C2 already works towards. however the CPU also benefits from caching code, and memory variable(as Duff Device below) significantly.

I propose a loop that the CPU can take advantage of code/behaviour batching which can improve JIT optimization at runtime. Less deep than above, and also offers the awesome feature of priority behaviour control. this of course still works off the basic idea of world object and everything is a behaviour.

Proposed loop

loop through different behaviours

loop through all of the same behaviour on all objects

execute behavior update

How does this work instead.

This loop does not loop through Objects.

This loop does not go through behaviors in an object

This has the behavior at the top, and then manipulates it’s world object

There is a BehaviourList. this list contains a BehaviourInstanceArray. And the array contains a reference to each and every instance of the behavior.

abstract sample below

BList[ Sprite[]

Collision[]

Platform[]

Solid[]

Pin[]

]

When an object is created, the code adds the behavior instance to the array. When the object is destroyed then the behavior is removed from the array. This also means that the CPU can cache the update function and run through them all in one go. Doing so offers the benefit of Duff below. However the system also offers another benefit.

Sort-able behavior execution. The above sample shows Sprite at the top, and Pin at the bottom. however this list can be sorted. Offering control as to what should be executed first to last.

So the loop is

for(int i = 0, int length = blist.length; i < length; i++)

{

var bInstList = blist[ i ];

var n = iterations % 8;

while (n--) {

bInstList[ n ].tick();

}

n = (iterations * 0.125) ^ 0;

while (n--) {

bInstList[ n - 0 ].tick();

bInstList[ n - 1 ].tick();

bInstList[ n - 2 ].tick();

bInstList[ n - 3 ].tick();

bInstList[ n - 4 ].tick();

bInstList[ n - 5 ].tick();

bInstList[ n - 6 ].tick();

bInstList[ n - 7 ].tick();

}

}

So here is the game loop. Takes advantage CPU caching. Far simpler in design. Allows for Behavior execution order. So instead of Object top down, It’s behavior top down. There are probably other optimization techniques that can be applied.

Don't use per animation frame colliders. Each collider on a different frame will Trigger the collision again.