Rough overview of my situation: I’m using procedural content generation for the layout of my 2D game space. My PCG creates a 10x10 array; randomizes some values for each node; then, eventually, draws either a floor tile or lava tile to the screen.
We have a class or interface for everything I need. If I need a sequence I’ll use IEnumerable, if I need a mapping from contiguous numbers to data I’ll use a List, if I need a mapping across arbitrary data I’ll use a Dictionary<K,V>, if I need a set I’ll use a HashSet. I simply don’t need arrays for anything, so I almost never use them. They don’t solve a problem I have better than the other tools at my disposal.
So I read up a little on List<>, Dictionaries<>, iEnum, and hashTags, and vaguely understand their uses compared to single dimensional arrays. However, I’m concerned with 2 dimensions. So, List <> is basically a single dimensional array; can I nest them, and is this faster than just creating an array? Dictionary<> creates keys/values. But this is probably more suitable for a storing attributes you want associated with one object. For instance, like storing data about the player.
So I guess my question is this: For Planer (or worse Cartesian) mapping systems, how do you guys handle structuring the storage of variables contained on each game space? I should clarify I’m not really looking for code, unless it helps to clarify your example. I’m more or less looking for reference material on methods or concepts (hell even terms to google), that I don’t know about and can help clarify this for me.
List<> is simply a wrapper around an array. It can grow when necessary and shrink when cleaned up. As for computational and functional use, choose what you prefer and use that.
Roughly, yes. You would have to new List<int>() each element of the multi-dimensional List though, which makes the multi-dimensional array more attractive.
That’s why I was thinking too; but not knowing every nuance, I felt like I was ignoring something obvious or well know.
Continuing with that, it seems like I want to create a Grid Class, with Dictionary<[,]> storing all of coordinates of every object on the board. Since, I’ll be supplying the coordinates for the array to look up (instead of it searching for a value to find at x&y coordinates); and I can create dynamically scaling lists of arrays within the dictionary… In theory I should be getting the best of both worlds in terms of finding objects and accessing them, with respect to performance?
If yes, I’m thinking I need to review {get; set; } again.
edit…*
Actually, it looks like I want to investigate Entity Component Systems as my underlying structure for handling all of my data. At first glance, it looks like it’s difficult to setup, but the correct approach for handling data on current systems. Am I at least heading down the right track so I am not wasting time reading a bunch of articles,etc?
It depends what you are up to, how much stuff is going on and how much you want to play with this
For a 10x10 floor I’d probably use a 2d array (or a 1d array and use some maths to work out what cell is what index, then you only do one memory allocation instead of 11)
For your entities, if it is a common operation to lookup what is on a certain cell you could do a List[,] or something like that, but probably you will not have that many entities, so just putting them all in a List and looping over the list will be fast enough (will depend how many entities you have etc).
[quote=“daveleaver, post:6, topic:1808”]
but probably you will not have that many entities, so just putting them all in a List and looping over the list will be fast enough (will depend how many entities you have etc).
[/quote] Which is exactly what I have right now, <10 entities on a 10x10 board using a 2D array, but in fairness it was really just for testing certain features. However, now that I understand Monogame/XNA a little better (compared to 2 weeks ago), the amount of “content” for lack of a better term, that I want to add is scaling very quickly.
With that in mind, I took a step back and thought about what I really want to accomplish; which from my OP to sometime late last night lead me to ECS. The extra overhead of setting up a working prototype may not be ideal for these small projects, but I think it will pay off in the long run. Plus, I feel I should be structuring my systems this way anyways for the flexibility it offers.
