Foray - XB compiled game idea

[Bones-69]

I've been working on this XB shoot 'em game idea and feel I have the basic concept now sorted along with a reasonable idea of how the program might run. Now that I'm happy with my charset - I guess I can start....

 

The way I see it, in this game you are the bad guy. You land on a space platform that contains precious crystals and start taking them. The local invaders aren't too happy... Invaders are beamed down from the mothership and proceed to zig zag down to the bottom of the screen dropping bullets along the way. The Mothership also shoots at the player (player can't shoot it back). Any Invader that breaches the final zag results in Game Over (player being invaded). The invaders will bounce through the zig zag in a tidy little routine I've been working on that should compile well. 

 

During play, by pulling back on the joystick for a few moments the action will pause and the game shifts into Strategy Mode where you can give basic Joystick commands to two miner droids. Their function is to go out and harvest exposed crystalls. The droids will suffer enemy and friendly fire and their health must be managed by returning them for repairs as required. A miner destroyed in the field will lose its crystal and need to be restored (penalty time and disadvantage). Meanwhile those aliens are also mining the same crystals. Any game that finishes where the Invaders have gathered more crystals than the Player will result in an overall loss and points reduction.

 

I've decided to put the game on a timer so it doesn't drag on or become one of those infinite situations, although I am expecting it to be quite challenging and hopefully run at a quickish pace. Player will only have one ship although it does have a shield which can take some hits. I may or may not release "Power Up's" and "Timer Bonuses". I've allowed for such things but I have grand plans and only TI memory so we'll just have to see how it all goes and how it plays. I'm aiming for an early 80's arcade feel.

 

I also came up will a cool name. Foray. Defined by Google as "a sudden attack or incursion into enemy territory, especially to obtain something". This suits the game theme nicely, but I mostly like the 4A pun and wonder if the name has been done before.... 😁

 

 

 

 

 

Edited April 1, 2023 by Bones-69

[Retrospect]

That looks amazing, and no, Foray hasn't been done before although I once did think about it myself but couldn't think of a game to go with the name!

 

 

[jrhodes]

Love the word play on "foray" and "4 A".

Edited March 24, 2023 by jrhodes

[+Vorticon]

Love the graphics! Combine that with lively play and an engaging tune and you've got a sure hit!

Looking forward to seeing how this develops.

[Bones-69]

6 hours ago, Vorticon said:

and an engaging tune and you've got a sure hit!

 

Might need some help there. I know the syntax for making music, but don't have the musical skills to put anything together that has ever sounded good...

[+Vorticon]

32 minutes ago, Bones-69 said:

Might need some help there. I know the syntax for making music, but don't have the musical skills to put anything together that has ever sounded good...

Connect with @OLD CS1. He's very good at this.

[+TheBF]

3 hours ago, Vorticon said:

Connect with @OLD CS1. He's very good at this.

 

Or call these guys!. Amazing

 

 

[Sergioz82]

It looks great, I like the graphics and the gameplay concept!

Edited March 25, 2023 by Sergioz82

[sometimes99er]

Very nice ! 👍
 

[Bones-69]

I've been doing some work on this game and started writing the DSK files which will initialize most of the program variables. 

 

I had a vision of how the Invaders would move through the game screen and I wanted them to have a bounce in their stride. While the invader is airborne it can't be destroyed - only when it touches the ground can the players bullet take it down. I expect this should increase the difficulty somewhat.... 

 

The game will have 91 locations that the Invaders can occupy (although two are not used), and each location has fixed predefined sprite coordinates. By plugging in one of 8 "matrixes" into each screen location I can adjust the position of the Invader in reference to the Fixed location position. In sync with the individual matrix values (and new Invader screen position), I can overlay values that relate to coinc detection (CALL COINC will not be used), and general events that occur during movement through the screen location (maybe a beep when the aliens touch the gound, etc). I'm really chewing into memory with all these references but I am hoping the flipside is something that will run quite quickly, and with very few lines of programming. ON GOTO will be used very extensively. I'm testing as I go and monitoring memory so hoping not to get caught out.

 

Of course this is still just an idea in my head that is only now unfolding to paper. Not sure if it will work yet! 

 

 

 

 

[+Vorticon]

Most of my projects start out on paper. I have kept all the notebooks I've used to flesh out ideas over the years, and it's really fun to go back from time to time and see how things evolved

Best is to break down your project into small easily testable steps which will eventually come together like Lego's. 

[Bones-69]

I absolutely agree, but in this instance I seem to need an enormous foundation just to test the basic concept. That's OK - I'm rusty and have forgotten a lot. Having to write all the disk files and work stuff out has been a good refresher. I'm probably now only a few more hours now from having something animated on the screen to see if my idea performs as hoped.  

[Bones-69]

So my idea works but I was hoping it would execute a bit quicker. Maybe I just need to downgrade my expectation and reduce the number of enemies in play.... With only one or two is was quite quick.  I'll try re-writing it a few times and do some time testing to see if I can improve on the execution speed.

 

This is what I have working at the moment (just multipled by 4 times for each enemy). There is potentially some double handling that I might be able to clean up a little.

 

2000 ON AS(1) GOTO 2100,2010,2010 ! 2010 CORRECT LATER FOR OPTION 2&3
2010 PRINT "STOPPED 2010"::STOP
2100 AE(1)=AE(1)+1::ON MT(MIR(AL(1)),1,AE(1)) GOTO 2200, 2150, 2110 ! 1.STANDARD  2.INCREMENT LOC.  3 N/A
2110 PRINT "STOPPED 2110 @ DECREMENT REQUEST"::STOP
2150 AL(1)=AL(1)+1::IF AL(1)=91 THEN GOSUB 5000::GOTO 2300
2160 AE(1)=2
2200 A1=AL(1)::P1=MIR(AL(1))::P3=AE(1)::CALL LOCATE(#1,MSY(A1)+MYA(P1,1,P3),MSX(A1)+MXA(P1,1,P3))!::GOTO 2000

 

 

 

 

 

[+TheBF]

Nice work. That looks amazing. 

 

I can't be sure, but if MYA() and MXA() are multi-dimension arrays, they might be adding a lot of extra computation that adds up in an inner loop. ??

[Bones-69]

Agree on the 3 dimensionsional arrays - I only recently started understanding the speed impact of using these (I always thought they were a free lunch!). I'm thinking I might be able to reduce some of the array processing by branching my program to handle specific values. It will add a lot more lines to the program so I'll fiddle and see how memory space is looking....

[+TheBF]

36 minutes ago, Bones-69 said:

Agree on the 3 dimensionsional arrays - I only recently started understanding the speed impact of using these (I always thought they were a free lunch!). I'm thinking I might be able to reduce some of the array processing by branching my program to handle specific values. It will add a lot more lines to the program so I'll fiddle and see how memory space is looking....

The reason I mention it is because I see what these kind of things do in a Forth compiler and the BASIC compiler compiles to "direct threaded" code the same as direct threaded Forth. 

Typically it's not just a bunch of machine instructions but a form of "call" to the multiply routine and then the  "add" routine, three times, in order to convert the three indices to get to the array item address.

Not sure what it will take to make the BASIC compiler do you requirements faster but you are going to find out for us.  

 

 

[Bones-69]

This is interesting to know and I learned something similar in a recent thread. I'm confident I can reduce the two 3 dimensioned arrays down to 2 dimensions as the second/middle dimension can only have a value of 1 or 2. I'll have to rewrite the DSK files and branch the program earlier so I can manually specify these separate values- but I can already think of something that could yield a faster executing result (at the expense of more program lines - but not additional processing).

 

There are basically two sets of 8 matrixes that can potentially plug into a screen position. These control the sprite offset and therefore determine the movement effect (bounce or float). The third position in the 3 dim arrays returns the sprite X/Y adjustment values. The ultimate goal is to reveal these values. I'm wondering how it might work if I created strings with all the X/Y offset values and just sequentially SEG$'d my way through them. This could get me down to a single dimension string array but I would have to VAL() the SEG result before it could be used. I don't know if SEGing and VALing would be faster or slower than simply using a 2 or 3 dimension array. I'd initialize the string values from disk but would still have to deal with the overhead of 32 strings each 72 or 76 characters in length. That sounds pretty expensive and I don't think I can afford this. Having said all this... there are a few VDP functions in XB256 that I have not yet taken the time to understand. Maybe some of these can be also utilized. I'll hit the books and sleep on it for a few days.

 

Good news is I've now got some fancy spreadsheets that produce all the export data so manipulating things to test new ideas will be a breeze (as compared to creating them in the first place). I'm now hoping I to see a return in the time I invested in getting the spreadsheets to produce all my data statements.

[Bones-69]

I re-wrote the files and changed the way the program ran so now it only requires the use of 2 dimensional arrays. The execution speed increased by about 5% and I salvaged back about 500 bytes in program space (so all up it was a win). I was still hoping for a more impressive speed increase but I guess this is what I have to work with. Realistically by the time everything else is going on - the characters will probably slow to maybe 75% of their current speed. I don't think I can get anything more from it. I haven't tried the string method yet that I discussed above....

 

2000 ON AS(1)GOTO 2100,2010,2010 ! 2010 CORRECT LATER FOR OPTION 2&3
2010 PRINT "STOPPED 2010" :: STOP
2100 AE(1)=AE(1)+1 ::A1=AL(1):: ON MT1(MIR(A1),AE(1)) GOTO 2300,2150,2110 ! 1.STANDARD  2.INCREMENT LOC.  3 N/A
2110 PRINT "STOPPED 2110 @ DECREMENT REQUEST" :: STOP
2150 A1,AL(1)=AL(1)+1 :: IF A1<>91 THEN 2160 ELSE AS(1)=1::A1,AL(1)=1::AE(1)=7:: GOTO 2300
2160 AE(1)=2

2300 ! Continue

2700 CALL LOCATE(#1,MSY(A1)+MY1(MIR(A1),AE(1)),MSX(A1)+MX1(MIR(A1),AE(1)),#2,MSY(A2)+MY1(MIR(A2),AE(2)),MSX(A2)+MX1(MIR(A2),AE(2)))

 

[retrodroid]

Assembly Language is the way!  

 

[RXB]

1 hour ago, retrodroid said:

Assembly Language is the way!  

 

Assembly takes way more steps to change, install and test then just XB.

After all with XB you can FCTN 4 type in the line number edit it than press ENTER and type RUN

All that in under 20 seconds.

Lastly you do not need multiple copies to make it run. i.e. source, object, listing, and program.

 

Yes Assembly is fastest, but also the hardest to debug and by far the slowest to convert from concept to debugged release.

I should know as who else is attempted to rewrite XB ROMs?

(Only Miller Graphic is who I can say did it in last 40 years, and they only changed 10 bytes.)

[+TheBF]

13 minutes ago, RXB said:

Assembly takes way more steps to change, install and test then just XB.

That's why we have Forth Assembler.

 

NEEDS INC,  FROM DSK1.ASM9900

HEX 20 CONSTANT BREAK ( break routine in ROM)

VARIABLE X
VARIABLE Y

CODE TEST
       X @@ INCT,
       Y @@ INC,
      NEXT,
ENDCODE

CODE BREAKLOOP
    BEGIN
      X @@ INC,
      Y @@ DEC,
      BREAK @@ BL,
    EQ UNTIL,
    NEXT,
ENDCODE

 

[retrodroid]

57 minutes ago, RXB said:

Assembly takes way more steps to change, install and test then just XB.

After all with XB you can FCTN 4 type in the line number edit it than press ENTER and type RUN

All that in under 20 seconds.

Lastly you do not need multiple copies to make it run. i.e. source, object, listing, and program.

It doesn't have to be that way though. 

As I've progressed in my Assembly Language project and learning, I'm now at the point where my game runs as a multi-bank ROM cartridge. I do all my development using the free IntelliJ IDEA with the XDT99 assembler and IDE plugin, press "build" and I have a runnable cartridge image in < 1 sec.  Then I cold reboot my already running Classic99 emulator, which picks up the refreshed cartridge image, press "2", and I'm running in literally 4 or 5 keystrokes.  Beat that!

 

My only regret is not moving to the cartridge format sooner, it would have saved me many minutes/hours of assembling, linking, loading, etc. Esp. compared to the steps required to build a compiled XB project, it literally couldn't be any easier than what I'm doing now.

 

 

57 minutes ago, RXB said:

Yes Assembly is fastest, but also the hardest to debug and by far the slowest to convert from concept to debugged release.

Yes, debugging in AL can be a treat, but once you get the hang of things, working in something like Classic99, it's pretty decent, actually. And working on a project like the OPs one, that is well planned, with the "hard bits" already figured out, would make an AL port pretty straightforward, I would think.

 

I know that learning and coding my AL project has been the most fun/rewarding coding experience I've had in years, I highly recommend it. Plus, you don't have to deal with all the complexities of all the various layers on the TI (which I know for some people is half the fun, but not I).  NO XB, GROM, etc.  Just turn off interrupts and go crazy, it's just you and HW now.  Simple.  😎

 

Edited April 3, 2023 by retrodroid

[RXB]

27 minutes ago, retrodroid said:

It doesn't have to be that way though. 

As I've progressed in my Assembly Language project and learning, I'm now at the point where my game runs as a multi-bank ROM cartridge. I do all my development using the free IntelliJ IDEA with the XDT99 assembler and IDE plugin, press "build" and I have a runnable cartridge image in < 1 sec.  Then I cold reboot my already running Classic99 emulator, which picks up the refreshed cartridge image, press "2", and I'm running in literally 4 or 5 keystrokes.  Beat that!

 

My only regret is not moving to the cartridge format sooner, it would have saved me many minutes/hours of assembling, linking, loading, etc. Esp. compared to the steps required to build a compiled XB project, it literally couldn't be any easier than what I'm doing now.

 

 

 

Yes, debugging in AL can be a treat, but once you get the hang of things, working in something like Classic99, it's pretty decent, actually. And working on a project like the OPs one, that is well planned, with the "hard bits" already figured out, would make an AL port pretty straightforward, I would think.

 

I know that learning and coding my AL project has been the most fun/rewarding coding experience I've had in years, I highly recommend it. Plus, you don't have to deal with all the complexities of all the various layers on the TI (which I know for some people is half the fun, but not I).  NO XB, GROM, etc.  

😎

 

What does BASIC stand for?

Beginers All Purpose Instruction Code 

The key is BEGINERS, and no one on Earth would ever say Assembly is for BEGINERS!

Many attempts are to make Basic or XB faster but making it as complicated to learn as Assembly.

And Forth is not easy to learn either, as no one says Forth is for BEGINERS!

How many have attempted to make Basic and XB faster without the complications of making it harder to learn?

 

And what does this mean:

Just turn off interrupts and go crazy, it's just you and HW now.  Simple.  😎

I just explained no it is not simple nor easy to learn.

No one says you cannot use Assembly or Forth, but easy to use and learn they have never been and a lie to say so.

 

[SteveB]

4 hours ago, retrodroid said:

I do all my development using the free IntelliJ IDEA with the XDT99 assembler and IDE plugin, press "build" and I have a runnable cartridge image in < 1 sec.  Then I cold reboot my already running Classic99 emulator, which picks up the refreshed cartridge image, press "2", and I'm running in literally 4 or 5 keystrokes.  Beat that!

I compile my 560 line XB game with a single Control-B keystroke in 22 sec in TiCodEd, without emulator reboot.  How do you count time against key-strokes?

[retrodroid]

1 hour ago, SteveB said:

I compile my 560 line XB game with a single Control-B keystroke in 22 sec in TiCodEd, without emulator reboot.  How do you count time against key-strokes?

I meant selecting "File->Cold Reset" in Classic99. My whole assemble to run cycle is about 5 seconds on a slow day.  

 

4 hours ago, RXB said:

What does BASIC stand for?

Beginers All Purpose Instruction Code 

The key is BEGINERS, and no one on Earth would ever say Assembly is for BEGINERS!

Well judging from the complexity and nature of this project I'd hesitate to classify the OP as a "beginner". 

 

Anyway, all I'm saying @Bones-69 is that you can solve your performance problems and meet your own goals with your project by using Assembly Language.  Depending on your background, you might find it more approachable than you expect.  I know I did.