CompuServe Messages

#War Games

    19-Nov-92 23:17:46
Sb: #30219-#War Games
Fm: Jim Nangano/SYSOP 76703,4254
To: Jim Menix 70004,1732
Jim, My knowledge of Basic is extremely limited, so I can't really offer you direct help with what you are asking. I do have a little experience with writing war games, however. (I co-wrote The Perfect General, and have also done the Amiga conversions of a couple of other war games – Empire and DRAGON Force. I am currently working on a major rewrite of the original Empire. War games seem to be my life <grin>). We generally keep track of our units with arrays of complex data types (i.e., structures). It gets a bit more complicated than that, though, as I like to keep things "flexible" in terms of memory requirements – a "static" array can't grow and/or shrink very easily. One approach I've taken is to allocate enough storage for an "n"-element array, and when that is exhausted, allocate a new array of (2 * n) elements, copy the original array into the new one, leaving 'n' elements for growth, and freeing the original array. This has the advantage of quick access to the units (via a direct index), but the disadvantage of heavier memory requirements, as we have to allocate the 'new' array before freeing the old. This can also fragment memory, which can be a problem in a memory-constrained system. Another technique I've used is to maintain an array of pointers to fixed sized blocks of unit arrays. Each "block" is allocated as needed. To access a unit by number, I can use a two-dimensional array construct of "element[n][m]", where 'n' is the unit number divided by the number of elements in a single block and 'm' is the unit number mod-ed by the number of elements in a single block. This approach works directly in C, as it takes advantage of C's treating of arrays and pointers with an identical syntax. The advantage here is that I only allocate unit blocks as needed, and only allocate the growth amount, instead of an "old" and "new" block. The disadvantage is that each element access takes a little longer, as there's the extra calculations involved for the indices and the pointer dereferencing. I haven't noticed marked speed penalties, however. As is fairly obvious, I program primarily in 'C', and therefore my data elements are designed with C's strengths and weaknesses in mind. Hope this gives you a bit of food for thought. – BobR