Do use the R1 and R2 keys while laying out a program.  They'll help speed
you through the drudgiest part of the game.  The manual mentions them, but
personally, I missed that part the first time through.

  For all the intelligence and attention to detail this program shows in
most respects, troop movement is butt stupid.  Since units cannot be
stacked more than one to a map position (except in bases), they'll collide
and set out in directions completely opposite from the directions you've
ordered.  Executing an ordered attack on an enemy position is much easier
if you ensure that lower-numbered units are always ahead of higher-numbered
units, since units are moved in strict order beginning with #1.  Even then,
sometimes units will still set off in random directions.  A unit listens
most closely to your orders when you tell it to move one hex at a time, and
you'll have to resort to that particular tedium on occasion, even if you're
careful to put lower numbered units at the head of the attack.

  A unit gives an indication of the direction it wants to head when the
turn ends, except when it's about to stop dead in "standby" mode.  It will
indicate that only after it has done so, and you've lost a turn of
movement.  You'll have to remember where each unit's movement instructions
end, and be ready to give it a new direction before it sets up camp.

  There are interesting concurrency problems in an OKE's battle program.
The program runs faster than the machine, and so the machine will still be
executing a "turn" instruction, say, as the program runs on to the next.
The manual points this out, but gives incomplete rules for using this
feature.  I believe the input chips (scan for enemies, scan for mines and
all that) do execute as quickly as the program can run them, though I
thought the manual hinted in a place or two that they might not.  The
output chips are where the issue occurs.
  The output chips have a strict order of precedence, as the manual does
point out.  A jump chip wins over a fire or move (walk) chip, and a fire
chip wins over a move chip.  So an OKE running under a program which says
"shoot, jump, walk forward" will only jump.  Which is only fair; it's easy
to write a program that starts to shoot an enemy but then decides to dodge
an incoming bullet instead.  The manual doesn't mention that within
categories, there is yet another rule.  The first jump chip or the first
fire chip wins the day: "fire primaries forward, fire secondaries right"
will fire primaries forward.  But the last movement chip it runs into is
the one it actually executes.
  These rules become very important as you try to hammer your intentions
into the unyielding, 8 by 8 programming grid and .

  Finally, the counter and test-for-ammo chips claim to branch if greater
than (or less than) the value you specify, but actually branch if greater
than or equal to.  So a program which reads "if ammo remaining is less than
one, use your fist, otherwise shoot" won't fire the last round of ammo.

- Grendel

====================================================================

Well, now that we've all gotten over how cool the game is, 
it's time to start hashing out some real design discussion. =)
Like Bill Bechtold, I don't want to give away all my secrets,
but discussing general design stategy sounds like fun.  I
hope this isn't too basic for everyone. =)

I build all my OKE's with a very modular plan.  I divide all
the OKE's behavior into "move", "attack", "evade", etc. then 
design each one individually on paper.  I've found that this 
saves a lot of space and makes the OKE easier to debug and modify.   
My current OKE looks something like this:

      ________________________   
     |  _______    _________  |
     | |       |  |         | |    Note the spaces around the modules.
     | | init. |  |  attack | |    This gives them some room to grow
     | |       |  |         | |    without having to design the whole
     | |_______|  |_________| |    OKE from scratch.  You also need
     |  _______               |    some space to wire all the modules
     | |       |              |    together.  
     | |       |   _________  |    
     | | move  |  |         | |   
     | |       |  |  evade  | |   
     | |_______|  |_________| |   
     |________________________|   

The modular development helps out a heap when debugging.  By watching
the program trace in the test arena, it's very easy to see roughly how
much time your OKE is spending on each activity and how the program
flows.

The final big benefit of this is that you can easily modify
the priority of each activity with a series of conditionals in
the left-hand columns.

   _______         _______
  |       | yes   |       |
  | if    |------>|  nop  |----> string leading to attack
  | E 100 |       |       |
  |_______|       |_______| 
   ___V___
  |       | yes
  | if    |------>  nop string leading to evade
  | ! 80  |
  |_______|
      V
   branch to
     move


Above is an aggressive program that will attack immediately if anything
comes within range.  If I want to make the OKE more defensive, all
I have to do is switch two chips:

   _______         _______
  |       | yes   |       |  no
  | if    |------>| if    |-------> nop string leading to attack
  | E 100 |       | ! 80  |
  |_______|       |_______|
   ___V___            V
  |       |        
  |  nop  |           nop string leading to evade
  |       |
  |_______|
      V
   branch to
     move


Of course, one disadvantage to the modular approach is that you
use a good number of nop chips to build those initial condition
branches. If you know that you want to build an certain style of 
OKE, you can eliminate this by laying out the modules in the order 
that you want them to execute.


EVASIVE LOOPING
-----------------
There has been some discussion on using looping to provide quick
evasive manuvers.  Here's the template for an evasion module 
that I use.  The strategy is to progressively check for bullets from 
all sides.  If you see one, take evasive manuvers and loop back to the 
start of the module.  If you check all 360 degrees without finding a 
bullet, you pass through the module and get on with something else.

 _______
| A:0   |    For your reference, this ASCII tile means, if there
| S:120 |*   is a bullet within 80 meters in an arc centered on
| !:80  |*   angle 0 (straight up) and 120 degrees wide, branch
|_______|    to the left.  If not, branch down.
    V

          in
        ___V___   _______   _______  
       |       | | A:0   | | A:180 | 
in --->|  nop  |>| S:120 |>| S:240 |>-----> out
       |       | | !:80  | | !:80  | 
       |_______| |_______| |_______| 
        ___^___   __***__   __***__  
       |       | |       | |       | 
       |  nop  | | jump  | | jump  | 
       |       | | left  | | forwd |
       |_______| |_______| |_______|
        ___^___   ___V___   ___V___
       |       | |       | |       | 
       |  nop  | |  nop  | |  nop  | 
       |       | |       | |       |
       |_______| |_______| |_______|


This is a fairly braindead example, but the basic template is there.
Scan for bullets in one row on the board.  If you find a bullet, branch
down.  Once you take evasive manuvers, loop back and look for more
bullets (saves my little OKE all those times jumping in one direction
puts you back in the line of fire from another OKE!).  This OKE
will jump out of the way when it finds a bullet, then keep on
jumping until it's in the chear.  Note that the cost in nop chips 
for the loop will be lower if your evasion module is long and 
flat rather than a square.

One interesting point about this little algorithm is that the OKE
jumps _forward_ when it sees a bullet behind it.  This has the
hilarious effect of making the OKE run hopping away from enemy
fire.  This can be very desireable at times (like when you want one
OKE to draw enemy fire and the other to loop around behind for the
kill.)

To make the OKE even more evasive, you can conditionally branch to
the evasion module before doing any risky tasks.  If it's damage
is higher than 50%, my OKE will check for incoming bullets before
firing any of its weapons.

Well, that's my 2 bits.  Let's get that league going. =)

---
Tom Cannon
tom@vxtreme.com

==========================================================================

Now for my programing hints.

Unlike Tom, I write my programs in a somewhat unorganized manner.  Before
I write it I place my priorities.  What my programs lack in being able to
re-organize, it gains in functional specialization.

First, I plan.  At what point should I evade? (if at all in the case of
tanks.)  Attack?  Search?  Advance?

My latest program starts with a search for obstacles or allies.  Then I go
into a advance attack mode.  If any allies were detected in a 120 degree
range atack of the OKE, it does an advanced search and shoot function.  If
not ally to the left shoot left.  If ally is left, look right, if ally is
to right also move or If ally is left, look right, if no ally is detected
to right shoot right.   If no ally was found in the original 120 degree
search it goes into a regular attack mode.  If enemy is in 135 ft shoot
main weapon.  If enemy is in 110 ft, shoot secondary weapon.  After an
attack, my program jumps to evade.

If no attack was formed, my program goes to search.  It also has an
advance movement function where if an enemy is closer than 90ft in fron my
OKE jumps backward.  Similarly if my OKE is out of shooting range, it will
advance.

