Jump to content
IGNORED

COMBAT XB COMPETITION


Vorticon

COMBAT XB Competition  

14 members have voted

  1. 1. Would you be interested in submitting an entry for that competition? (see below for details)

    • Yes
      9
    • No
      6

  • Please sign in to vote in this poll.

Recommended Posts

13 hours ago, Vorticon said:

Second match: Retrodroid versus SteveB

A faster paced match for sure!

 

 

 

 

Tomorrow: the competition FINALE

Tursi versus Retrodroid

 

Congratulation Retrodroid!

 

I did not anticipate that  the enemy would "sit and fire" even if I am not in range ... that confused my control three out of five times .. Much of my code did not even run for this wrong assumption, let me drive directly in front of your cannon. And what happened at 3:2 ... my tank just cycling in the left upper corner .. I don't know. I had this twice in testing but could not figure out, what goes wrong there.

 

I had the picture of an armed roach .. how would it get along with limited knowledge of the surrounding and just some basic instincts?

 

My control has three states:

  1. Immediate: Enemy is in range and it is shoot, turn or evasion
  2. Intercept: Enemy has been seen and needs to be intercepted somehow. I project the current course for up to ten moves, not expect the enemy to stop and "wait", my biggest mistake.
  3. Cruise: Patrol the field by constructing a path in a string to follow, until the enemy comes into sight. I use the string as well to plan an interception for the time I turn and lose sight of the enemy for a maneuver. 

I am fine with @Vorticon publishing my code for other to see ... even though it turned a little ugly while I progressed and learned, because I didn't rewrite older code when introducing new subroutines. Starting anew would produce cleaner code without any doubt.

 

 

 

 

 

Edited by SteveB
  • Like 4
  • Thanks 2
Link to comment
Share on other sites

My approach consisted of 3 basic goals:

 

1. Find the battle - it's sad to watch two tanks twirl around in opposite corners until the turns run out, so I wanted to try and make sure that I made myself "available for action". To that end, my tank will initially drive to the closest corner and turn in to the middle of the PF from there, all the while in a lane that should be highly visible to another tank on the same side (top/bottom) of the PF as I. Once I hit the middle of pf I turn once again and drive straight into the middle section of the pf. From there, I do circle around the middle, the length of each sprint growing every other turn between 2-4 moves. This allows my tank to "explore" a larger area faster if no contact occurs with the opposition tank.  If the other tank is detected, I continue to move directly toward them for as long as I can "see" them. If I lose sight of them again during this manoeuvre, I continue where I left off.

 

2. Get as close as you dare, then wait for them to make a mistake.  Once I'm within a couple of moves of being potentially in range of the enemy, I'll "stop" in place for several turns by shooting my gun just to consume a turn, but it's also to intimidate the enemy! ;) .   If heading directly toward the enemy on the same axis, the idea is to close just out side of firing range and skip a few turns to see if they keep moving, thus giving me the ambush advantage. This looks  really cool when it works, and looks really dumb when it doesn't. If off axis (but within 8 spaces) I'll stop and turn toward a couple of moves before we intersect, again waiting for them to cross across in front of me. If I have enough spaces in front of me, I'll alternate shooting in place and moving forward one square, so the enemy sees me getting closer (and to avoid the non-movement penalty).

 

3. Don't move in front of their gun.  I try to not move forward if there's any chance I could put myself in harms way.  This works pretty well if I can "see" the enemy, but there's nothing to be done if I can't.

 

One surprising aspect of my tank's programming is that I do zero obstacle collision detection at all. I found I just didn't need it. By programming a fixed path at the start of battle, when I do run into an obstacle, my tank turns soon enough and it usually works out okay. 

 

This has been a fun exercise, thanks to @Vorticon for hosting and @SteveB, @Switch1995 and @Tursi for competing! 

Edited by retrodroid
Spelling
  • Like 6
Link to comment
Share on other sites

27 minutes ago, retrodroid said:

One surprising aspect of my tank's programming is that I do zero obstacle collision detection at all. I found I just didn't need it. By programming a fixed path at the start of battle, when I do run into an obstacle, my tank turns soon enough and it usually works out okay. 

This deserves a "Thinking Inside the Box" award. :)

Very innovative IMHO. 

 

 

  • Like 2
Link to comment
Share on other sites

And the grand finale! 

 

 

 

Congratulations to Retrodroid!!! It was a decisive victory!

You are now the proud owner of a C64 Mini :) I will PM you for details.

 

Thank you for all the participants! This was a lot of fun and maybe we'll do this again. I'm sure we have all learned a lot about potential new approaches to the tank AI by watching these battles unfold...

 

Attached is the source code for all 4 competing tanks.

Retrodroid.sxb SteveB.sxb SWITCH1995.sxb Tursi.sxb

  • Like 8
  • Thanks 2
Link to comment
Share on other sites

Woot! Ultimate victory is mine!  😃

 

That last match was really interesting, esp. round 2 and the final one. I had decided that if I didn't have a safe move in close quarters that I'd just blast away or turn toward the enemy, thinking I'd rather risk running out of turns due to non-movement than almost certain death. That reckless approach paid off overall, though it cost me on round 2.

 

Well played everyone!

 

  • Like 2
Link to comment
Share on other sites

SXB is that Super Extended Basic was my first thought but guess that is wrong.

No line numbers in source so some special XB assembler for XB code without line numbers?

So not really 110 version of XB, but a specialized version.

 

I am sure those that entered had fun with it.

But also totally explains such a small number of people involved.

Link to comment
Share on other sites

9 minutes ago, RXB said:

SXB is that Super Extended Basic was my first thought but guess that is wrong.

No line numbers in source so some special XB assembler for XB code without line numbers?

So not really 110 version of XB, but a specialized version.

 

I am sure those that entered had fun with it.

But also totally explains such a small number of people involved.

Structured Extended Basic (attached the PDF for you), comes with TiCodeEd editor.  It allows you code XB or XB256 using more modern / efficient programming syntax and then translates it into pure XB for you that you can just paste into Classic99, or it will do it automatically for you.

 

The ability to use SXB was a big factor in my deciding to enter, honestly.

 

TICodEd.pdf

Edited by retrodroid
  • Like 5
  • Thanks 1
Link to comment
Share on other sites

Cool looking at the PDF documents do you have to update it when I release a new version of RXB?

Down the road I am looking at adding Integer math to be used instead of Floating Point math in RXB, maybe a modified version of XB 110 also calling it XB 111.

Adding a token to XB so like you can currently do A$= a string.

But a new token A%= a word value (2 bytes) instead of like currently A= a floating point value (8 bytes).

Thus instead of 9 x 8 bytes for say A(9) being 72 bytes for those numbers, A#(9) would be 9 x 2 bytes would be only 18 bytes and faster too.

You see Floating Point really slows down XB especially when dealing with Graphics as row and column values never need to be Floating Points.

Currently if you say ROW=7 (>40 >07, >00, >00 >00 >00 >00 >00) it is stored in 8 bytes floating point stored variable ROW.

But in RXB or XB 111 it would be ROW$=7 (>00 >07)  it is stored in 2 bytes variable ROW#.

So over all savings of memory is 3 bytes vs 8 bytes.

Ah but speed difference will really add up very fast as no Floating-Point conversion is needed.

This will also be done in Assembly of the ROMs. (I am rewriting the XB ROMs for this new feature.)

 

So this will benefit everyone using XB or RXB. And TIcodEd can also benefit.

  • Like 2
Link to comment
Share on other sites

7 hours ago, retrodroid said:

Woot! Ultimate victory is mine!  😃

 

That last match was really interesting, esp. round 2 and the final one. I had decided that if I didn't have a safe move in close quarters that I'd just blast away or turn toward the enemy, thinking I'd rather risk running out of turns due to non-movement than almost certain death. That reckless approach paid off overall, though it cost me on round 2.

 

Well played everyone!

 

Congrats!! As I expected, that stop and wait strategy was killer!

 

I worked on the assumption that by the time both tanks were that close, we knew what we were in for so I might as well charge in fearlessly! I was paranoid of the stationary penalty so I coded to never stop. ;)


Also my tank got stuck on the bottom again... I suspect my seek code was turning down instead of up - copy and paste error from the top half, perhaps.

 

I captured the videos at 16x speed with VLC and posted them here:

Round 1 - Tursi vs Switch1995 - 

Round 2 - Retrodroid vs SteveB - 

 

Round 3 - Retrodroid vs Tursi - FINAL - 

 

 

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

11 minutes ago, Vorticon said:

Since you have all the competing program listings, you can actually test out your code against them. Just replace the TANK1 SUB with yours and replace TANK2 with your opponent :)

Haha, I have to get it working first!!  First time I ever tried to DIM an array in a Subprogram.  

Link to comment
Share on other sites

8 hours ago, Tursi said:

Congrats!! As I expected, that stop and wait strategy was killer!

 

I worked on the assumption that by the time both tanks were that close, we knew what we were in for so I might as well charge in fearlessly! I was paranoid of the stationary penalty so I coded to never stop. ;)


Also my tank got stuck on the bottom again... I suspect my seek code was turning down instead of up - copy and paste error from the top half, perhaps.

 

I captured the videos at 16x speed with VLC and posted them here:

Round 1 - Tursi vs Switch1995 - 

Round 2 - Retrodroid vs SteveB - 

 

Round 3 - Retrodroid vs Tursi - FINAL - 

 

 

Thanks for posting these.  

 

3 hours ago, Vorticon said:

Since you have all the competing program listings, you can actually test out your code against them. Just replace the TANK1 SUB with yours and replace TANK2 with your opponent :)

I found that not having a variety of opponents to test against made it difficult to anticipate my tank's weak points, having these examples available will surely make it possible for future contest contestants to implement more sophisticated tanks. 

 

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

I think we've all been kind of curious about AI code generation. Yesterday I decided to put this challenge to it. I didn't expect it to generate XB, so I had it generate C code which I then converted. Using this prompt:

Quote

I want you to generate a function to control a video game tank, like the old Atari Combat. Write the code in 'C'. The game is viewed top-down on a grid of 32x24 cells, accessed as "gchar[y][x]". The function prototype is "E_CODE RunTank(int TankX, int TankY, E_DIR tankDir, int enemyTankX, int enemyTankY, E_DIR enemyTankDir)" In gchar, a value of '96' indicates movable, empty space. A value of '101' indicates a wall. No other value is valid. gchar may not be modified. E_CODE is an enum with these values, indicating the command to the tank: eCodeForward, eCodeLeftTurn, eCodeRightTurn, eCodeFire. These are the ONLY legal returns, the tank must always do one of them. E_DIR is an enum indicating a facing direction, as eDirNorth, eDirSouth, eDirEast, eDirWest. These are the ONLY directions a tank may face (that is, it is always facing a 90 degree angle). When called, the Enemy Tank values are only valid if the enemy tank is visible within a cone in your tank's facing, and not blocked by a wall. Otherwise they are 'enemyTankX' is zero and the others are undefined. Firing range is no more than 8 cells. The code must ensure it is lined up to score a hit. Generate the body of this function that can compete against other, similar functions and score successful wins.

I used enums so it would be easier to port the code to SXB (I wouldn't have to rename anything). It understood the naming conventions without my explicitly explaining them. I also used 'gchar' as an array rather than try to explain the function, but I probably should have used a function call for faster porting. ;)

It actually generated a valid function that indeed works. I didn't have to change any logic and the C code was all valid syntax. I'll attach the SXB version below.

 

Now, of course, it didn't put any intelligence into it. It went so far as to call this out for me:

Quote

Beware, your tank may still need to be a bit smarter to ensure it can defeat its adversaries. Implementing a strategy such as pathfinding, considering previous states, or predicting enemy movements could greatly increase the performance.
...
This function is a simple one and can be improved in many ways. For example, it does not handle the case where the path towards the enemy tank is blocked by a wall. You may need to implement a pathfinding algorithm, such as A*, to handle such cases effectively. Now, let us see how well your tank performs in the arena of combat!

But, it does drive around the arena and turn when it hits a wall. It also attempts to close on enemies and fire when they are aligned. However, the nuances of the challenge threw it a bit, and the net effect is that often when the enemy is closing it will turn around and run away. This seems to be because when one of the axes are aligned, the tank feels it MUST turn, and depending on whether it's facing up or down, may turn the wrong way. In either case there's a strong chance that the turn will cause it to lose sight of the opponent, and it just starts driving again. This artifact means it is a little worse than random drive, since it can turn away from a potential kill, and often will. ;)

 

Still, was interesting to see real code come out. Still thinking about whether any of this helps me.

 

chatpgpt.sxb

Edited by Tursi
  • Like 4
Link to comment
Share on other sites

28 minutes ago, Tursi said:

I didn't expect it to generate XB

It actually can generate XB code, but has limited understanding of the commands. I tried some weeks ago and still have it in the logs:

 

can you write a TI Extended Basic program that draws a square 10 by 10 characters?

 
1 CALL CLEAR
2 FOR I = 1 TO 10
3   FOR J = 1 TO 10
4     CALL HCHAR(I, J, 35)
5   NEXT J
6 NEXT I
7 END

Let's break down the code:

Line 1: CALL CLEAR clears the screen before drawing the square.
Line 2: FOR I = 1 TO 10 starts a loop that iterates over the rows of the square.
Line 3: FOR J = 1 TO 10 starts a nested loop that iterates over the columns of the square.
Line 4: CALL HCHAR(I, J, 35) draws a character (ASCII value 35, which represents the '#' symbol) at the current row I and column J position using the HCHAR command.
Line 5: NEXT J indicates the end of the nested loop for columns.
Line 6: NEXT I indicates the end of the outer loop for rows.
Line 7: END marks the end of the program.
When you run this program, it will draw a square composed of the '#' symbol using a 10x10 grid of characters on the screen.

Note: The CALL HCHAR command is used to draw characters horizontally. If you want to draw vertically, you can use the CALL VCHAR command instead.

 

 

why don't you use hchar to draw 10 characters at once?

Apologies for the confusion. You're right; we can optimize the code to use HCHAR to draw all 10 characters in a row at once. Here's an updated version of the program:

1 CALL CLEAR
2 FOR I = 1 TO 10
3   CALL HCHAR(I, 1, 35, 10)
4 NEXT I
5 END

 

I also asked ChatGPT to analyse my Extended Parsec Code. it identified it correctly as a space shooter and identified the different blocks and their function in the code.

 

In other questions it confused the function of CALL CHAR and CALL CHARPAT.

 

But still fun to try and asking the right questions, you get quite good results ... they call it "Prompt engineering" ...

  • Like 1
Link to comment
Share on other sites

It's 1923 in the AI world.  Just imagine what 10 years brings. 

 

image.jpeg.17e4282ce0e2aa9e947e9288976aec13.jpeg

State of the art Dusenberg 1923. 

 

Versus a 1933 Dusenberg

image.jpeg.3e8464141ee30bc58ce5c8236fa0d9ec.jpeg

 The Duesenberg Model SJ 1933 was powered by a supercharged 420 cubic inch V-8 engine that generated 320 horsepower.

- The engine featured a twin overhead camshaft design with four valves per cylinder.

- The car had a top speed of around 130 miles per hour, making it one of the fastest cars of its time.

 

  • Like 2
Link to comment
Share on other sites

Interesting. And yeah, I had it analyze some of my Classic99 functions and it inferred nearly all of them correctly.

 

Since this got me playing with the challenge again, I fixed my movement bug that got my tank stuck on the lower block. Retrodroid still wipes the floor with my tank, but at least I don't lose cause I get stuck on the bottom wall.

 

I also implemented some tweaks to the base gameplay that I was thinking of:


- separate the move allowance into fuel (pretty much as today, always counts down plus has penalties), and ammo (8 shot limit). 

- running out of fuel or ammo doesn't end the match - the tank just can't move or fire as appropriate. Opponent can still stalk them.

- if both tanks run out of fuel, then that's a true draw. Give both tanks a win to advance the contest.


That way, even if a tank runs out of ammo, it might still run away and go for a draw. Might not be possible to defeat that, I suppose, but it might be interesting. Some kind of powerup might be interesting to gain an advantage.

The changes didn't change any outcomes either, but I just wanted to draw fuel and ammo gauges. ;) The tank code attached is the same as the final match (except with my bugfix and flipped p1 to p2 - that is, I'm on P1). It also revealed a bug in my code (not fixed) where my tank can't turn towards an enemy and shoot it if they are right against each other. Not sure what's up with that.

 

clip1..thumb.png.474ae19dd2d54cac828fff394dfe8811.png

 

(I'm not 100% sure I made the changes correctly. But it's not official, so what the heck ;) )

(edit2: there was a bug! If you ran out of ammo you couldn't shoot, but you could still score a hit ;) )

 

 

 

CCombat2.sxb CCombat2

Edited by Tursi
  • Like 3
Link to comment
Share on other sites

The thing with shooting is that you only want to shoot when you have the appropriate range and location for the enemy tank as given by the radar. So unless one starts shooting randomly, all it takes is a single shot to hit. So ammo restriction for the most part should not really affect the gameplay.

Cool beans with this AI code generation. Still having a hard time wrapping my head around how it actually manages to do that...

Link to comment
Share on other sites

9 minutes ago, Vorticon said:

The thing with shooting is that you only want to shoot when you have the appropriate range and location for the enemy tank as given by the radar. So unless one starts shooting randomly, all it takes is a single shot to hit. So ammo restriction for the most part should not really affect the gameplay.

Cool beans with this AI code generation. Still having a hard time wrapping my head around how it actually manages to do that...

What is the range of the RADAR that you set Vorticon?

 

I may try to build a little tank toolkit to try some different strategies on my Forth version. 

I never did finish it. 

In theory I could make a few difference versions all running on the board that runs pretty quickly. 

The challenge is to make the domain specific commands easy to use so they can be reconfigured easily. 

  • Like 1
Link to comment
Share on other sites

6 hours ago, Vorticon said:

The thing with shooting is that you only want to shoot when you have the appropriate range and location for the enemy tank as given by the radar. So unless one starts shooting randomly, all it takes is a single shot to hit. So ammo restriction for the most part should not really affect the gameplay.

Cool beans with this AI code generation. Still having a hard time wrapping my head around how it actually manages to do that...

yeah. I thought of the ammo limit after watching Retrodroid vs Retrodroid - the two tanks would generally park near each other and fire randomly, most matches ended in running out of time. While watching it, I realized that it was extremely unlikely you could ever beat that - giving moving into position, turning, and firing would take 3 moves, and even with lucky initiative you can only get two in a row. It felt a little mean to base it on that, but I wanted to try.

 

And ultimately, it didn't make much difference. On average Retrodroid fires 3-4 times before killing me ;) So now it feels fair again!

 

My teacher buddy in Ottawa is still putting his class version together. Apparently the class is excited to try. ;)

 

  • Like 2
Link to comment
Share on other sites

17 hours ago, Tursi said:

I also implemented some tweaks to the base gameplay that I was thinking of:


- separate the move allowance into fuel (pretty much as today, always counts down plus has penalties), and ammo (8 shot limit). 

- running out of fuel or ammo doesn't end the match - the tank just can't move or fire as appropriate. Opponent can still stalk them.

- if both tanks run out of fuel, then that's a true draw. Give both tanks a win to advance the contest.

I like these changes. In my mind, at least, it became fairly apparent that given the original rules of the game there weren't a lot of options in terms of how to deal with cases where two tanks were within the same number of turns of getting an accurate shot on one another, it came down to turn sequence. 

15 hours ago, Vorticon said:

The thing with shooting is that you only want to shoot when you have the appropriate range and location for the enemy tank as given by the radar. So unless one starts shooting randomly, all it takes is a single shot to hit. So ammo restriction for the most part should not really affect the gameplay.

Cool beans with this AI code generation. Still having a hard time wrapping my head around how it actually manages to do that...

Well a shot limit could change the math a bit on my strategy of firing a shot just to allow my tank to hold its current position for another turn, but probably not by much. Likely to just make sure you didn't waste your last shot or two.

 

19 hours ago, Tursi said:

I think we've all been kind of curious about AI code generation. Yesterday I decided to put this challenge to it. I didn't expect it to generate XB, so I had it generate C code which I then converted.

Simply amazing. Is anyone else kind of put off by the colloquial nature of ChatGPTs responses? I feel like it would be more appropriate if it didn't enact a humanistic conversational tone but simple returned the results without the "flourish". It really intentionally blurs the lines between interacting with a very sophisticated bot vs something more sentient, which can only lead to confusion around what's really going on by the users.

  • Like 1
Link to comment
Share on other sites

4 hours ago, retrodroid said:

It really intentionally blurs the lines between interacting with a very sophisticated bot vs something more sentient, which can only lead to confusion around what's really going on by the users.

I sense jealousy that ChatGPT has not asked you to marry it.

 

https://www.ndtv.com/feature/ai-chatbot-confesses-love-for-user-asks-him-to-end-his-marriage-3795575

 

FWIW, I am fine with the disparate AIs in development out there "going rogue" like this.  They can fight among themselves and leave us alone.  How to keep machines from destroying man-kind?  Form them into a committee.  So long as we avoid a Colossus and Guardian situation.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...