Tile Computing

Programming
1

So I’ve got a proposal I want to discuss with the other programmers, @crovea, @Moopli.

Currently, the in-game spawn system draws a circle around the microbe every frame and sees if the circle moved from the last frame. It then despawns entities that were part of the old circle and not part of the new one and adds additional entities (such as compounds and other cells). In my opinion, this is unintuitive and wastes processing time. For one, the player screen is rectangular, so you have to make the circle quite large and end up spawning too many entities off-screen in the verticle direction and too little in the horizontal. It is also a pain to have to check every frame if something is no longer in the circle around the player.

I propose to move over to a tile-based computing system for lack of a better word that is used in every other game. Below is my failed attempt at using text to illustrate what I mean (the X is the player cell).
_____
|||_|
||X||
|||_|

We calculate all the cells, compounds, velocity fields, etc… in 9 squares surrounding the player’s screen. Unlike the previous system, this allows AI cells to swim into the player’s screen (currently if you stop moving, all AI microbes disappear after a while because they don’t spawn unless the player moves). It also means that you can continue chasing an organism after it vanishes outside of your screen (right now if it leaves the screen, it’s gone). Whenever the player moves to one of the 8 bordering tiles, the 3 tiles directly opposite from it disappear and are replaced by three new adjacent ones, as shown below.

_____
|||_|
||X||
|||_|

_____
|||_|
|||X|
|||_|

___
|[b]||||[/b]
|[b]||X||[/b]
||||_|

 ______
|_|_|_|
|_|X|_|
|_|_|_|

Hopefully, this all makes sense.

2

It makes sense, though I’m not sure why we would need to discretize it – cells could simply be spawned/despawned at a sufficient distance from the player that you’ll never see them pop in/out. The only thing I see us possibly needing to do, is stretching the spawn and despawn boundaries in the direction you’re moving, to cover cases where you move quickly.

3

Because, frankly, circles are a pain. I’ll bring two example to show why a grid is much faster and easier to work with.

  1. I can easily make a for loop that calculates the velocities in a grid cell, but calculating it for an area that is part of one circle but not another would involve a lot of checking conditions.
  2. I can easily see if a point is in a square cell, I just compare the x and y coordinates. To find if a point is in a circle I would need the distance, which is expensive to calculate.
    Okay, I have another one.
  3. It is a lot harder to randomly place a point in a circle than in a rectangle.

Tl;dr: cells are faster and much easier to work with.

4

One option you have is to change metric. So if you define distance = max(x,y) then draw a shape which is “all the points equidistant from the origin” (definition of a circle) you get a square.