Game slowing down to crash??

#1 Slowdowns can be caused by several factors

If your behavior is updated very often (each tick or frame for example) and performs complex operations each time it is updated, it will slow down the engine.

If I understood your post correctly, you say that your game slows down over time. This often happens when you fire off a lot of 'schedules'. i.e. you schedule a function "FunctionB". At the end of "FunctionB" you set a new schedule to call "FunctionB" in x milliseconds.

If you were to call "FunctionB" outside of the schedule (through an input event, for example), then the schedule calls would be doubled, tripled, and so on, until the game slows down to a crawl and crashes.

Look at your console.log file (in your project's root folder) to see if there are any errors or warnings.

It is also very hard to give you a precise answer as the problem itself is not clearly defined. Providing more precise details would probably help others track down the issue you are experiencing.

#2 I'm with Simon on this one - if you recently started adding more schedule calls then that's probably where your problem is. And just for informational purposes, try to ensure that all calls to schedule use a time greater than 32ms - anything smaller is pointless (because the tick duration is 32ms) and can sometimes cause crashes.

#3 Thanks for taking time to reply.. Actually, im not scheduling too much...there are at max schedule at 4 different places...they mostly used to switch animations in the apt time...there is only one place where im recursively schedule calling a function say 6- 7 times....nothing complex in them and they worked fine till now...

What i'm beginning to doubt is (sounds stupid but still) whether scripting one long behavior with too many fields and functions or a datablock with too many references may be the cause...can it??

#4 Hasn't happened yet, and we've built some fairly large behaviors. However, it is a good design practice to try to ensure that a behavior encompasses a discrete, er, behavior. So, for an enemy you might have several behaviors; one TakesDamage behavior, one TargetPlayer behavior, one SeekPowerUp behavior, etc. instead of trying to gob all of that into one giant EnemyBehavior. This way each is easily independently testable and you can re-use them - perhaps for an obstacle that can take damage.

As another example, the Three Step Studio Tower Defense projectiles each used 16 (maybe 17) different behaviors to allow for different projectile types, to handle switching animations and sound effects, and to deal with the various states the projectile could be in.

#5 Or you may have used too many setPosition methods, and/or calling them frequently,

#6 One thing to check out, if you look at your game running with task manager - is it eating up more and more memory until it crashes? It could be something isn't getting deleted properly or some other memory leak.