1. lots o stuff

first, is there an algorithm which describes the behavior of the default
palette in the DOS graphics modes?  I'm trying to sort them based on
color and luminosity, but i can't discern the pattern involved there.

second, the "xplode.ex" program which was recently posted was absolutely
wonderful.  I sat there looking at that thing for 5 minutes when i
turned it on.  little progs which demonstrate algorithmic behavior,
opcoding, and code technique like this are perfect for us beginning
programmers, i think.  i'm still trying to figger it out tho (actually,
i'm a little unfamiliar with some of the operations).

third, if at all feasible, i think strings like the "win32 tutorial" are
highly appropriate and useful.  especially those of us out there who
really need to know the meat-and-bones aspect of programming, and don't
have the benefit of computer science college courses (or money to buy
the books).  perhaps more of these on useful subjects, like, say
high-speed DOS graphics would be in order.

lets see...o, has anyone else made or are making a strategy game?
specifically a turn-based, square-grid one?  i'm working on one right
now, and i just need some code examples so i can see where to go with
some of the complicated stuff...like AI.  so far i have:
map reading function (which is highly elaborate--almost all aspects of
the game are variable)
--includes game map, starting peice location, variable players
(conceivably infinate), map pictures (customizable by player)
--all the stats for all the different peices and land types (also
variable)
display function (map, game peices)
--separate functions for the "map" and "peices"
--peice movement is a simple step
"scrolling" function
--scrolls tile by tile, map-size checking so there's no trash or memory
leaks, etc.
the interface hasn't been started yet--i'm gonna wait until i get the
game mechanics working

what's left, and difficult
AI (not even in conceptual stage yet)
movement-range checking
--i've been pounding on this for 3 days now, and i can't get it to work
right.  it's recursive so its fairly hirstute, but "simple" solutions to
this prollem are horrible -- the only working function so far required
64,000 instances of the procedure (recursions) to find the solution when
the available "range" of a peice was 6.  smaller numbers yield a
distressing pattern-- x9 for each +1 to range

snortboy

p.s.  if anyone _really_ wants a copy of the game as it stands (its
about...1.3 megs [mostly bmps]), email me privately:

snortboy at tamu.edu

all it can really do right now is load up and display the opening
positions of the battlemap, but its kind of fun to look at.  :|

new topic     » topic index » view message » categorize

2. Re: lots o stuff

noah smith wrote:
>movement-range checking
>i've been pounding on this for 3 days now,
>and i can't get it to work right.  it's
>recursive so its fairly hirstute, but "simple"
>solutions to this prollem are horrible --
>the only working function so far required
>64,000 instances of the procedure (recursions)
>to find the solution when the available "range"
>of a peice was 6.  smaller numbers yield a
>distressing pattern-- x9 for each +1 to range

urmmm... if you described what you were trying to
*do* as opposed to what's not working, perhaps
we could understand the nature of the dilemma.
more importantly, we could assist in working thru
the solution to the dilemma, instead of hashing
around blenderized versions of non-functional
functions and null-proceding procedures.
:)


--Hawke'

new topic     » goto parent     » topic index » view message » categorize

3. Re: lots o stuff

Ok, here's what I have:

square, tile-based system, with an "army" at location (x,y).  the army
has a "range" of r.  each tile has a "land type" which has a "resistance
value" which is v.  armies may move to adjacent and diagonal tiles
(lands, with variable land types).  in order to move to the next tile,
the army must "pay" an amount from its' range (r), equal to the
resistance value of the land (v), such that (r - v >= 0).  most of the
lands have a resistance value of 1, and others have values of 2 or 3.
resistance values may be fractions (.5, or 2.5 v).  most armies have a
range of 6.  i am trying to write an optimized algorithm which
determines all the tiles (based on range and resistance values of the
land type) which determines all legal movement for an army in one turn
(that is: given full range and current location, where can the army
move).  I currently have one that does this, but it is sloooooooooow.
(several seconds at range = 6)

i hopes thats clear.

thx,

snortboy

new topic     » goto parent     » topic index » view message » categorize

4. Re: lots o stuff

noah smith wrote:
>Ok, here's what I have:square, tile-based system,
>with an "army" at location (x,y).
<snip>
>i am trying to write an optimized algorithm which
>which determines all legal movement for an army in one turn

take a look at the following 'code fragment' and see
what you think, and if it's faster than your method...
it's not really tested, but the logic is what you're
after anyway...

take care--Hawke'

