Um .. no, not really. There's nothing preventing the engine from handling multiple screens and scrolling. The algorithm isn't based on having only a low number of objects to consider or compare. It uses a brute force rendering method where adding another object simple merges it with the existing blob field perfectly, so it doesn't matter where the blobs are or how many. I am intending, at least for now, to have it be multi-screen and scrolling, maybe it could even be wraparound scrolling aka defender games, in both directions. Since the display is being generated in its entirity each frame there is no difficulty having to try to split rendering operations into 4 parts or whatever - the coords would be worked out relative to the screen and if its visible it gets drawn in one go.
There can also be many different types of blob effect (two shown above) at the same time, it doesn't have to be all one kind. The only thing I have to bare in mind is the amount of videoram it consumes. I am expecting the engine to be *at least* a multidirectional scrolling engine. And heck, maybe I'll even come up with some kind of multidimensional scroll that lets you go in and out of the screen too. It could be fully zooming in realtime with not much extra overhead - ie zoom out when two players get further apart - except I have another idea for a dynamic splitscreen in that case.
Also since the gfx are generated in realtime there isn't any need to use a lot of ram to store a `map` as such, like there would be with a superbitmap, so levels could technically be huge. I don't know about `progress`, that hasn't been designed/designed yet. Ideas? I thought maybe that the energy fields had to be `balanced` or something in order to ascend to the next level. Since we have this whole idea of blobs, it'd be nice if levels could merge into each other in some kind of blob-like way, too.
There can also be many different types of blob effect (two shown above) at the same time, it doesn't have to be all one kind. The only thing I have to bare in mind is the amount of videoram it consumes. I am expecting the engine to be *at least* a multidirectional scrolling engine. And heck, maybe I'll even come up with some kind of multidimensional scroll that lets you go in and out of the screen too. It could be fully zooming in realtime with not much extra overhead - ie zoom out when two players get further apart - except I have another idea for a dynamic splitscreen in that case.
Also since the gfx are generated in realtime there isn't any need to use a lot of ram to store a `map` as such, like there would be with a superbitmap, so levels could technically be huge. I don't know about `progress`, that hasn't been designed/designed yet. Ideas? I thought maybe that the energy fields had to be `balanced` or something in order to ascend to the next level. Since we have this whole idea of blobs, it'd be nice if levels could merge into each other in some kind of blob-like way, too.