I'm making a JavaScript game engine for fun and one thing I noticed was that my laptop runs super hot with the simplest game mechanics and that my game is doing about 600 updates per second.
The graphics is already capped at 60 fps, but I'm wondering if I should limit the update cycles so my processor doesn't get owned on the simplest games.
I think the answer is yes, it is just that I've never heard of anyone doing this before, so I wanted others opinions.
You may want to look at some of the common javascript game loop patterns that exist. Most folks use a timer to schedule the game loop. This resource is excellent: http://codeofrob.com/archive/2011/03/17/a-javascript-game-loop-for-multiplayer-webgl.aspx
If your game isn't multiplayer you can likely use what the author calls "another naive game loop".
600 updates per second is far too much for any game I can think of. Some games require a very intensive update rate, but most of the games can do all they need to be done, with a 25-30 update rate per second. (We speak about the game state updates, not about the display updates)
There is different methods to limit the number of game state update per second... and as Koen Witters wrote a very interesting, clear and simple paper on this question I recommend you the following article ( http://www.koonsolo.com/news/dewitters-gameloop/ ) instead of trying to explain myself the same ideas with my approximative English ;)
This paper will present you four approaches of game loops, and for each one it will expose the pros, the cons and explain how it can be done.
