Forums » Everything else » new to Impact, how large can games be?

I just purchased a license for Impact to develop some games. I'll eventually build them to distribute on iOS. I don't have any Javascript experience (but I've coded in Java and some Objective-C).

One thing that isn't clear to me is how big can Impact games be? I'm not necessarily thinking in terms of file sizes, but more in the size and length of the game (game world).

For instance, would it be feasible to build a game the size of Super Mario Bros. or The Legend of Zelda?

Thanks and I look forward to being part of the community here.

No-one's pushed the boundaries to see how far they can go, really.

That said, there is a direct correlation between the limit and practicality of file sizes - when publishing a 'build' for the web, the standard bake script combines all files into a single JS resource file. The size of that will naturally limit how big things can get.

If you're a bit more careful about coding and free up resources once you're done with them there's absolutely no reason why a suitably large game can't be written - but it'll need a bit of careful code not to just dump everything on the browser up front.

Honestly, though, Biolab Disaster (which is the main demo game for Impact) is a sizeable enough little platformer with only 3 levels, clocks in at 47KB or so of JS (plus all the images and sounds separately) and doesn't seem to consume absolutely vast amounts of browser resource, so I'd imagine that the limit is quite a way off, very likely beyond the limits of what you're thinking about.

Can you say something about "free up resources once you're done with them"?

I hadn't thought about the need to do anything special in code to free up resources. Could be a gold mine of optimization that I'm missing.

Thanks for any clues.

You don't have to worry about garbage collection with javascript (although it would be nice if we had more control over it) but you can be careful about what you are loading to memory.

I think what he means is don't load everything all at once and keep it in memory. If you are done with a level or whatever then null out the variable that was holding it... stuff like that.

There is also the whole concept of loading in blocks/sections of the entire map. I've toyed with this in the past with good results... but its all very custom. Then you are pulling in information much like Google Maps or something does where it only loads areas around you and when you get close to the edge it loads more (and cleans up other blocks). With this your level size could be infinity large.

That's exactly what I meant. The stock bake script builds everything into a single JS file that will be loaded at once.

Take Biolab Disaster. The levels are 256x20 and 256x40 tiles (with another layer for collision data) and just the three levels, without images, makes up some 130KB. Going "bigger" will likely see the larger files be needed in memory at all times, which might not be too lightweight.

There is also a plugin/utility to compress level sizes.

http://impactjs.com/forums/code/map-minifier-plugin-for-level-data-compression

That saves thehysical transit but not the overhead in the browser memory where it gets held.

Very true, in fact it adds overhead. ;) All depends on what you feel needs optimized.

I'm glad to get all the answers I did. This thread has been very helpful so far.