I'm looking to make my first intellivision game and trying to gauge design limits (repost from wrong forum area)

[8bitwidgets.com]

Hi everyone, so I have an idea for a game (famous last words)  It would at it's core basically be a kind of "spy hunter" game.  So taking games I know and love from my intellivision I went straight to Bump n' Jump which not only shares the vertical movement with cars, but collisions would be a thing though not as exaggerated as in BnJ.  

 

So one of the biggest first questions overall would be how many vehicles could i get on the screen realistically.  I'm actually looking to use intybasic so that might be another limiting factor (not sure how great performance is with that vs. straight assembler)..  like is intybasic 50% as fast.. 80% as fast..  does assembly allow more sprite / etc.. 

 

I'm happy to go into more about the game, but maybe that's TMI (please, not another "game idea" ) I'm concerned I may just need too much on the screen for an intellivision..  i may have to strip down the concept to insure it fits..  so knowing limits will be the first step to not make a game the hardware couldn't possibly deliver on.  

 

Bonus question.  Are there tools to convert images from say.. png or other formats that could translate to the raw code needed.. i'm thinking of full screen cut scenes / intro story graphics that could get kinda complex to fully realize through strict code..  maybe there are clever low tech approaches other artists have used to keep things straight?  maybe tools like intybasic have something that does this.  

 

 

Thanks!

Caleb

[+DZ-Jay]

Hello, Caleb,

 

Here are a few quick thoughts that may or may not put your mind at ease.

 

• IntyBASIC is a compiled language, so it is not like the interpreted BASIC in old micros.  It compiles into assembly language which, it turns out, is rather efficient.
  
  Sure, hand coding assembly code may turn out to be faster, but not necessarily by much; and it will certainly be much harder to write, troubleshoot, and debug.
   
• The Intellivision supports 8 hardware sprites, which we call MOBs, for Movable Object Blocks.  These are of a single color, 8x8 pixels, and support 2x scaling horizontally or vertically.
  
  MOBs can also be 8x16, and can be rendered at single or double vertical resolution.  That is, an 8x16 double-res sprite will display its pixels at 1/2 the size vertically.  This affords a bit more detail.
   
• The hardware sprites can be accessed from IntyBASIC just as well as from assembly language.
   
• Because the size and color of sprites is limited, sometimes you may want to overlay multiple MOBs to represent a single game object.  That’s the way that games can have multi-colored or very large sprites.  Just keep that in mind, because that will limit the number of objects you can display in your game.
   
• Don’t worry too much about the number of objects in your game.  Obviously, as a starting point, you should design your game for the strengths of the platform; but if it comes to that, there are tricks that can be employed to give the illusion of multiple objects.
  
  However, in my experience, the 8 object limitation is only a big deal when compared to other platforms.  The Intellivision is perfectly capable of rendering awesome games with amazing game-play and cool visuals with only those 8 MOBs.  Great things have been done with less.
   
• Take a look at IntyColor, which comes with the compiler.  It is a tool that translates a BMP into IntyBASIC or assembly data statements for your game.

 

All that said, a Spy Hunter inspired game for the Intellivision would be a great addition to the canon of the platform.  If you search the forum, you may even find some mock up screenshots that someone made in the past (although no game came of it), to give you an idea of what can be done.

 

Also, since you mentioned it, take a critical view at Bump n’ Jump, which illustrates how you can make exciting game-play and impressive visuals within the limits of the hardware — and that is a title made almost 40 years ago!  We’ve learned a thing or two about how to squeeze more performance from our little CPU since then.

 

Good luck, and keep us posted!  Also ask any technical questions you may have.

 

   dZ.

Edited August 18, 2021 by DZ-Jay

[8bitwidgets.com]

Awesome thanks so much for those pointers!   Great to hear intybasic isn't the BASIC you knew what i was concerned about.  

 

OK so if you don't mind, help me understand how games like Mission X had so much detail on the ground and still have a number of MOBs (player and rockets)..  

 

For example, you said 8 sprites, but is that 8 unique sprites that could be copied?  

 

My challenge is that i was looking to make a game that has a convoy of friendly vehicles being approached and attacked by enemy vehicles..  TLDR:  Road Warrior Tower Defense..  

 

