Entry 2020: Space Combat

[fsuinnc]

OK, for all those new programmers out there feeling like their efforts may not be up to the high standards this contest requires, I've lowered the bar.  Stealing code from my own Planetoid, Nano Chess's "Raiders" (from his awesome book), an Acceleration and Velocity example Joe Zbiciak shared with me (even though I don't understand all of it) and probably some other sources from this board.  I present Space Combat.  I'm sure some of you can tell that this is a simple game that could be thrown together in an evening. So, you will be happy to know I've been working on it for weeks.  (not constantly, but it took way longer to get this far than it should have.)

 

I'll post a rom soon.  I haven't tried it on real hardware just yet. I also haven't used IntyBASIC in about two years and I feel like as easy as it is, I'm having way too problems. Apparently my mind 57 doesn't hold info like it did at 55.

 

Edited November 23, 2020 by fsuinnc

[+cmadruga]

Awesome! So will it be possible to play against the computer?

[+DZ-Jay]

9 hours ago, fsuinnc said:

OK, for all those new programmers out there feeling like their efforts may not be up to the high standards this contest requires, I've lowered the bar.  Stealing code from my own Planetoid, Nano Chess's "Raiders" (from his awesome book), an Acceleration and Velocity example Joe Zbiciak shared with me (even though I don't understand all of it) and probably some other sources from this board.  I present Space Combat.  I'm sure some of you can tell that this is a simple game that could be thrown together in an evening. So, you will be happy to know I've been working on it for weeks.  (not constantly, but it took way longer to get this far than it should have.)

 

I'll post a rom soon.  I haven't tried it on real hardware just yet. I also haven't used IntyBASIC in about two years and I feel like as easy as it is, I'm having way too problems. Apparently my mind 57 doesn't hold info like it did at 55.

 

 

It looks like it could be lots of fun between two players, sort of like a "space duel."

 

 

And don't worry about spending weeks on simple stuff; it happens to us all.  Not all of us can be superstars like Nanochess and Joe Z.  The world still needs mere mortals like us to vacuum the red carpet and bring them coffee.

 

   -dZ.

[Zendocon]

This could turn out to be another Biplanes.  Very promising indeed.

[fsuinnc]

8 hours ago, cmadruga said:

Awesome! So will it be possible to play against the computer?

Currently planned as two player but only.  I would like to make a 1 player version but Not sure I can figure out the AI to make that happen.

[+DZ-Jay]

1 minute ago, fsuinnc said:

Currently planned as two player but only.  I would like to make a 1 player version but Not sure I can figure out the AI to make that happen.

If you are interested I could help with some simple ideas for AI. :)

 

     -dZ.

[fsuinnc]

14 hours ago, DZ-Jay said:

If you are interested I could help with some simple ideas for AI.

 

     -dZ.

Appreciate the offer.  If I can get over my extremely lazy streak and decide to make the effort sometime during the holidays I will take you up on it.

[fsuinnc]

I know everyone has been on pins and needles waiting for me to upload a playable version, so here it is.  I was able to play it with my daughter on real hardware yesterday and it seemed to work ok. Controls are pretty basic and I doubt instructions are needed but I have thrown some together anyway. 

The game isn't finished, but here is the current version. 

 

Space_Combat.rom

 

Space Combat with Instructions.zip

[Mik's Arcade]

i wish I had something playable for the contest.  I'm stuck at the moment, hitting the book again. Too much stuff I don't get and want to figure out before I plug away again.

 

I guess my 51 year old mind is not as good as when it was 50...lol

[fsuinnc]

2 hours ago, Mik's Arcade said:

i wish I had something playable for the contest.  I'm stuck at the moment, hitting the book again. Too much stuff I don't get and want to figure out before I plug away again.

 

I guess my 51 year old mind is not as good as when it was 50...lol

you still have almost two months. If you have questions, asking them in the programming section.  The people around here love giving answers.  I'm about to start asking about sounds and music because I just can't make the sounds work the way I want them to. (my lack of understanding obviously)

 

I'm also trying to move this Space Combat game to Foreground/background mode so I can have some stars and maybe an occasional planet to fly behind or something but I have never used FB/BG and I am finding it quite different.

[+DZ-Jay]

7 hours ago, fsuinnc said:

I'm also trying to move this Space Combat game to Foreground/background mode so I can have some stars and maybe an occasional planet to fly behind or something but I have never used FB/BG and I am finding it quite different.

Why do you need FG/BG mode?  The things you mention can be done in Color Stack mode as well ...

 

      -dZ.

[fsuinnc]

6 hours ago, DZ-Jay said:

Why do you need FG/BG mode?  The things you mention can be done in Color Stack mode as well ...

 

      -dZ.

I don't need FG/BG, just some misunderstanding on my part.  Trying to put some stars or something in the background and thought that was the way to do it. I was playing with Intycolor to make some tiles to randomly throw and give some background. Had some fun playing with it but found FG/BG wasn't the way to go. 

 

but I am using some tiles from Intycolor I created and they create a very basic star field but for some reason the sprites used for the ships and missiles no longer work. I'm not sure what I did there.  

 

Update: I got my little sprites working with "stars" in the background. For some reason loading my original sprites as I was and then loading the 4 background bitmaps starting at DEF20 through things off with regard to my ship bitmaps.  Well, it through me off.  Loading them all together works fine.  I had no reason to load them at 20 but in my playing with IntyColor I was messing around and just thought I would do it.

 

Not sure I'm super happy with the stars. I need to play with the colors a bit maybe.

Edited December 6, 2020 by fsuinnc
update

[+DZ-Jay]

On 12/6/2020 at 11:11 AM, fsuinnc said:

I don't need FG/BG, just some misunderstanding on my part.  Trying to put some stars or something in the background and thought that was the way to do it. I was playing with Intycolor to make some tiles to randomly throw and give some background. Had some fun playing with it but found FG/BG wasn't the way to go. 

 

but I am using some tiles from Intycolor I created and they create a very basic star field but for some reason the sprites used for the ships and missiles no longer work. I'm not sure what I did there.  

 

Update: I got my little sprites working with "stars" in the background. For some reason loading my original sprites as I was and then loading the 4 background bitmaps starting at DEF20 through things off with regard to my ship bitmaps.  Well, it through me off.  Loading them all together works fine.  I had no reason to load them at 20 but in my playing with IntyColor I was messing around and just thought I would do it.

 

Not sure I'm super happy with the stars. I need to play with the colors a bit maybe.

I don't quite understand what you mean about the DEF20 thing.  Could you post some code and maybe we can assist in finding what was wrong?  To be honest, you shouldn't have to update GRAM for everything on every cycle, just those cards that need to change.

 

Also, if you'd like to share some screenshots, that would be nice. :)

 

      -dZ.

[carlsson]

DEF20 refers to constants.bas, GRAM number $14 if you think in hexadecimal, obviously 20 in decimal.

[+DZ-Jay]

53 minutes ago, carlsson said:

DEF20 refers to constants.bas, GRAM number $14 if you think in hexadecimal, obviously 20 in decimal.

I got that.  I just didn't quite understand what was the problem.  Was it that he was loading too many GRAM cards on the same cycle?

 

There is an easy way to find out:  Enable the debugger in the emulator and issue the command "^" (show GRAM dropped writes) in the prompt, followed by "r" (run).  It the debugger should tell you if writing to GRAM failed at any point, and where, due to the VBLANK access window ending.

 

If you are using the IntyBASIC SDK, you can enable the debugger using the "INTYDBUG" command.  If not, you can just issue the option "-d" at the command prompt when running the emulator.

 

     -dZ.

[fsuinnc]

12 hours ago, DZ-Jay said:

I got that.  I just didn't quite understand what was the problem.  Was it that he was loading too many GRAM cards on the same cycle?

 

There is an easy way to find out:  Enable the debugger in the emulator and issue the command "^" (show GRAM dropped writes) in the prompt, followed by "r" (run).  It the debugger should tell you if writing to GRAM failed at any point, and where, due to the VBLANK access window ending.

 

If you are using the IntyBASIC SDK, you can enable the debugger using the "INTYDBUG" command.  If not, you can just issue the option "-d" at the command prompt when running the emulator.

 

     -dZ.

I think the original issue was just a lack of understanding on my part of how FG/BG works and it's limitations.  I still don't really know the usefulness of it compared to color stack mode.  So, I don't know why when using FG/BG that I had problems. I had just a few tiles and I just randomly put a star tile or a blank tile  to fill in the stars on the screen. Works great. But when I display the sprites for the ships I don't see the ships I had loaded.  Reading a little more I found that FG/BG is limited in the number of GRAM tiles it can access. I don't think that was my issue but that's when I realized that I can do the stars in Color stack mode exactly the same and I don't need FG/BG. 

When I was playing with IntyColor the fantastic tutorial document shows all the options and gives an example of how to use the -oxx and says "say the first 19 are for sprite data. Setting the offset to 20 would start the Screen_cards definition at GRAM card 20."  Well, I'm only using 7 sprites but thought I would do that anyway just to try something. I had my two define statements and I still think it should have worked but loading the stars starting at 20 messed up the sprites I was using elsewhere.  I doubt it had anything to do the bitmaps and I'm pretty sure I just keyed something incorrect but frustration got the better of me so I just removed one of the tags and loaded all the bitmaps with one define statement and suddenly it worked. (well, works as well as I expected).

 

Here is the most recent version of the code and ROM. I think the onlything I changed to get it to work was change the first DEFINE statement to load 13 bitmaps instead of 8 and commented out the second DEFINE statement.

Space_Combat_20201208.bas

space_combat_20201208.rom

 

So, what is FG/BG used for compared to color stack mode?  someone commented several years ago when I first starting work on the Stunt Cycle game that I brave to do it in color stack mode. I guess I don't understand the advantages of FG/BG or what kind of game(s) it might excel at (per se).

[+DZ-Jay]

30 minutes ago, fsuinnc said:

So, what is FG/BG used for compared to color stack mode?  someone commented several years ago when I first starting work on the Stunt Cycle game that I brave to do it in color stack mode. I guess I don't understand the advantages of FG/BG or what kind of game(s) it might excel at (per se).

 

For what it's worth, I prefer Color Stack myself.  However, both modes have their advantages and limitations.  In Color Stack, the BACKTAB can use all GRAM and GROM, but the background colors of cards are limited to the four sequential colors in the stack, and there are some limitations on the colors available to GROM cards.

 

In FG/BG mode, you get independent background colors for each card, which can use all 16 colors, but the foreground color is limited to the primary set.  However, the biggest limitation of this mode is that you can only access the first 64 cards of GROM for both BACKTAB and MOBs.

 

Essentially, Color Stack is more flexible graphically and limited in colors; while FG/BG is more flexible in colors but more limited graphically.  However, a clever hand can make beautiful artwork and scenes in either mode.

 

I personally find Color Stack more powerful because the color limitations can be worked around with some clever tricks like reverse-video and MOB overlays; but nothing in the world can make FG/BG access more graphic pictures than the 64 GRAM cards and the ASCII set of GROM.  I rather have access to the full GROM to gain more picture variety. :)

 

      -dZ.

[carlsson]

I've tried to wrap my head around Color Stack, but never quite understood how cycling the stack works in practice. To me, FG/BG is far more straightforward and better resembles all other systems I've dipped my toes into. Yes, both modes have their pros and cons. As for accessing the full GROM, I'm still not convinced there is so much to use except for lower case letters. The graphic symbols look good on the surface but at least I quickly find that very few of those are practical to use, of course depending on which type of game you are making.

[+DZ-Jay]

1 hour ago, carlsson said:

I've tried to wrap my head around Color Stack, but never quite understood how cycling the stack works in practice.

 

Here's an old explanation I provided some time ago on how it works.  It may not seem as intuitive as most other "bitmap" graphical systems, but it very similar in spirit to how painting programs work.  Think of the Color Stack background colors as "flood fill" of backgrounds, and the "Stack Advance" flag as the boundary where you switch colors to continue "flooding."

 

 

 

 

1 hour ago, carlsson said:

To me, FG/BG is far more straightforward and better resembles all other systems I've dipped my toes into. Yes, both modes have their pros and cons. As for accessing the full GROM, I'm still not convinced there is so much to use except for lower case letters. The graphic symbols look good on the surface but at least I quickly find that very few of those are practical to use, of course depending on which type of game you are making.

 

If you think of the GROM graphical cards as purely "geometric shapes" to fill patterns, you end up with "programmer art" scenes, which understandably, may not be precisely what you want.  What I do instead is try to align my scene to tile boundaries in a somewhat "organic" way and exploit the fact that geometric shapes do occur in our natural surroundings, and sometimes even fit to cover certain regions.

 

Essentially, I design my "ideal" scene, rip it into tiles, then try to match as much as possible each tile to a commensurate GROM card, sometimes slightly adjusting the other tiles around it in order to make them "fit."  It's time consuming and a lot of effort, but it's quite effective, in much the same way that exploiting the four-color-per-8x8-tile in a C=64 has been used to create very impressive scenes.  I've even used a GROM lower-case letter on a MOB, slightly offset from the background grid, to cover a spot in a scene; something which would be impossible in FG/BG mode.

 

Let us be clear, GROM cards are not just special-purpose shapes like clubs and diamonds; the set includes useful pictures like lines of various width and offsets, triangles, small blocks at differing alignments, etc. -- all of which may occur to some degree or another in any part of some random scene -- and that's before considering actual stamp-patterns.

 

Something as innocuous (and exceedingly useful) as an 8x8 solid block (card $5F) is out of limits in FG/BG mode.  Now, this is mitigated by more background colors being available in that mode; but in Color Stack mode, you can actually fill the sections of your background with actual pixels of a solid color with no GRAM cost whatsoever.

 

Highly complex scenes can be built with Color Stack by cleverly mingling GRAM and GROM cards and exploiting color variance between them.

 

Is it better than FG/BG?  It depends on your expectations of what "better" means.

 

If you feel, like I do, constrained by the graphical potential of only 64 custom GRAM cards, then Color Stack opens up a whole new world of possibilities with GROM shapes.  If you feel that it is too hard and cumbersome to manage a set of only four background colors which -- to add insult to injury -- can only be used in sequence; then FG/BG offers a larger universe of colors.

 

Both are perfectly good and valid positions to take.  Like we say in Spanish, "para los gustos, los colores"; which translates roughly to "for every taste, a color," and has a similar meaning to the English idiom, "horses for courses." :)

 

     -dZ.

[fsuinnc]

OK,I know it's not the greatest thing since sliced bread, but here is a small update.  Not much in the way of improvements but players can now choose between two different types of space ship. Not much but hey, it's free right. Anyway, here's the latest rom.

 

Space_Combat.rom

[digress]

Cool. I like the colourful stars.

 

1 suggestion. I would like to be able to turn at the same time i am thrust or firing.

[fsuinnc]

17 hours ago, digress said:

Cool. I like the colourful stars.

 

1 suggestion. I would like to be able to turn at the same time i am thrust or firing.

I would like that too.  I'll see what I can do.

[fsuinnc]

On 12/21/2020 at 10:17 PM, digress said:

Cool. I like the colourful stars.

 

1 suggestion. I would like to be able to turn at the same time i am thrust or firing.

Latest ROM

 

Ok. I think you can now turn while you thrust or fire. (But you can't do all three at once. I can't get that to work).  Added an option for guided missiles which makes the bullets always travel in the direction the ship is facing. It doesn't work well when it bounces off the edge as it immediately returns to the direction prior to the bounce (if the ship is still pointed in that direction). Haven't played it on real hardware in a while so might not behave as well as I think it does.

 

Space_Combat.rom