1. lots o stuff
- Posted by noah smith <nhs6080 at UNIX.TAMU.EDU> Oct 15, 1998
- 573 views
- Last edited Oct 16, 1998
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. :|
2. Re: lots o stuff
- Posted by Hawke <mdeland at NWINFO.NET> Oct 16, 1998
- 543 views
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'
3. Re: lots o stuff
- Posted by noah smith <nhs6080 at UNIX.TAMU.EDU> Oct 16, 1998
- 539 views
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
4. Re: lots o stuff
- Posted by Hawke <mdeland at NWINFO.NET> Oct 16, 1998
- 579 views
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...