Anyone use Crafty or HTML 5? by angela

Anyone use Crafty or HTML 5?

[raw] LD26MiniLD 16. Jul 2013 · 22:05 UTC · 81 days after compo start by angela · 0

Hey everyone! I’m working on my first real game called Binge! and it’s almost finished. I’m just trying to work out a few bugs and I could use a little help with understanding how the browser handles resources with the Crafty engine. I use faucets and pipes to shoot streams of water around the screen that create barriers that block the avatar. The avatar is supposed to solve puzzles to get around them. It works great with just one or two faucets in a level. However, if I have more than a few of these faucets on the screen everything starts to really slow down. This causes the water droplets to spawn unevenly, with lots of space between some of them that the avatar can just walk right though.

Any advice on what is causing the slow down (too many things to draw on screen? too much memory used? too many entities trying to create simultaneously?)

The faucet entities call a component that has a timeout function that calls itself every 100 ms. The timeout function creates a water droplet entity that switches directions when it hits a pipe, and destroys itself when it goes off screen. The water droplet entity has a component that blocks the avatar from passing through it. Any better way to do this?

Thanks!

Comments

jhinebaugh

17. Jul 2013 · 15:02 UTC

I’ve only barely dabbled in Crafty, but I have some generic javascript advice that may apply.

18. Jul 2013 · 06:03 UTC

you can also try using the javascript profilier that is built into google chrome. It will tell you which functions are chewing up the most time, and give you call stacks for them.

18. Jul 2013 · 17:16 UTC

Thanks I’ll give both of those a try. I’d never used Javascript before, I just learned it for this project. I’m using Crafty.timeout which is built on Javascripts’ setTimeout, I think. I’ll see if I can figure out how to make it work with setInterval instead. Thanks for you help

Fritzendugan

19. Jul 2013 · 00:48 UTC

I’d recommend, in wherever your update loop is, to track the time since the last update. If the time since the last update is longer than some critical period, only process that much time in the game simulation rather than actual elapsed time. This will cause the screen to be really “laggy” at times of critical lag, but will prevent the scenario you’re describing (where there are large gaps between droplets and the player can go through them).