Introduction

Since you won't be streaming for a while I though I'd share a thought on this project that I had for a while. I wasn't sure if it would be an issue at all, and I'm still not, but in any case it's probably better to mention it now than in January.

Problem(?)

So, I have been thinking about the arena grid and game cell structure, to be more specific I've tried to look at it from a resource efficiency perspective.

At the moment the grid looks something like this:

struct GameGrid{
	width: u16,
	height: u16,
	grid: Vec<Vec<GridCell>>,
}

struct GridCell{
	coordinates: Point<u16>, // I also wonder if this is necessary since 
                                 // GameGrid.grid[x][y] already implies the coords
	contains: Piece,
}

enum Piece{
	...
	}

I have been wondering if this is the best practice. It surely is intuitive, but with a large arena most of the Piece's will be empty. Under the assumption that for every Piece a new bit of memory is allocated, you'd have a lot of duplicate piece of memory allocated just to express that some cell of the grid is empty. If my assumption is valid, it might be wise to consider other hierarchies/structures.

The next part based on the assumption that every cell of the grid allocates a new piece of memory and that most of the cells are empty (e.g. 500x500 grid, thus 250.000 cells, with 1000 bots would still mean that more than 99% of the cells would be empty even if all bots would fire 1 bullet). If my assumption is incorrect, you can discard this issue, I'll return to my box of shame and we'll never mention this again. (Implicitly I assume that the allocation takes up a significant amount of memory. I mean, no one bats an eye if takes up 10 MB instead of 1MB)

Suggested solution

An idea for solving this is, is sort of getting rid of the cells. What if the grid would contain a list (or some form of grouping structures) and thus only registering useful information. An example is given below.

struct Grid{
	width: u16,
	height: u16,
	pieces: HashMap<(u16,u16), Piece>, // HashMap<Piece, (u16,u16)> might work as well
	// here pieces are some entities that live somewhere on the grid
}

struct Piece{
	Bot{...},
	Bullet{...},
	Powerup{...}, //just an example
	Wall{...},
}

In the example above, I'm mapping the coordinates to some Piece and a Piece is only something that contains 'useful' information. In this case I chose for a HashMap, but I haven't looked into other possibilities. The constant updating of keys of the HashMap might be a bit inefficient, but the bottom line is to only track the things we're actually interested in. From that we can infer that the rest to be empty. Applying the suggested approach to the example of a 500x500 mentioned it earlier, pieces will only need to hold 2000 items, instead of the 250.000.

Of course, the question then is: does this affect further computations and does it hamper the readability? Maybe collision checks will be harder and that might lead to a decreased performance. Maybe the suggested approach is quick and dirty instead of quality code. It might be worth to investigate.

Recap

So the questions are:

• Is my assumption valid? (loads of duplicate mem)
• If so, is the consequence severe enough to 'question' the current implementation?
• If so, can we solve this with a solution similar to the one I suggested?
• If so, does this solution solve everything/enough? No caveats?

If I can manage, I'd love to work on this problem during the rest of December. However I'm not sure if it is worth investigating (or that it even is a problem), so I hope you could give your thoughts on this.

In either case, it just has some implication for the logic of tracking stuff, collision checks, etc. Not for the actual game itself. So it isn't something that must be solved (now), but it might be some food for thought during the hiatus :)