----------------begin fragment
constant maxDIR=8,         --max number of directions
         maxPEN=4,         --highest terrain penalty (0..4)
         maxTYPES=3,       --number of 'types'
         maxTER=5,         --number of terrain types
         maxOBJ=100,       --number of object types
         maxMOB=100,       --number of mob types
         minMAP={1,1},     --min coordinates for the map
         maxMAP={100,100}, --max coordinates for the map
         maxRANGE=6        --farthest any mob/plr can move
         XI=2,YI=1,        --X index and Y index
         TI=1,DI=2,        --TYPE index and DATA index
         NORTH=1,NE=2,EAST=3,SE=4,
         SOUTH=5,SW=6,WEST=7,NW=8,
         --this is a list of offsets that apply to a coordinate
         --pair for a given direction
         DIRLIST={ {0,-1},{1,-1},{1, 0},{ 1, 1},
                   {0, 1},{-1,1},{-1,0},{-1,-1} },
         TERRAIN=1,OBJECT=2,MOB=3
sequence map
--map is a 2d seq, lineXcol ordered, which holds the 'world'.
--At each intersection there is a pair of values {TYPE,DATA}
--where TYPE is what is being held there (mob,terrain, or object)
--and DATA is the data related to what is held there. If TYPE is
--mob, then DATA would be its mob number, if it's terrain then
--DATA would be what kind of terrain, etc.
sequence moblist,objlist,terlist
object   junk,temp

--build map
--let's create some random world information...
map = repeat ({{},{}},maxMAP[XI]) --a line of Xcoord's
map = repeat (map,maxMAP[YI])     --a 'list' of lines
for i=1 to maxMAP[YI] do
   temp=repeat({{},{}},maxMAP[XI])
   for j=1 to maxMAP[XI] do
        junk=rand(maxTYPES)
        if    junk=TERRAIN then
                temp[j]={junk,rand(maxTER)}
        elsif junk=OBJECT
                temp[j]={junk,rand(maxOBJ)}
        else    temp[j]={junk,rand(maxMOB)}
        end if
   end for
   map[i]=temp
end for

--build terlist
--terlist holds the penalties for each 'type' of terrain
terlist=repeat(0,maxTER)
for i=1 to maxTER do
   terlist[i]=rand(maxPEN) --fill it with penalties of your choosing
end for

--build moblist
moblist={} --whatever you want

--build objlist
objlist={} --whatever you want


function Max(object a,object b)
   return a*(a>=b) + b*(b>a)
end function

function Min(object a,object b)
   return a*(a<=b) + b*(b<a)
end function

function FixBoundary(sequence point)
--determines if a point is on the map, and adjusts
--bad coordinates into good coordinates
   point = Max( point,minMAP ) --careful here...
   point = Min( point,maxMAP )
   return point
end function

function CheckDIR(sequence map, sequence center,
                  atom direction, atom range)
--Given a direction to travel, from a central point 'center',
--determine the last possible point that can be visited.
--This point will be within the distance 'range' along that
--direction, and will stop just before an obstruction is reached.
--Obstructions are defined as anything that *is not* terrain.
--Fractional penalties are accounted for.  If a border is reached,
--it will keep moving parallel to that border if the direction
--is diagonal, or it will simply stop at the border if the
--direction is along the X or Y axis.
sequence testpoint, goodpoint, terrain, offset, temp
atom penalty
atom testX, testY
   goodpoint= center
   testpoint= center
   offset   = DIRLIST[direction]
   while range >= 0 do
       testpoint= FixBoundary(testpoint + offset)
       testX    = testpoint[XI]
       testY    = testpoint[YI]
       --what's at this point on the map?
       temp     = map[testY][testX]
       --remember, TI is TYPEindex, and DI is DATAindex
       if temp[TI] != TERRAIN then --must be obj or mob
          return goodpoint
       end if
       terrain  = temp[DI]         --pick up the terrain type
       penalty  = terlist[terrain] --look up it's penalty
       range    = range - penalty
       goodpoint=testpoint --update the last known 'valid' location
   end while
   return goodpoint
end function

function FindValidMoves(sequence map, sequence center, atom range)
--Build a list of all locations that can be visited,
--in all directions, from the starting point 'center', for
--a distance around that point of 'range'.
sequence movelist movelist={}
   for direction=1 to maxDIR do
      movelist=movelist & CheckDIR(map,center,direction,range)
   end for
   return movelist
end function

? junk

--hope that worked...

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu