New Game - Stratego

[senior_falcon]

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,::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 February 17, 2019 by senior_falcon

[+TheBF]

 

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.

[+FarmerPotato]

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.

[+Lee Stewart]

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.

 

...lee

[+Vorticon]

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.

[SSG]

I literally might buy a Ti-99 for this.

[+Vorticon]

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,::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.

[+Vorticon]

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 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?

[+OLD CS1]

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

[wolhess]

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 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:

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

[+Vorticon]

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.

[wolhess]

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.

[+Vorticon]

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.

[+Vorticon]

I just couldn't help myself 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.

[+Lee Stewart]

I just couldn't help myself 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

[+Vorticon]

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!

[+Vorticon]

I ended up doing one additional update which tackles the endgame specifically which is pretty weak. It's still problematic, but I think a little better now. I don't think there is much else to do, and overall I'm pretty pleased with the end result. For my own edification, I downloaded the Accolade version of Stratego for the PC from 1990 (DOS), and even at the highest level, the AI was pretty weak. As a matter of fact, I felt that my version plays better overall.

Now I can put this whole project to rest!

[Iwantgames:)]

Tried playing earlier but as I've never played Stratego before I had no idea what I was doing lol. Looks like I gotta read the manual

[Omega-TI]

Any updates on the official release?

[+Vorticon]

Still tweaking the compiled version which is much faster. Hopefully later today.

[+Vorticon]

With the help of Senior Falcon and his outstanding XB compiler, we were able to get Stratego to compile! Along the way, both the game and the compiler were enhanced, so make sure you check out the latest version of the latter, ISABELLA 2.0, under the XB development thread.

Now, Stratego runs over 6x faster, with an average response time of 10 seconds only, and it gets shorter as the number of units dwindles! The AI has been beefed up as well since compilation freed up more memory, and I even managed to uncover a couple of deep bugs within the depth of that complex code.

The game is now far more playable from a time-requirement standpoint, and I'm very pleased with the end-product.

Updated disk images and manual in the first post of this thread.

[Opry99er]

Insane.... great work!!!

[wolhess]

I played a testgame with your last version and it seems the computer AI has become much stronger.

 

The gameplay is very entertaining and exciting.

 

Thank You for this fantastic game

[+Vorticon]

I played a testgame with your last version and it seems the computer AI has become much stronger.

 

The gameplay is very entertaining and exciting.

 

Thank You for this fantastic game

 

 

Insane.... great work!!!

 

Thank you for the kind comments!

[Kurt_Woloch]

Since there was the question about some ideas how to improve, I took a bit of a peek into the code and found some locations where space could possibly be saved...

 

I took a look at the subroutine calls. Hmmm... I normally do subroutines when a piece of code gets called multiple times. However, the subroutine GENMOVE is only being called once, and then I ask myself what all these parameters are for. I can't recall exactly how the scope of variables work in XBASIC, but as far as I remember, there's no such thing as a scope, so all variables defined in the main program are visible to all subprograms as well. Which would mean to me that if a subprogram only gets called once, there's no need to use any parameters, or it could be turned into a GOSUB entirely. Same thing about SCOUTMOVE and FINDEN.

 

With CALL CHECKEN, this subroutine gets called multiple times, but some of the parameters are always the same, so those could also be stripped.

 

The line "IF CE1<>120 AND CE2<>120 AND CE3<>120 THEN keep_checking" is superfluous because these conditions get checked afterwards individually again and lead to the same outcome if none of them is true. This entire code section seems to be multiplied 4 times anyway with every iteration being pretty similar to the others, so maybe something could be condensed here as well...

 

That's just some ideas how code space could be saved, I could probably find more if given more time.