So is it possible that maybe the player has a tanker (mother ship) and escort vehicles that could be moved around the screen independently..  (i'm thinking that = 2 sprites)

 

then the enemy vehicles could be of a limited variety, let's say a motorcycle and pickup truck (2 sprites)

 

Then you have your scrolling background (basically just random dirt blocks / road) for the scrolling background (2 sprites)

 

then some kind of bullet fire (1 sprite)

 

and an explosion when hitting a target (1 sprite)

 

Is that plausible?   this is an early html5 prototype i did .. obviously i'm not expecting mounted rotating turrets and such..  just have a bullet at any given time shooting at enemies or from enemies to player

 

https://part12studios.com/part12studios.com/misc/games/rd/rd_physics_09/    (drag blue car around to reposition it)

 

https://part12studios.com/part12studios.com/misc/games/rd/rd_path_test_02/  (this was a pathfinding test, i wouldn't have enemies do pathfinding as i know that would be expensive, this would be much more "dumb mobs moving in straight paths to attack till destroyed" 

 

I just imagine using the keypad to select which convoy member you want to activate and then navigate to a new location (maybe use the same vehicle as the marker, but alternate color too much?)

 

Edited August 18, 2021 by Caleb Garner

[+cmadruga]

For what is worth, I just responded to your original message at the main forum.

[+cmadruga]

Your game idea reminds me of this WIP. 

 

 

[+DZ-Jay]

1 hour ago, Caleb Garner said:

Awesome thanks so much for those pointers!   Great to hear intybasic isn't the BASIC you knew what i was concerned about.  

 

OK so if you don't mind, help me understand how games like Mission X had so much detail on the ground and still have a number of MOBs (player and rockets)..  

In Mission X, the background objects are drawn on the background.  Their moving is a function of the scrolling technique.  Only the more complex enemies are using MOBs to move independently from the background.

 

1 hour ago, Caleb Garner said:

 

For example, you said 8 sprites, but is that 8 unique sprites that could be copied?  

 

The eight sprites limitation means only 8 at one time on the screen.  You can reposition them and you can change the picture they use for the object.

 

1 hour ago, Caleb Garner said:

My challenge is that i was looking to make a game that has a convoy of friendly vehicles being approached and attacked by enemy vehicles..  TLDR:  Road Warrior Tower Defense..  

 

So is it possible that maybe the player has a tanker (mother ship) and escort vehicles that could be moved around the screen independently..  (i'm thinking that = 2 sprites)

 

Sounds right.

1 hour ago, Caleb Garner said:

 

then the enemy vehicles could be of a limited variety, let's say a motorcycle and pickup truck (2 sprites)

 

Sounds right as well.  You could alternatively draw some of the objects in the background, rather than using sprites for them.  It depends on the complexity of their movements.

 

Typically, you would reserve the hardware MOBs for things that need to move over the background, independently from it, in more complex ways than just across axes.

 

1 hour ago, Caleb Garner said:

 

Then you have your scrolling background (basically just random dirt blocks / road) for the scrolling background (2 sprites)

 

then some kind of bullet fire (1 sprite)

 

and an explosion when hitting a target (1 sprite)

 

Sounds right.  You could reuse the bullet MOB for the explosion.  You could stagger the firing of your enemies (or of the player) to ensure only a set number of bullets need to be rendered at a time.  You could also multiplex their positions at 1/2 the screen refresh rate, which adds flicker but could be effective for small and fast objects.

 

1 hour ago, Caleb Garner said:

Is that plausible?   this is an early html5 prototype i did .. obviously i'm not expecting mounted rotating turrets and such..  just have a bullet at any given time shooting at enemies or from enemies to player

 

https://part12studios.com/part12studios.com/misc/games/rd/rd_physics_09/    (drag blue car around to reposition it)

 

https://part12studios.com/part12studios.com/misc/games/rd/rd_path_test_02/  (this was a pathfinding test, i wouldn't have enemies do pathfinding as i know that would be expensive, this would be much more "dumb mobs moving in straight paths to attack till destroyed" 

 

I looked at your prototypes and I will say they are perfectly doable.  Also, there is no reason why you couldn't implement proper pathfinding.  You may want to simplify your algorithm for performance reasons, but depending on the game, pathfinding may not need such perfect accuracy or thorough computation.  It may also not require twitch-reflex timing, so it could be spread out across frames.

 

In any case, you do not have to sell your game short on AI.  Take a look at some of the projects that have been done already.  Consider that almost all games released for the Intellivision in the past few years -- with very few exceptions -- have been written in IntyBASIC.

 

1 hour ago, Caleb Garner said:

I just imagine using the keypad to select which convoy member you want to activate and then navigate to a new location (maybe use the same vehicle as the marker, but alternate color too much?)

 

That could work.

 

I would lean on any suggestions from people like @cmadruga, @nanochess, and others in this forum, who are very proficient in the language, having made several successful (and highly impressive) titles already.  @nanochess himself is the author of IntyBASIC.

 

   dZ.

[8bitwidgets.com]

@cmadruga yea cool indeed.  reminds me of "convoy" a PC pixel based side scrolling kinda game.. 

 

we originally conceived this idea in 2006.. inspired by road warrior and games like speed rumbler..  and over the years have tried several iterations (unsuccessfully) even as early as flash with papervision 3d.. and some 2d versions..  but yea our latest iteration is stalled due to our developer hitting a wall with pathfinding / ai stuff but we're still working on it and atm waiting for a new plugin we believe will be the silver bullet we've needed to get back on track..    It is a more ambitious project than obviously what i'm aiming for with intellivision..   but the website will remain consistent.. https://www.roaddefender.com/ 

  

 

@DZ-Jay thanks for that clarity.  so yes my hope was that a single "sprite" could be broken into numerous copies of itself and move around..  my mind went to games like Space Armada which have more than 8 sprites on them, but i get that they are all moving in unison.. vs. say.. galaga which has sprite copies moving around independently not all moving in unison.  

 

where i think i'm wrong is that imagine this list of sprites and how they are used numbered 1 - 8 sprite slots and i'm taking the scrolling background into consideration now, but i'm restating some of it because i think i'm wrong but hoping i'm not.. lol:

 

1. tanker cab 

 

2. tanker trailer (was running out of must have ideas if my use of #2 was viable) 

 

3. escort vehicle 1 (i would want to have say.. 3 copies of these so i could position them around the tanker) but this is where i'm talking about how space armada has many objects on screen even though of course there are only 8 unique objects on screen.  

 

4. escort vehicle 2 (upgraded that i could have say 2-3 of those on screen) 

 

3. enemy 1 (i could see these both swapping out like escort vehicles maybe 2-3 copies of this on the battlefield at once)

 

4. enemy 2 (like enemy one a couple copies of these moving around to create some variety, maybe both changing colors as enemies get tougher) 

 

5. bullet

 

6. explosion

 

7. oil slick (maybe a few of these in a line like spy hunter arcade game)

 

8. overpass graphic (iffy on that one)

 

background would be the road and such as seen in games like bump in jump.. maybe a kind of middle gray strip with lines pretty much like the take off pad for Mission X

 

 

 

now if i understand the harsh reality that i can't do the kind of "rubber stamp" of sprites to be used in game here's another iteration of sprite usage in game:

 

1. tanker cab 

 

2. tanker trailer 

 

3. escort 1

 

4. escort 2

 

5. enemy 1

 

6. enemy 2

 

7. enemy 3

 

8. projectile / explosion (game won't be fast shooting action, but slower firing and a bit more "back and forth" sharing the bullet.  

 

background would be road and such (i assume scores are baked into the background as well?  

 

 

now regarding variety of enemies.. i notice that a lot of games (like bump n jump) have 5 enemy sprites (3 sprites/colors used on player vehicle ) they never varied the enemies colors / behaviors later.  is there some core reason why the game could haven't entirely different enemies both behaviorally and graphically (so long as they don't go over 4 sprites (the 5th one was for the rock dump from the dump truck).. or was that just the scope of the game (since it was an arcade port of course) 

 

Edited August 19, 2021 by Caleb Garner

[8bitwidgets.com]

and this one has me wondering though about my first approach..      for me having say.. 5 escort vehicles would be identical in size and only move on x/y axis..  i would hope this is possible.  

 

 

this has copies of balloons moving independently..  this picture has 12 things moving that vary in color and movement in the first pic.. 

 

 and like 14 things in the second pic.. 

 

and this has a ton of stuff on it, but i do understand they are moving in unison with many of these enemies

Edited August 19, 2021 by Caleb Garner

[Brian's Man Cave]

Not sure if this helps a bit, but you can check out this thread that I posted asking how games like Frogger had so many moving parts with an 8 sprite limit

 

 

 

[+DZ-Jay]

9 hours ago, Caleb Garner said:

 

 

@DZ-Jay thanks for that clarity.  so yes my hope was that a single "sprite" could be broken into numerous copies of itself and move around..  my mind went to games like Space Armada which have more than 8 sprites on them, but i get that they are all moving in unison.. vs. say.. galaga which has sprite copies moving around independently not all moving in unison.  

 

Each of the eight MOBs can be controlled individually.  Each one is a separate object or sprite, and can have its own 8x8 or 8x16 picture, and have its own attributes controlled independently.  However, there are only eight at any one time.

Space Armada is an interesting case.  In that game, the enemies are rendered as background tiles, and animated in unison by cycling their pictures in graphics RAM (GRAM).

 

Something like Galaga (which someone in this community is actively working on), could be implemented as a hybrid of both techniques:  while the enemies are in static formation, they can be drawn as background cards, animated by cycling their GRAM pictures.  Then, when they break out from the line and attack, they can be replaced by a MOB and moved independently towards the player.

 

The idea is that only a small set of enemies would be flying in attack mode at any given time.

 

Quote

where i think i'm wrong is that imagine this list of sprites and how they are used numbered 1 - 8 sprite slots and i'm taking the scrolling background into consideration now, but i'm restating some of it because i think i'm wrong but hoping i'm not.. lol:

The scrolling background can be accomplished with just background tiles.  The Intellivision supports smooth scrolling by shifting the display one pixel at a time, up to a full card (8 pixels), at which point the program can shift he background itself and give the illusion of constant movement.

 

That means that you may not need to consume any of the sprites for background scenery.

 

Quote

1. tanker cab 

 

2. tanker trailer (was running out of must have ideas if my use of #2 was viable) 

 

3. escort vehicle 1 (i would want to have say.. 3 copies of these so i could position them around the tanker) but this is where i'm talking about how space armada has many objects on screen even though of course there are only 8 unique objects on screen.  

When you say "copies," I believe you mean multiple sprites with the same picture, right?  If so, you still consume one object per "copy."

 

If their movements are simple, they could be rendered similarly to Space Armada, by animating them in the background.  Note that countering the active scrolling of the background complicates this somewhat.

 

Quote

4. escort vehicle 2 (upgraded that i could have say 2-3 of those on screen) 

 

3. enemy 1 (i could see these both swapping out like escort vehicles maybe 2-3 copies of this on the battlefield at once)

 

4. enemy 2 (like enemy one a couple copies of these moving around to create some variety, maybe both changing colors as enemies get tougher) 

 

5. bullet

 

6. explosion

 

7. oil slick (maybe a few of these in a line like spy hunter arcade game)

 

8. overpass graphic (iffy on that one)

Personally, I think the tanker itself can be rendered as background tiles, since its movement would be limited.  Depending on the complexity of their behaviour, so can the escort vehicles.

 

Oil slicks and overpass elements can be also rendered as background tiles.

You can focus your movable objects on the attacking enemies, the player, and bullets.  An explosion can reuse the bullet sprite that caused it (since they are mutually exclusive).  This may require some staggering in the way shooting is done, but some clever planning on your enemy behaviours can cover for that.

 

 

Quote

background would be the road and such as seen in games like bump in jump.. maybe a kind of middle gray strip with lines pretty much like the take off pad for Mission X

 

If your background does not require rendering many complex elements, then you may simplify your implementation greatly by avoiding scrolling, and just animate the center lines of the road and other selective elements to give the illusion of movement.

 

Scrolling the screen implies handling the shifting of the background, and adjusting the position of objects to maintain their place relative to the display.  If you don't have to scroll as a necessity, then it is best to avoid it.

 

On the other hand, if the scenery itself changes along the way (as Mission X does), then you may need to scroll the background.

 

Quote

now if i understand the harsh reality that i can't do the kind of "rubber stamp" of sprites to be used in game here's another iteration of sprite usage in game:

Yes, harsh reality indeed.  Still, lots of games have been done to great effect with such limited resources, so you still have a chance of making your vision come to life in an exciting way.

 

Quote

1. tanker cab 

 

2. tanker trailer 

 

3. escort 1

 

4. escort 2

 

5. enemy 1

 

6. enemy 2

 

7. enemy 3

 

8. projectile / explosion (game won't be fast shooting action, but slower firing and a bit more "back and forth" sharing the bullet.  

Remember, each one of those is one single color, and of limited size/resolution.  If you can afford to put at least one of the escorts as an animated background tile, you can add another bullet or enemy into play.

We call these "software sprites," because they can be used as regular sprites, but implemented in software.  Essentially, you animate the pictures on the background card where it resides, as well as its adjacent ones, to shift its position across multiple tiles, giving the illusion that the object is moving within the background.
 

It takes some clever engineering, but it can be done to great effect.  Plus it saves you one MOB for more interesting independent objects.

 

Quote

background would be road and such (i assume scores are baked into the background as well?  

Yes.

 

Quote

now regarding variety of enemies.. i notice that a lot of games (like bump n jump) have 5 enemy sprites (3 sprites/colors used on player vehicle ) they never varied the enemies colors / behaviors later.  is there some core reason why the game could haven't entirely different enemies both behaviorally and graphically (so long as they don't go over 4 sprites (the 5th one was for the rock dump from the dump truck).. or was that just the scope of the game (since it was an arcade port of course) 

 

 

The limited behaviours could just be due to the design constraints at the time.  Remember, these are games that needed to be designed and developed within specific budgetary and timely boundaries.

 

The number of enemies and their colors can easily be explained:  Five enemies consume five objects, leaving three for the player's avatar.  (There is only eight, remember.)

 

Sprites can only be of a single color, so reserving a few objects for the player's avatar is a common technique to give it a multi-colored look.  Why?  Because it's what the actual player will be focusing on -- the enemies are mostly in his peripheral vision -- so best to make it shine with as much detail as possible.

 

In the case of Bump n' Jump, it turns out that limiting the enemies to only 5 at a time was sufficient.  In my opinion, I would say that attack waves of three to five enemies at a time are very effective.  In my own game (a Pac-Man inspired maze game), there are two enemies, and most people would say that they are more than enough.

 

The most important thing is to make the enemy behaviour interesting.  That does not necessarily mean complex, but at least understandable and relatable to the player's experience.

 

   dZ.

Edited August 19, 2021 by DZ-Jay

[8bitwidgets.com]

@Brian's Man Cave thanks for that link!  that is really helpul.  I definitely see that this going is going to need background stuff used big time.. and i know that is going to make things tough, but worth it.

 

@DZ-Jay awesome yes i think what you say is great about using tiles in background.  my escort vehicles are positioned by the player but once they are positioned they would stay static (MAYBE some subtle swaying to create more of the illusion of being real cars) but ultimately the player can only position one vehicle at a time.. highlight pick a new destination.. once it reaches the new destination. stop and resume cruising position.  

 

So yes this definitely seems doable.  You're right also about the tanker being a tile.  It is meant to be a centerpiece and not moved around too far.  I would like to be able to move the tanker up and down the high way but never off of it... because of the rough terrain would be too much for such a heavy vehicle.  I would hopefully like it also if possible would be nice to have some drift.. but ultimately it stays on the highway

 

how many colors can the background have?  like you said about the main player in BnJ..   The tanker being the main showpiece, I wonder if as a tile background object, must it be monochrome?  at the very least it would be nice if the tanker cab and trailer could be two different colors. 

 

I do see how moving things on an x and y axis would be more doable and easier to manage in background.  as if i follow correctly once you get into putting things in background you have to then get really down to defining the state of each thing at a pixel level which i can imagine would get really hairy.. 

 

So here are some mockups I did just now to kinda illustrate a few states of things.  some ideas are iffy and others i hope are reasonable.  

 

so green vehicles are positioned by player. hit a number to select a given vehicle.  then move the ghost to where you want to go.  any time a vehicle touches another vehicle it breaks the movement and they stop.

 

This was just an overpass idea.. like BnJ I do see dangers in the road ahead like bridges and such which the player has to account or lose vehicles.

 

So this is a few deeper ideas like bullets or maybe tossed (arching?) grenades / firebombs..  then you have oil slicks.. and lastly enemy jumpers that can try to get onto the tanker and kill the driver.  

Edited August 19, 2021 by Caleb Garner

[8bitwidgets.com]

but i will say i think that 1.0 will not take on all this.  maybe a sequel..  for sanity i'll figure out a way to do the minimal..  tanker will be stationary and baked into the background.  that should be enough work to manage..  and then some kind of BnJ style terrain background...  and then use sprites for everything else..  just so i can keep my sanity    

 

If I went beyond that, the next would be to see if my convoy could be baked in.  but collision detection would be yet another likely daunting task of not allowing player vehicles to move over each other or through each other.  where i can imagine how BnJ did collision was easier to manage because they were all sprites all the time.  

 

So 1.0 would likely be something like 2 friendly vehicles and 3 enemy vehicles and that would give me 3 sprites to play with for things like bullets, destination ghost, road hazards.  

[+DZ-Jay]

30 minutes ago, Caleb Garner said:

@Brian's Man Cave thanks for that link!  that is really helpul.  I definitely see that this going is going to need background stuff used big time.. and i know that is going to make things tough, but worth it.

 

@DZ-Jay awesome yes i think what you say is great about using tiles in background.  my escort vehicles are positioned by the player but once they are positioned they would stay static (MAYBE some subtle swaying to create more of the illusion of being real cars) but ultimately the player can only position one vehicle at a time.. highlight pick a new destination.. once it reaches the new destination. stop and resume cruising position.  
 

That's a perfect use case for animated background tiles.  You need to reserve an object for when the player wants to move the escort vehicle, in order to display a reticle or some sort of icon indicating the desired position; but once that is complete, it can be rendered again as a background tile.

 

The key is that you only need one for all.

 

Quote

So yes this definitely seems doable.  You're right also about the tanker being a tile.  It is meant to be a centerpiece and not moved around too far.  I would like to be able to move the tanker up and down the high way but never off of it... because of the rough terrain would be too much for such a heavy vehicle.  I would hopefully like it also if possible would be nice to have some drift.. but ultimately it stays on the highway

 

For a large object like the tanker, it may be better to render it as background tiles.  The movement and swaying can be implemented as a "software sprite," animating he background tiles and shifting their pictures.  It's more work, but it is possible and effective.

 

Quote

how many colors can the background have?  like you said about the main player in BnJ..   The tanker being the main showpiece, I wonder if as a tile background object, must it be monochrome?  at the very least it would be nice if the tanker cab and trailer could be two different colors. 

Background tiles have two colors: foreground and background.

 

Sprites have two colors too, it's just hat their background color is "transparent," or whatever color shines through from the background tiles or sprites behind it.

 

Quote

I do see how moving things on an x and y axis would be more doable and easier to manage in background.  as if i follow correctly once you get into putting things in background you have to then get really down to defining the state of each thing at a pixel level which i can imagine would get really hairy.. 

Remember that the Intellivision had a character-based display, so it's all tiles, with no direct access to pixels like on a bitmapped display.

 

You'll need to break your pictures into tiles and manipulate the pixels for each tile.

 

To add to the list of limitations, keep in mind that there are only 64 picture slots available in GRAM, and these are shared by all graphics:  MOBs and background.

 

Depending on the screen mode you choose, you may or may not have access to the extended GROM, which are built-in picture cards of simple lines a geometric shapes that can be used to draw more complex scenes.  GROM includes the built-in font, but the character set for text is always available in all screen modes.

Screen modes is a completely separate and complex topic in itself, so best to address any questions on that separately.  Feel free to create as many topics as you have questions.  Sometimes it is better to narrow the focus of a particular discussion.

 

Quote

So here are some mockups I did just now to kinda illustrate a few states of things.  some ideas are iffy and others i hope are reasonable.  

 

It's hard for me to tell from that illustration which elements are expected to be visible simultaneously, in the same screen.

(EDIT: I just saw your updated post with descriptions for each image.)

 

A few considerations:

• MOBs can be given a priority to appear in front or behind background tiles.  However, keep in mind that if they are to appear behind, only the foreground color of the tile will occlude them.  Same for MOBs on top of MOBs:  only the non-transparent areas occlude other objects or background tiles.
• If you are planning to render the tanker as background, it will be tricky to make it look like it's going "under" the overpass, if the latter is itself also part of the background.
• There is no shame in adapting your game to the limitations of the Intellivision.  One idea from the top of my head is to stagger the elements on the screen so that they all come into play, but not necessarily simultaneously.  This can be very effective.
  
  For example, you could have an oil slick or an enemy jumper, but not both.  Or you could wait until one of the enemies dies and render something else before attempting to respawn.  Or you could suppress fire while the player is repositioning his escort, so as to conserve the bullet MOB and employ it for the "ghost," etc.
  
  Trust me, the player will be too busy dealing with the this that are coming at him to notice things like that.

 

 

   dZ.

Edited August 19, 2021 by DZ-Jay

[8bitwidgets.com]

@DZ-Jay yea I see what you mean about background tiles..  would it make sense to switch and use a vehicle sprite while the vehicle is in transition from point A to B and then flip it to background image?  this could also help keep things more neat regarding "tweening" between two locations (location points selected would fall neatly into quantized card spaces to insure they display right.  

 

yes i'm sold on the tiles approach for the tanker for sure.  I can live with monochrome tanker and trailer. 

 

Good to know about background colors but I do want to understand how games like mission x do it?  they have blue water, green ground, darker green bushes and those dithered dots.. and then you have the white AA guns red bridges in the background scrolling down.  not to mention the nice jagged coastal detail.  really nice stuff.  

 

 

Yea I'll have to study how backgrounds work with characters and picture slots / gram but i'm sure the book and other areas go into this plenty so I'll research that soon.  

 

is collision detection difficult to manage with items baked into background?  like once a escort vehicle is in it's new place.. how to keep enemies from crossing over it.  

 

yea i'll avoid anything advanced for sure like screen modes..  

 

as for the overpass honestly it sounds like it would be more trouble than it's worth.  it makes sense you don't really see over/under stuff in intellivision games and this makes sense why.  

 

as for staggering i'm not sure i am following it exactly, but if i follow you right i would see how the by having slower shooting enemies and action not being fast paced.. should allow things like timing when it's ok to shoot something..  for example if oil slick was dropped for a given chunk of time the next shot fired by any enemy or friendly target would get put on hold for just a moment.. then resume firing after the oil slick was laid.  which would be a fairly brief time.  like 0.5 seconds. 

 

i could definitely see that being the case..  an enemy jumper wouldn't jump till a shot is open.  thinking of it like an audio channel.. the "action" channel would have various actions that happen in it and scripted events would be put on hold by player actions but even player actions might have a slight delay if they pushed a button when a scripted event is occuring.  

 

very exciting stuff!   

Edited August 19, 2021 by Caleb Garner

[carlsson]

52 minutes ago, Caleb Garner said:

Good to know about background colors but I do want to understand how games like mission x do it?  they have blue water, green ground, darker green bushes and those dithered dots.. and then you have the white AA guns red bridges in the background scrolling down.  not to mention the nice jagged coastal detail.  really nice stuff.  

Every BACKTAB tile (20x12) can have its own combination of foreground and background, 8x8 pixels. The land portions probably have middle green background and darker green or white foreground. The jagged lines next to water would be a combination of middle green and blue, and the bridge at the top probably has blue background and red foreground. The key is that you can't have more than one foreground per 8x8 tile, but each respective tile is independent. Thus the secret to impressive graphics is planning your boundaries so you can align objects as desired.

[+cmadruga]

In that Asphalt WIP I shared above, @YannAros went through similar considerations about when to use sprites vs background graphics.

I thought he was achieving pretty good results. I wonder if he continued to work on it.

Maybe he will see this message and stop by to offer additional insights.

[+cmadruga]

15 hours ago, DZ-Jay said:

I would lean on any suggestions from people like @cmadruga, @nanochess, and others in this forum, who are very proficient in the language, having made several successful (and highly impressive) titles already.  @nanochess himself is the author of IntyBASIC.

BTW, I appreciate your generous comment.

I still feel far from being fully proficient. Still learning this stuff like many others.

On the other hand, one can't go wrong by listening to @nanochess 

Edited August 19, 2021 by cmadruga

[8bitwidgets.com]

wow so awesome.  ok yea i see now how that would open up possibilities @carlsson regarding background and foreground.  so is it then possible that each tile could have any color combination possible?  that could result in a lot of colors (all 16) on the screen at once.  i'm not thinking of any games off the top of my head that have 16 colors on screen at once or at least it's not common if ever.  maybe some color concerns still matter?  or really all 20x12 tiles can be ANY two colors you like?

thank you @cmadruga for your insight and experience!  knowing who's who is absolutely new to me.  i'm picking up on a little of it, but I know I have a lot of work ahead of me.  I'm kinda picking up the pieces the 3D version of Road Defender which is an "on hold" project because the programmer I was working with bailed on the team so I am taking the reigns of this new iteration and can be able to making something myself rather than being at the whim of someone else.  It was a risk but when you're working on a passion project with more people, the more likely things can go wrong..  just how things go sometimes..  so this empowers me to achieve a finished project myself.  I've made games for mobile / web before, but making a game for the game system of my childhood is just too cool to pass up especially thanks to intybasic helping make the development cycle a bit easier than it was in the 70s and 80s.   

 

..checking delivery date for intybasic book!  

[carlsson]

Yes and no. In FG/BG mode you can have any of the 16 background colours on each tile but only use the first 8 foreground colours. In Color Stack mode, I believe you define 4 different background colours out of the 16 that you'll use for the entire screen (cycle through those), but can use any of the 16 foreground colours on each tile.

[+DZ-Jay]

4 hours ago, Caleb Garner said:

Good to know about background colors but I do want to understand how games like mission x do it?  they have blue water, green ground, darker green bushes and those dithered dots.. and then you have the white AA guns red bridges in the background scrolling down.  not to mention the nice jagged coastal detail.  really nice stuff.  

 

 

Sorry, I forgot to say that the two-color limitation applies to each 8x8 tile in the background, not to the entire scene.  I see that @carlsson provided the details I missed.

 

Also, as stated by @carlsson, there are some limitations on the combinations of colors you can use on each tile.  Again, this applies per tile, not per scene.

 

The only scene-wide color limitation is related to the display mode you choose.  Essentially there are three modes:

• Color Stack (model 0):
  In this mode, the background color palette is defined on a 4-color circular array, called the "color stack."  You can use any of the 16 colors for the foreground, but the background colors can only be from the lower 8, the so-called primary colors, and must be preconfigured for the entire scene in the "color stack."
  
  Moreover, you can't use them at random:  you can only access the background colors in the order in which they are arranged in the stack.  Selecting a different color requires you to "advance the stack" at a particular tile, which will then make any subsequent tile use that background color.  When you advance the stack past its end, it returns to the first color, and on it goes.
  
  This mode a bit convoluted and many people (especially IntyBASIC programmers) avoid it like the plague.  However, it does have some good qualities, particularly the ability to use any of the 16 colors for the foreground in any combination with the four background colors selected.
  
  It also opens up access to the full GROM set.  I know that a lot of people assume that it's useless because it's merely lines and basic geometric figures, and such; but you'd be surprise how useful they can be in filling in spaces around your screen with little corners and lines, etc., which afford some level of complexity in the scene -- plus it frees the GRAM for even more detail.  Every card you fill with GROM is one less custom card that you need to define in GRAM.  Remember, there are only 64 GRAM cards, and they serve for all graphics on the screen.
   
• Foreground/Background (mode1):
  Whereas Color Stack offers more graphical flexibility at the expense of color space, FG/BG mode offers the reverse:  the ability to select individual foreground and background colors for each tile, at the expense of access to the extended GROM set.
  
  Still, it includes some color limitations. For one thing, only the primary colors are available for foreground, so you still have that.  As with Color Stack mode, the full GRAM set is available, but unlike Color Stack, only the character set for text is available from GROM.
  
  Because it is easy to configure, and is comparable to similar modes in other systems, FG/BG is very popular among programmers.
   
• Colored Squares (mode 0+):
  This is not really a distinct mode at all, but a variation on the Color Stack mode.  Using Color Stack mode, you could set any of the tiles on the screen to display instead of an 8x8 pixels picture, as a a block of 2x2 "bloxels."  This affords some rather "chunky" graphics at lower resolutions.  I believe that the only game every published to use it was "Snafu," which was rather simple.
  
  It has some color limitations as well, but most people don't bother with this mode.

 

Personally, I like Color Stack mode, but that's me, and apparently I'm in the very small minority.

 

    -dZ.

Edited August 19, 2021 by DZ-Jay

[carlsson]

Also consider that if you e.g. want a pastel colour (8-15) for background in CS mode or foreground in FG/BG mode, I suppose you can define that GRAM card in inverse so background becomes foreground, or maybe it affects collision detection?

[8bitwidgets.com]

wow that's fascinating!  i can see why people might avoid that stuff, but i do see your point about them having benefits.  I would love to have greater pallet options for sure.  The mockups above used all 16 colors without any concern of stacks..  so more shades would be helpful if Road Defender (RD) could get more action on the screen at once.  

 

Fortunately for RD, I don't think background complexity is going to be a huge thing.. mostly solid color for roads and some rough noise for the sides much like bump n' jump..   and i figure it will be better to keep the road / dirt fairly sparse (just enough to convey a sense of motion) that way when baked in escort vehicles are moving over those areas it doesn't feel too jarring (like when you can see texture jumps like in mission x)

 

I still worry though that collision detection may be problematic with baked in objects..  i can't have enemies rolling over escort vehicles..  i would make enemies not go on paths through players but it could be a pain to prevent players from getting in the way of enemies..  but then again don't know how difficult collision detection is to manage / update.  I could see a 1.0 solution would be to just insure that the player range of positioning can't overlap the paths of the enemy but that would make for a more stale experience and i feel like it would be cooler if they could collide / bounce off each other (not BnJ levels of bounce, but you know.. some reaction / damage) but again what i want vs what's manageable is the question..  

Edited August 19, 2021 by Caleb Garner

[YannAros]

2 hours ago, cmadruga said:

In that Asphalt WIP I shared above, @YannAros went through similar considerations about when to use sprites vs background graphics.

I thought he was achieving pretty good results. I wonder if he continued to work on it.

Maybe he will see this message and stop by to offer additional insights.

Work is on going, at a pretty slow pace. I’m working on enemy AI at the moment, some of the truck damages are managed now, I still need to add opponents gun shots and mine deposit.

In original game (look for Asphalt on Amstrad CPC) there are also enemies climbing on your truck, I haven’t thought on how to do this. I’m running out of sprites and have to think about transferring more to soft sprites.

 

In the current prototype, only the truck colors are soft sprites, the black is done with 3 MOBs, and a 4th one is used for the firing tower and the flames (multiplexed).

 

Each opponent is using 2 MOBs, the color one is multiplexed with flames.

 

Finally the road edges and the dropped mines are done with soft sprites.

 

I find the use of a single color MOB for an object quite limiting.

 

I need to process the video before uploading so that it appears at 60fps and not 30, currently you can’t see the multiplexed MOBs (only one of them is displayed)

[+DZ-Jay]

2 hours ago, carlsson said:

Also consider that if you e.g. want a pastel colour (8-15) for background in CS mode or foreground in FG/BG mode, I suppose you can define that GRAM card in inverse so background becomes foreground, or maybe it affects collision detection?

It does affect collision detection.  It is a very effective visual trick, but it may require you to implement collisions in software.

Edited August 19, 2021 by DZ-Jay

[+DZ-Jay]

17 hours ago, Caleb Garner said:

wow that's fascinating!  i can see why people might avoid that stuff, but i do see your point about them having benefits.  I would love to have greater pallet options for sure.  The mockups above used all 16 colors without any concern of stacks..  so more shades would be helpful if Road Defender (RD) could get more action on the screen at once.  

 

Fortunately for RD, I don't think background complexity is going to be a huge thing.. mostly solid color for roads and some rough noise for the sides much like bump n' jump..   and i figure it will be better to keep the road / dirt fairly sparse (just enough to convey a sense of motion) that way when baked in escort vehicles are moving over those areas it doesn't feel too jarring (like when you can see texture jumps like in mission x)

 

I still worry though that collision detection may be problematic with baked in objects..  i can't have enemies rolling over escort vehicles..  i would make enemies not go on paths through players but it could be a pain to prevent players from getting in the way of enemies..  but then again don't know how difficult collision detection is to manage / update.  I could see a 1.0 solution would be to just insure that the player range of positioning can't overlap the paths of the enemy but that would make for a more stale experience and i feel like it would be cooler if they could collide / bounce off each other (not BnJ levels of bounce, but you know.. some reaction / damage) but again what i want vs what's manageable is the question..  

For some games, bounding-box collision detection in software may be preferable.  These are simple and effective, although perhaps not as accurate as the pixel-level hardware collision.

 

In any case, remember that collisions don’t just happen:  hardware collisions just set a flag, which you must check and respond to, so you are still in control.

 

It may be a challenge, as @carlsson suggested, to decode collisions against reverse-video tiles, but I would mostly recommend such tricks for mostly static or inert scenes (like title screens or non-interactive displays), and not for actual game-play enabled scenes.

 

Another thing to consider is that hardware collisions are detected during the vertical blanking interrupt (VBLANK).  In fact, most video-related objects and attributes are only accessible during the VBLANK period.  IntyBASIC does a good job of abstracting this for you by buffering any MOB and GRAM changes until the next interrupt.

 

However, this all leads to the following problem:  you move your sprites in one frame (frame “n”); you then wait to read the collisions on the next frame (frame “n + 1”); and by the time you react to collisions, you have to wait yet one more interrupt to update the state of your sprites on the next frame after that (frame “n + 2”).

This reaction delay of 2 frames is just part of life, and may or may not be significant to your game, but it must be accounted for.

 

Software collisions, in the other hand, can happen in the same frame, since you have full control of its state.  Each one has its strengths and drawbacks.

 

   dZ.

Edited August 20, 2021 by DZ-Jay