Qix game logic

I am struggling to make game like Qix. I am using VectorLine. I am stuck at a point. I want to detect when lines get close they form a different mesh and player should follow the most enclosed circle.

Please help!!

 

Qix is tricky. The original game was made on a raster. Essentially the minimum distance to move was two pixels, so you could at most enclose a 1x1 pixel piece of color, with a 3x3 pixel bounding box.

I think the follow logic was probably just walking along and looking left/right to make sure you didn't bury yourself into an extant area that was filled, causing you follow the inner black container. I think it just used white to indicate the walkable area, black to indicate the "leap off and make fresh line" area, etc.

Also, as you leaped off, it obviously tracked each pixel you went along because if you paused while off drawing a line, it would spawn a "sparx" behind you and burn down your line and get you.

As far as floodfill, if I recall it test-flood-filled both sides and if it found the Qix, then it would floodfill the other side. If it found Qix on both sides of your new line then you split the Qix and that was a way to finish certain levels.

I'm not really sure how you would replicate it easily with ad-hoc verts and lines. I'd still honestly keep a raster underlying logic matrix (not displayed to the user) in order to floodfill and figure out where you can and cannot go. Then you can make a vert/polygon based display system based on how the player fils the underlying raster.

 

Thanks for quick reply. Let me explain you what logic I am build. I am using VectorLinehttps://www.assetstore.unity3d.com/en/#!/content/82 for creating the scene.

First of all I created a square and define then as "solid line". Create a cube and make it follow the solid line. I player press any key from "up" , "down" , "left" and "right" , I stop cube to follow solid line and Cube will follow the instruction and creating new line "Current Line" behind that.

if "current line" touch "solid line" , it means a closed loop is created and add those line to "solid line". but still struggling to make cube follow on new lines and shading/calculated the percentage of the area covered is another bottleneck.

I calculated top-left and bottom right points of rectangle to be formed. I done this by storing all the turning points in a list.

I am in process of developing the algorithm. I know there is long way to go.

 

This. Ultimately this game is much, much simpler if you consider the underlying playing field as a rectangular array. In this case modern tech just gets in the way.

 

I am not getting you.

 

Basically you split the game up into a massive grid. The player can only move along the grid. Then you can simply check the colour of the grid to figure out what sort of territory you are on, and you can fill in completed spots with a simple flood fill.

 

That's a really good idea, but can you help me in moving a gameobject on particular tiles i.e they should move only on Grid.

 

When I use a grid I normally lerp between the two grid positions. That way you get smooth, exact movement.

 

But that will give a lag, because I need to constantly check the position. @BoredMormon

 

On the grid, the movement (at least in the underlying data structure) will be instantaneous in fixed integer positions.

How you visualize the movement is another story, I.e you could lerp like @BoredMormon suggested, have a trail, fade, etc.

 

Stop trying to optimize before you've even built the prototype. Constantly checking your position should have no measurable difference on performance. Remember the original game had to do it and it was able to do so on a processor that was easily hundreds if not thousands of times slower than any modern mobile chip.

 

You guys are right!! I implemented it.

Any idea how should I colour the close area.

 

Google flood fill algorithm, and combine it with SetPixels. And you are good to go.

 

I don't know the game but based on the first video, I have the feeling an approach could be:

1. Determine which area to fill (it seems to be the smaller one) - this check needs to happen whenever the player returns back to the border of an already filled area (basically the frame + all the filled cells have the attribute border)
2. Fill the respective area - not sure if you need a typical flood fill (seems good enough to store all the points at which a directional change happened and then you can fill a couple of rectangles along the path)

 

And its Done!! Thanks @BoredMormon @sngdan for your valueable inputs.