From: "Thomas Tomiczek" <[EMAIL PROTECTED]> <snip> > Also, I am not so sure whether you are not wasting TONS ot space. > > Your field (hex) currently consists of one byte plus a pointer. > > Now, this limits you in two ways: > (a) you can not have more than one object on a hex (rules may change, > what about minefields?)
One solutions to this is to add a reference in the unit class that points to the next unit in the hex. > (b) the pointer is pretty huge compared to the byte. At the same time, > most hexes will not contain a unit. > > My idea would be to store the position of a unit either in the unit > class or in a helper class. > > Use hashtables on various grids to find all units in a given sector > fast. I will definitely need a few more bytes in the struct later. But yes, storing the units in a Hashtable would save a lot of memory. I'm concerned about the speed though. Each time a unit is moved, I have to check the vicinity to see if it's spotted (fog of war), if there's an enemy unit in the hex and possibly also to see if an enemy unit nearby wants to open fire. I recently read an article by a game programmer who claimed that you almost always had to store pointers to the units both in the map and in a central store (I'm using a hashtable for that) to get decent preformance. Peter You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
