brookspatton / brcodegg Goto Github PK
View Code? Open in Web Editor NEWThis is the primary repo for my battle royale coding game
This is the primary repo for my battle royale coding game
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.
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)
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.
So the questions are:
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 :)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.