#War Games
10 messages in this thread
I am trying to write a war game and I need some help.
I need to find a good way to setup my arrays in Basic to take care of my
map and units. I want to write it in Basic for convience sake but if my
only option is for Assembler or C I can do that also.
I just have to be able to access my unit data and store my information for
a map which includes elevation. My arrays turn out to be monsters.
I had thought of how to store info in bits but I have no idea of how I
should be retreiving the info and how to analyze it quickly.
Thanks for any info,
Jim
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
Thanks, Any advice helps. I have done tinkering in C but not awhol lot. I'd
like to try and get ti to run in Basic where I can debug it easier then if
the gme turns out to be worth while I'll see about converting it. I am
trying to write a war game on a unit scale dealing with armor and
helicopters and that is why I am haveing so much trouble with elevations
and units beeing able to spot things like helicopters at different
altitudes over the terrain. Thanks very much for the advice and I'll post
another message when I hit my next wall.
Jim
PS I love playing Perfect General,Empire and UMSII.
I've been programming in AMOS Basic for about a year now and the trick I
use to record elevations on a map is to create an iff with the elevations
coded as different colours. I create a EHB screen so that I can have 64
different elevations, and all I have to do is read the pixels value at
whatever X Y coordinate I need. A particular benefit is that the memory
requirements are highly optimized vs using an array. If you choose your
palette colours well you get a beautiful contour map to use as well.;-) As
an aside to another thread here, to first learn programming principles I
would suggest AmigaVision as it gives instant results… dead slow, but
instant enough. Other than that I have found Amos to be the most productive
language I have tried… much easier than C or assembler.
– via Whap!
Well I guess I'll have to try Amos seeing is how I have had more than one
suggestion to use it. Is there any heavy requirements to use it? I doubt
there is but one would never know. I have thought of tryingdifferent colors
for different elevations,but the problem I ran into was scaning the area
between the two units to see if they could see each other. I would draw a
line between the two units then sets flags as I moved through the grid
between the two units. Then depending on the result I had after reaching
the other unit I could tell if one could see the other. In Basic this
routine was less than speedy but I have no other idea as to how to do it.
The game is on a unit level so my routine is going to have to be sharp in
determining visibility between units. Any ideas or suggestions?? Thanks
Jim
As far as any Basics that I have tried, and I have tried several, Amos has
the best combination of features and has been upgraded often and quickly.
There have been very few bugs and these have been delt with rapidly. Amos
Pro which is now out should be even better as there have been a lot of new
commands added and the manual has been expanded and revised. The manual
is one of the best manuals I've used as it is orginized with related
commands in the same place and has cross referencing to other commands. It
also compiles so is a very fast language. I don't really have any
suggestions for speeding up your routine except to write it in assembler
and get your basic program to call the routine. I always write a program
first in the high level language until I get all the bugs out and then I
translate any computation intensive parts that slow the program down into
small assembler routines. I hope this helps. Bill.
– via Whap!
Thanks Bill, Since I have posted my message on the board asking for help
eveyone has\ been really helpful. I have been putting this game off for a
long time and with the comments and suggestions from people like yourself I
excited about going back to it and finishing it.
Thanks again.
-Jim
Jim,
Commenting on Bill's message to you, I'd like to add that on the occasions
that I've programmed in Basic and wanted the code to run faster, what I've
done is to write a library in assembler and call it just like you'd call
any of the standard libraries.
It's quite easy to do, once you've got a template to copy. Of course, you
have to debug your library routines by calling them in assembler – you'll
never do this from a higher level language as the machine can just crash
for no apparent reason.
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
Thanks. On Libraries, do you mean like a routine written in Assembler?
Kinda like a subroutine for handling a specific task that I could call to
process a certain part of my code. I guess I'm a not sure what you mean.
Jim
Jim,
Yes you're correct, libraries are just collections of routines. If you
write your own library, you should store it in the LIBS: directory. You
can then use it in just the same way you would use any of the system
libraries (exec.library, dos.library etc).
In other words, first you could write a library containing the routines
which need to run at top speed. Then, in your main program you open the
library, call the routines contained in it to handle specific tasks, and
close your library when your main program finishes.
I used this technique with AmigaBasic a while ago, and it worked a treat.
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK