Jump to content

Photo

New Game - Stratego

Stratego TI 99/4A Extended Basic

40 replies to this topic

#26 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,380 posts
  • Location:Lansing, NY, USA

Posted Sun Feb 17, 2019 1:08 PM

So in the case of Stratego, the main game program is chain-run after the setup program is done. If the main program is in 2 segments, how would I go about loading it from the setup program?

Also, would you mind posting the actual assembly code for the CALL LOAD statement so I can better understand how you do this?

What I envision is the low memory code saved as an XB program - let's say "PROGRAM1". The high memory code is saved as "PROGRAM2"

Your setup program does this: "RUN "DSK1.PROGRAM1".  Program1 is a 1 line program:

 10 CALL LOAD(8192,32,8)::CALL LINK("X")::RUN "DSK1.PROGRAM2"  

with an XB program of up to 8K stored as embedded code. 

This program is loaded into high memory and the AL sub at >2008 copies the embedded XB code to low memory. When the sub has done this it returns to XB and the program then loads and runs Program2. The first line in Program2 does an AL sub that finds the line number table for the XB code in low memory and merges that with the line number table for the XB program in high memory. The program would then probably have to run itself again so the prescan has been done properly. At this point the program runs normally but with up to 32K of code available. This utility does not exist yet, but the concept is simple enough.

 

The CALL LOAD statement sets >8330 (start of line number table), >8332 (end of line number table), >8384 (highest address in exp memory), >8386 (highest free address in memory exp) This fools XB into loading the program into low memory. This may be useful to whoever decides to implement this idea.


Edited by senior_falcon, Sun Feb 17, 2019 1:12 PM.


#27 TheBF ONLINE  

TheBF

    Dragonstomper

  • 923 posts
  • Location:The Great White North

Posted Sun Feb 17, 2019 1:21 PM

 

The main difficulty is going to be the subroutines conversion. Also, it's quite a long program. Happy to assist you in this endeavor if you are up to it. It would make a great show and tell at the next Chicago Faire companion event!

I am attaching the source code in TIdBiT format which should make things much more readable. 

 

It wonderful BASIC code but converting this to Forth by trying to imitate the BASIC code will probably not be ideal. 

There are some blocks of code that are very long, a fair number of nested loops as well, all of which would typically factored differently in Forth.

 

Its a big enough program that it will take some time to consider how a Forth implementation should look.

 

If Lee can see a way to partition the work into pieces I can assist with some translation. I have FB Forth working here now.



#28 FarmerPotato OFFLINE  

FarmerPotato

    Moonsweeper

  • 272 posts
  • Location:Austin, TX

Posted Sun Feb 17, 2019 2:00 PM

The AI concept is pretty simple here and mainly consists of many simple heuristic rules each covering a specific situation. For example, one rule would state "don't attack a known enemy piece of higher value". I attach a score to each rule, and rules override each other depending on the score while others have a special urgent trigger which calls for immediate action regardless of the score. 

 

Computer game AI is one area I never had a clue about. I've spent a day thinking about it and actually dreamed I was playing Stratego (and losing).

Thanks for  posting this info.



#29 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,906 posts
  • Location:Silver Run, Maryland

Posted Sun Feb 17, 2019 3:42 PM

I'm waiting, Lee - it has been almost half an hour and you aren't done yet?  ;)

 

Hey!...I am out here on the beach dispatching the opposing team in a game of horseshoes.  Did I say I was out on the beach?  Oh...and my final pitch was a double ringer.  :P

 

...lee



#30 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Sun Feb 17, 2019 10:04 PM

welp it looks like I broke a couple of things in the program with my last update. It's gotten so complex that it's really hard to completely predict the ramifications of any change to the AI. 

I updated the disk image yet again in the first post with a fix.

Sorry about that. I think I'm going to stop tinkering with the AI and call it done :) 

Please let me know if you run across something weird. There are only so many games of Stratego I can play and feedback is invaluable here.

I should also mention that I've been having some weird issues with Classic 99 under Overdrive where parts of the program lines seem to disappear, causing strange crashes and unexpected behaviors. This apparently happens randomly and I'm not sure what's going on, so I would strongly recommend you only use Normal mode when playing Stratego in Classic 99. 



#31 SSG OFFLINE  

SSG

    Dragonstomper

  • 758 posts
  • Live Long, And Prosper.
  • Location:Pennsylvania, USA

Posted Sun Feb 17, 2019 11:01 PM

I literally might buy a Ti-99 for this.



#32 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Mon Feb 18, 2019 7:02 AM

What I envision is the low memory code saved as an XB program - let's say "PROGRAM1". The high memory code is saved as "PROGRAM2"

Your setup program does this: "RUN "DSK1.PROGRAM1".  Program1 is a 1 line program:

 10 CALL LOAD(8192,32,8)::CALL LINK("X")::RUN "DSK1.PROGRAM2"  

with an XB program of up to 8K stored as embedded code. 

This program is loaded into high memory and the AL sub at >2008 copies the embedded XB code to low memory. When the sub has done this it returns to XB and the program then loads and runs Program2. The first line in Program2 does an AL sub that finds the line number table for the XB code in low memory and merges that with the line number table for the XB program in high memory. The program would then probably have to run itself again so the prescan has been done properly. At this point the program runs normally but with up to 32K of code available. This utility does not exist yet, but the concept is simple enough.

 

The CALL LOAD statement sets >8330 (start of line number table), >8332 (end of line number table), >8384 (highest address in exp memory), >8386 (highest free address in memory exp) This fools XB into loading the program into low memory. This may be useful to whoever decides to implement this idea.

 

I'm going to save this concept into my programming archives because it opens up XB to a lot of amazing possibilities once the full 32K is available. I already have a project in mind :)

I need to learn the trick of embedding an XB program within an ALC utility. Maybe even create a special utility similar to what you did with TML to allow the embedding of ALC code.



#33 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Wed Feb 20, 2019 3:15 AM

Found another bug which only occurs in a very specific situation and causes the computer to move a piece on top of another friendly unit and engage in combat. Basically going rogue  :D In all my testing I never had encountered it previously, and it took some painful manual stepping through the program execution to finally figure out what was going on. I wonder if there are other bugs hidden in there somewhere.

In any case, I updated the first post to reflect that last fix and hopefully, that should be the last update.

Incidentally, most of the commercial Stratego computerized versions out there seem to be pretty lousy from an AI standpoint despite having vastly larger available resources. Who said the TI can't compete with the big boys?



#34 OLD CS1 OFFLINE  

OLD CS1

    Technomancer

  • 5,933 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Wed Feb 20, 2019 2:09 PM

No way, just reduce its occurrence.  Friendly-fire from defectors is a nice twist.



#35 wolhess OFFLINE  

wolhess

    Space Invader

  • 42 posts
  • Location:Germany

Posted Yesterday, 6:35 AM

Found another bug which only occurs in a very specific situation and causes the computer to move a piece on top of another friendly unit and engage in combat. Basically going rogue  icon_mrgreen.gif In all my testing I never had encountered it previously, and it took some painful manual stepping through the program execution to finally figure out what was going on. I wonder if there are other bugs hidden in there somewhere.

In any case, I updated the first post to reflect that last fix and hopefully, that should be the last update.

Incidentally, most of the commercial Stratego computerized versions out there seem to be pretty lousy from an AI standpoint despite having vastly larger available resources. Who said the TI can't compete with the big boys?

Hi Vorticon,

 

a very nice strategy game. I downloaded the last version from Post 1 today.

I played maybe half an hour, then I got an error message:
Attached File  IMG_2378.JPG   125.85KB   0 downloads

Bad Value in 1350

IN BACKGROUND

Called From BATTLE

Called From 620

 

1350 Call GCHAR(YB,XB,BCHAR)

YB=15

XB=33   --> I think this is the problem

BCHAR=32

 

Maybe this help to fix it.

 

wolhess



#36 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Yesterday, 6:57 AM

Thank you for the report! I've never encountered such an error previously and I'm a little puzzled by it because it looks like it happened right after the outcome of a battle, which means that the piece coordinates were reported correctly. In order for the XB variable to be 33, then one of the pieces would have had to be offset to the right by 2 characters and thus off the game field, which you would have noticed and would have also trashed the BATTLE routine. From the screenshot, which is extremely helpful (thank you!), it looks like the attacker was the computer. Do you recall the value of your piece being attacked? Was it a scout (value 2)?

Can you tell me what hardware you played the game on? I have experienced unusual errors when the game is played on anything but a standard console (F18A ok) or in Classic 99 normal mode or JS99er.

 

Update:

So far I have not been able to replicate that particular error. I've tried to create situations where the computer is attacking a known or unknown player piece at the right edge of the playfield, and everything seems to work as expected. Frankly, I'm a little stumped here because this type of error should have cropped up a long time ago given that the BACKGROUND routine is one of the most called routines in the game... If anyone else has experienced this issue, please report it to me with as much detail as you can muster. This is a super complex game and it is possible there might be a very particular rare situation that might trigger an erratic response.



#37 wolhess OFFLINE  

wolhess

    Space Invader

  • 42 posts
  • Location:Germany

Posted Yesterday, 10:05 AM

unfortunately I can't recall the piece being attacked.

 

my hardware is a US-TI99 with PEP (32K, P-Code card=off, RS232, TI-diskcontroller and tipi inside)

 

I played the game with RXB from FG99-Module.

The game is on the tipi\xb\stratego path mapped as DSK1.

 

Right now I was playing over 4 houres without any issues.



#38 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Yesterday, 11:03 AM

OK thanks for the info. It doesn't look like there should have been any issues related to hardware, although I have not tested the game with TIPI. I'll keep trying to replicate the issue.



#39 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Yesterday, 9:13 PM

I just couldn't help myself  :P While hunting for Wolfgang's elusive and so far un-replicated bug, I managed to add a couple of enhancements to the AI, literally squeezing every last byte out of the 24K RAM available. There might still be room for a semi-colon, I think, so this has got to be it.

As for the aforementioned bug, I guess I'm going to have to let it lie as it seems to be exceedingly rare, and I have yet to encounter it after close to 30 played games. Otherwise, the game seems to be behaving appropriately.



#40 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,906 posts
  • Location:Silver Run, Maryland

Posted Yesterday, 9:20 PM

I just couldn't help myself  :P While hunting for Wolfgang's elusive and so far un-replicated bug, I managed to add a couple of enhancements to the AI, literally squeezing every last byte out of the 24K RAM available. There might still be room for a semi-colon, I think, so this has got to be it.

As for the aforementioned bug, I guess I'm going to have to let it lie as it seems to be exceedingly rare, and I have yet to encounter it after close to 30 played games. Otherwise, the game seems to be behaving appropriately.

 

 

PM me any TidBit changes, please, Kind Sir.

 

...lee



#41 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,551 posts
  • Location:Eagan, MN, USA

Posted Today, 5:33 AM

No way, just reduce its occurrence.  Friendly-fire from defectors is a nice twist.

 

Ha! Turning a bug into a feature: the oldest trick in the book!  :grin:







Also tagged with one or more of these keywords: Stratego, TI 99/4A, Extended Basic

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users