I have a evasion tactic of ducking when any projectile is closer than
40ft.  At 75 feet and closer, it will do a quick search to the side of the
attack and avoid the other direction.  Mine detection can take MANY chips,
and it is often easier to siplify it by making limited OKE reactions. 
Also, I only have my OKEs avoid from frontal attacks, this gives my OKEs a
weakness (behind them) but prevents them from being "hop-happy."

You must also make sure you add plenty of temp chips!  I have used limited
numbers of damage {/}  and fuel {/} chips.  I definitely use ammo {/}
chips in all my attack loops!

Well, that's about it for now!  We'll see what I create in the next week! 
My new OKE programs beat my old ones by a CONSIDERABLE margin.  (And the
old ones were pretty good.)  

8^)

-- 
-Bill Bechtold

============================================================================

Ok, I'm really still just playing around, I haven't really started.  Really.

I started playing the hardest scenario to see how much research I could get
done.  I wrote a program for the Prowler body that was pretty efficient, but
not perfect, and set about producing and overrunning the enemy.  By turn 30
I had 2 slightly more advanced versions of my OKE (in equipment, not program)
and had pinned the enemy down to one final base.  I had about 30 or so of my
OKE's made, of varying versions.  I stopped production of OKE's and consolidated
them in my 2 forward bases.

From there, I started blockading the enemy base with 2 units, and when an
enemy came out of the base one of them attacked the enemy unit.  After the
battle, I sent my unit back to base to repair and rearm, and sent a fresh unit
up to replace them.  My program did quite well against the enemy OKE's, and I
only lost an OKE roughly once every 10 battles.

After turn 90 I was no longer given any funding, and neither was the enemy.
However, the enemy was still able to produce a unit to throw at me every 10
turns or so.  A friend pointed out to me that I could defend my bases instead
of constantly sending units in and out, so I left my units in my forward bases
and let the enemy units come to me.  The enemy always went for the closest
base, so I moved all my units to it.

Now during all this I had funded some R&D, bought some blueprints I liked, and
optimized them.  I didn't have to produce any more OKE's, since the ones I had
were holding out just fine.  I didn't want to spend too much, so a lot of
stuff that showed up in R&D got researched to completion without my financial
help.  I put the cursor on 'End Turn' and switched the X button on the joystick
to autofire.

By turn 300, every item in the game had been researched to completion.  I
decided to upgrade my OKE design further for use on the next map, so I bought
the Vypor 2-leg body, the Hug9090 engine, the Alpha missile, 100mm armor, and
the best main weapon ammo and optimized everything.  This left me with about
15000, enough to produce a few mechs on the next map.  Not really good, but
I'm still playing around.  I don't take the last base yet.

As time goes on, the enemy OKE's don't get much smarter, but their armor and
weapons improve a lot, and since I'm not making any new OKE's, the
differential in equipment is making my attrition rate rise.

By turn 800, I'm down to 9 OKE's, and I'm wishing I hadn't spent anything
on R&D since it all gets researched anyway.  Now I've got a better idea
of what I'm looking for in hardware and next time I can avoid R&D and
buy only necessary blueprints.  I start producing OKE's one at a time
to make up losses.  I don't use my newest design because it's too
expensive.

I run out of OKE's around turn 910.  I really wanted to see what happens
after turn 999 (hoping that it rolls over to 0 then funds me every 15
turns once again) but I expect the enemy to overrun the map before it happens.

However, the enemy takes it's sweet time, and only retakes 3 bases by turn 999.
After turn 999, the turn counter no longer increments.  Also, the enemy no
longer advances.  I still have 2 bases left, even after letting turns go by
for the last hour while I do net stuff.  Strange.

So I guess my next move is to start over, overrun and box in as before, but
spend as little as possible, and wait for about 300 turns, buy and optimize
only the equipment I need, then go to the next map with enough cash to overrun
that one.  If I'm frugal and squeeze all the funding I can out of each map,
maybe I'll have enough money by the end to buy and optimize all the equipment.

Then I can really start playing. ^_^

I'm tired.  I think I'll do that tomorrow.

Mark Bradley