Hey thanks for testing some more. I agree it may be a bit on the hard side. I was considering having "easy" mode with zero enemies in the filled area to avoid instead of one, and "normal" having one instead of two, and "hard" having two instead of three.... but maybe this makes easy mode a little too easy. I'll try it and see.
The other option is to reduce the physics tick slightly. I think it's at 50 ticks per second currently. I could reduce that a bit I guess which will make it easier. Can this be done on the fly in the game easily enough? Or is it a fixed thing in the project settings only?
The way the filling works is as follows:
The level is stored as a grid[y][x] multidimensional array (160x112 or something, with 2x2 on-screen pixels per grid cell). In basic terms, each cell in the grid is stored as a 0 for unfilled, and 1 for filled.
I have a function that (re)generates polygon2d rects from the grid that I call whenever an area is filled (or the level starts), and that is how the screen is updated. It tries to generate as few rects as possible from the filled grid cells.
For filling, when the player has finished drawing the trail, and meets the filled area again, I trace along both sides of the trail from start to finish, logging all unfilled cells touching the trail edge where the previous touching edge cell was either another trail cell or an already filled cell. This generates a list of potential seed-cells on each side of the trail. For each seed-cell I send it to my scan-line flood-fill function that operates on a grid array. I do this first in a temp/mock grid array (a copy of the real grid array), and when that's flood-filled I check if any enemies are in the newly filled area. If they are not, I do the same flood-fill (for that seed cell) on the real grid. Then at the end I call the function to regenerate the polygon2d's.
There's a little bit more to it than that, but that's basically how it works.
I'll go check out the new Hop!2D beta!
