'Immunity' homebrew WIP

[Sohl]

Found my object position issue.  I'm a bit chagrinned that a bug that I described back in a reply on Feb. 1 came back to bite me again.  It was caused by crossing a memory page boundary with the PosObject code so that the object-positioning loop runs slower than expected and mispositions the object. 

 

To avoid this bug for good, I have enhanced the macro to check the current assembly target address and trigger an assembly error and abort with a line number statement if the critical loop part includes a page boundary.  Code is adapted from a @SpiceWare programming example...

 

;===============================================================================
; PosObjectCode - by Darrell Spice, Jr. (and others?) 
;   With fix by M. Losh for current DASM's failure to force word abs,x address.
;   Conversion to MACRO format to avoid source code repetition, you can place
;   macro in each bank, followed with a subroutine return (ret), 
;   and/or can be expanded inline with other code.
;   Added check for code page crossing in loop, which throws off timing and
;   therefore the object position.  If page crossing detected, will abort
;   assembly so you know to fix it (e.g. rearrange code to avoid page crossing)
;----------
;  for setting the X position of any TIA object
; when called, set the following registers:
;   A - holds the X position of the object
;   X - holds which object to position
;       0 = player0
;       1 = player1
;       2 = missile0
;       3 = missile1
;       4 = ball
; the routine will set the coarse X position of the object, as well as the
; fine-tune register that will be used when HMOVE is used.
;
; Note: The X position differs based on the object, for player0 and player1
;       0 is the leftmost pixel while for missile0, missile1 and ball 1 is
;       the leftmost pixel:
;           players     - X range is 0-159
;           missiles    - X range is 1-160
;           ball        - X range is 1-160
; Note: Setting players to double or quad size will affect the position of
;       the players.
;===============================================================================
	MAC PosObjectCode
        sec
        sta WSYNC
	IF (((* & $00ff) > $00fb) && ((* & $00ff) <= $00ff))
		echo "PosObject has page crossing that will cause incorrect positions! Address: ", *
		ERR
	ENDIF
.divideLoop:
        sbc #15        ; 2  2 - each time thru this loop takes 5 cycles, which is 
        bcs .divideLoop ; 2  4 - the same amount of time it takes to draw 15 pixels
        eor #7         ; 2  6 - The EOR & ASL statements convert the remainder
        asl            ; 2  8 - of position/15 to the value needed to fine tune
        asl            ; 2 10 - the X position
        asl            ; 2 12
        asl            ; 2 14
        .byte $9d, HMP0, 0 ; force sta.wx HMP0,X  (word-address absolute store indexed by x)
					   ; 5 19 - store fine tuning of X
        sta RESP0,X    ; 4 23 - set coarse X position of object
	ENDM
	

There are only a few bytes in the critical sbc and bcs instruction loop, but if this loop with starts on a 0xXXfc through 0xXXff address, there will be a page-crossing time delay, throwing off this masterfully-constructed bit of code.  This macro now looks for this condition and will not let me build a ROM with this issue in it.  Hope this helps someone else avoid this subtle bug!

[+SpiceWare]

I'm not sure who came up with that routine, I just documented it with all those comments.

 

DASM 2.20.14.1 restores support for .wx and .wy. It was released on November 9, 2020.  

 

Are you aware of Club DASM?

 

 

[Sohl]

1 hour ago, SpiceWare said:

I'm not sure who came up with that routine, I just documented it with all those comments.

 

DASM 2.20.14.1 restores support for .wx and .wy. It was released on November 9, 2020.  

 

Are you aware of Club DASM?

 

 

I didn't know about clubs in general!   I joined up.    Looks like I have version 2.20.41 (not the extra .1), so I should upgrade.

[Sohl]

I have a new playable demo!  I finally got the scoring/status update review mode working well after both types of main play screens.  Beyond the drawing kernel, there are a lot of changes as to when the scores and status levels change (now mostly synchronized with the review mode animations).  I'm pretty happy with this version in terms of how it plays and overall game mechanics.  It can and will be further refined before it's considered final.

 

I did some changes to object speeds to make the beginner mode (left difficulty switch setting B) somewhat more challenging. I'm sure I will continue to tune this aspect of the game, as well as initial starting 'inventory' status, etc. 

 

The main gameplay is basically the same as the last demo.  The prior early draft instruction manual is mostly still applicable, but I will document the updated status indicators and the score/status review "intermission" modes in a future manual draft.

 

Known issues:

* Exocellular: playfield drawing is a bit unstable (making it a bit vertically wobbly) even when the scanline count is OK

* Exocellular: perhaps occasional scanline count issues, at least when there is a latched virus

* Exocellular: when a virus is completely neutralized and macrophage is active, the virus sprite colors may not be the intended yellow + light gray (esp. when virus is low on screen?)

 

Future plans:

* Better stabilize the exocellular screen.   (Perhaps just by tweaking existing code to make it work more consistently, but I have an idea to change the object positioning method to allow a cleaner drawing kernel and perhaps one or more additional infecting viruses onscreen)

* Change the "breath count" to a elapsed time display?  Or at least allow a full three digits or more for the breath count (too easy to hit max 199 level right now)

* A two-player mode (even if simple) and single/two-player selection mechanism that is couch-compliant(R)

* Perhaps switching from playfield graphics to player graphics (AKA sprites) for most text in title/end screens? *

* Smooth out some of the jaggies in the title, win screen, and game-over screens? *

* Longer main theme and win/game-over music? *

 

* (Potential bonuses for the full retail version? )

 

Let me know your thoughts and any issues you have with this demo release!

 

immunity_2022_Mar_22.bin

Edited March 22, 2022 by Sohl
Wording

[Sohl]

Another "Developer Log" update... 

 

Changes: 

• Packed some state flags held in several separate RAM bytes into a single byte
• Now allow breath count to run from 0 to 9999! (It's easy to go over the old limit of 199 now, especially in "Advanced" difficulty mode)
• Health and Breath score display eliminates leading zeros 
• Breath icon relocated to left side of breath count and will adjust to stay relatively close to first visible digit
• Score display drawing kernel loop code moved into a macro so it is only defined once in source code for both intra and exo play modes

I also created a "RAM Plan" document that shows all of my RAM declarations, organized and layed out to better show renamed/shared cases over the different execution modes. This will help me determine where I have additional opportunities to share the same RAM location between the different modes, freeing up some additional space.  I anticipate that I will need to free up some space to support a better display kernel in the "exocellular" mode as well as the eventual two-player mode.  I can also share some RAM values to have a nicer title and game-over screens (better graphics?) and an interactive game initialization (one/two player game select, perhaps additional options).  

 

Here's a few screen shots of the new breath count display, showing possible high values and blanking any leading zeros in the count displays.

 

 

[Sohl]

I have a new demo version! The changes in terms of gameplay are minimal, but I spent quite a bit of time reworking the drawing kernel for the 'extracellular' screen (AKA exo mode).  It is more stable in terms of the simple playfield texture positioning and drawing of the antibodies when flung.  It's also about 130 bytes less ROM space!  (I bet I can use that later for the 2-player gameplay).  

 

Not saying this demo release is bug-free, but seems fairly good in some testing I did tonight.  A few of the changes, if you look closely:

• Macrophage is drawn without flicker when away from any latched viruses at the bottom.  This was done by making the fully-neutralized virus a solid color (one sprite instead of two)
• The exo mode bonus review if you clear all the viruses in that tissue will now only show you as many point animations as needed to reach the max health of 99%, e.g. if you had 96% when the tissue is cleared, you will see only 3 of the animated +1 point icons rather than the 10 you'd see before, which is the full bonus.  If you are already at 99% when the review starts, it just flashes an empty review background briefly.  I'm not sure I like this... maybe I can show something else or at least play a bonus sound effect before switching to the intracellular mode screen.

One concern I have is the beginner difficulty level at least is still too easy.  I think I will try to speed up all of the moving targets a bit.  I may also make the loose spike proteins start to dwindle over time, so if you don't collect them right away, you won't get as many, or perhaps none at all.  

 

I'm also thinking of a type of power-up in the exo mode that will repel the viruses, giving you more time to neutralize them.  Not 100% I can pull that off and still get one or two two-player game variations I'm thinking of with game-select screens, etc.

 

1st two-player idea:  One player controls the cell's immune system while the other controls movement of the viruses and viral DNA.  It would be a sort of dodge-em.  At the end of a round, the roles could reverse.  Scoring might be a simpler point system rather than health %.

 

2nd two-player idea: Rival macrophages attempt to collect the most neutralized viruses.  Other helpful items can be collected, but still-active viruses will hurt your macrophage in some way.  

 

Let me know if you have any thoughts on these ideas or any issues with the current demo! 

 

 

immunity_2022_Apr_24.bin

[Sohl]

This week's minor updates:   

• I addressed the skipped score review when the health is already maxed.  You will now see the earned bonus point icons swoop up, but you won't see point addition animations once the max health of 99% is reached.  This helps shorten the review period if it is not relevant, but you still get some acknowledgement that you earned a bonus.
• I did implement the vanishing loose spike protein idea mentioned in my last reply.  Over several seconds, the quantity of loose spike proteins dwindles down, and may completely disappear.  Later I plan to make the rate of dwindling A/B difficulty-based.
• Minor fix for lung icon positioning in the score area (sometimes misplaced during score review)
• Moderately faster target object speeds to raise the challenge level somewhat (should I go further?)
• Working out some design details for a two-player game (virus versus cell version)

I think I notice a very sporadic screen glitch happening.  It does not seem to affect gameplay, but I'd like to fix it.  To do that I need to be able to replicate it consistently, but I'm not sure what conditions trigger it.  If you test this demo release and see a pattern to any glitch, I'd like to hear your observations!

 

immunity_2022_Apr_29.bin

[Sohl]

Back again...  I've been toiling away for many weeks at a major refactoring of the "exo" play mode to allow the same code to handle both the lower and higher attacking viruses as well as other streamlining to save ROM space and to avoid timing overruns that led to unstable screen content and overall screen lines per frame.  There could still be some linecount glitches on major screen mode changes but those should not be very noticeable.

 

Besides a more stable screen during play, the refactoring effort has freed up just under 400 bytes of ROM space in my 16K cartridge image.  This is space I expect to need for a two-player game version (or two?) that I finally feel ready to get working on.  

While there should be no significant changes in the gameplay in this version over the prior demo release or two, I'm releasing this latest one because I feel it is more stable and should provide a slightly better demo experience.  But watch this thread for new forays into the two-player realm!   

immunity_2022_Jun_12.bin

[Sohl]

It's been a long time since my last post... I took some time off through the summer and got busy at times with home improvement projects.  I'm back in gear again, partly inspired by the fact that Immunity was one of many games set up as playable demos in the AtariAge booth at the Portland Retro Gaming Expo this past weekend, thanks to @Albert! 

 

As for my more recent development, I've been working on changing the virus motion control approach to make it better inside the game code to switch between computer control in one-player mode and joystick control for two-player mode coming later.  I've also made the virus motion in the "exocellular" screens dynamically affected by breaths and heartbeats depending on tissue types... I can't wait to show it, but it's still a bit rough, so stay tuned!

 

See this thread for pictures from the Expo, where you can see my 'GAME OVER' screen :

 

[Sohl]

Two-Player teaser...

 

The basic idea for the two-player game is that the left and right players take turns controlling the ribosome (at the bottom) or the infecting viruses in the "exocellular" gameplay mode.  The player controlling the ribosome moves left and right and flings antibodies upward hopefully to cover the attacking virus, as in the one-player game version.  I have not decided yet to leave the macrophage (gobbler) mechanics in or automatically remove the covered (and therefore neutralized) virus (Maybe this could be a minor game variant) 

The player controlling the viruses may move them sideways at various speeds depending on the tissue type, but generally slower than the ribosome. If the player does not press the joystick in the upward left/right direction, both viruses move in the same direction.  If the player does push the joystick in the upper direction left or right, the higher virus will move in that direction while the lower virus moves in the opposite direction.  If the player pulls the joystick downward, in any direction, the viruses will move straight down, but faster than the default decent rate.  (Note that the body's breathing affects virus vertical movement in two tissue types, while pulse effects virus horizontal motion in two other tissue types.)  

I have the two-player scoring display basically done, as seen in this screen shot (unless I want to make it fancier later).  Each player has a two digit score. The left player is yellow and right player is turquoise green.  The player controlling the ribosome will have a copy of the ribosome sprite next to their score digits, while the player controlling the viruses will have a virus sprite next to their score digits.  

 

I don't have the scoring worked out exactly, but when a player controlling ribosome neutralizes a virus, perhaps 1 point will be earned.  On the other hand, if the player controlling the viruses manages to get one to the cell membrane and "latch" it on, a higher number of points will be earned (maybe 3?  I'll try to balance this depending on how easy/hard each side is to play).  Right now, I don't plan to limit the antibodies as in the one-player game.  After three viruses latch or the ribosome player has neutralized a certain number (9 minus the latched number?), the players will swap roles.  After both players have completed both roles in a specific tissue type, the game will move to a new tissue type which will have different virus horizontal and vertical speeds, and possible effects from the body's breathing and pulse. As of now, first to 99 wins the game. 

 

All of this is still subject to change as I implement things and determine what works well in gameplay.  I still have many changes and additions to get the two-player mode fully playable, but I want to get a new playable demo out within two-three weeks.

[Sohl]

Demo with two-player mode is posted!  It's a bit rough around some of the edges... you may see scanline count issues in a few spots, and the virus sprite sometimes only partly visible when low, but you can try out the two-player game.

When on the Immunity title screen, the game select switch, or... being couch-compliant , pulling down on the left joystick will activate the game select screen (as seen below), while additional game select switch presses or downward motions of the left joystick will toggle the selected game version.  You will see a "1" or "2" at the top of the screen for one-player and two-player and a visual representation of a joystick icon horizontally aligned with the ribosome character for both games, or a blank or a second joystick horizontally aligned with the virus character depending on the current game selection of 1 or 2.

        
Gameplay for two players is as described above in my previous posting in this thread. As of now, neutralizing a virus scores a player 1 point (don't forget to push up on the joystick to enable the macrophage as done in the one-player game).  Latching a virus scores the other player 3 points, but to do so requires a player to move back and forth a few times over a good (and open) latching spot when at the membrane.

 

Later I plan to have the game briefly display a version of the above game select screen to show which player is controlling each character in the game whenever the player control swaps back or forth.  Furthermore, I want to rework the title screen and most of the non-play screens to leverage these new character graphics (aren't they cute?), but that will require some significant tear up and refinement in other parts of the code. Stay tuned for that.

 

If you have feedback or bugs to report, especially on the two-player mode, I'd appreciate it!  I've had one of my college-age kids help me playtest a bit, but I'd love to get others' impressions too.  Have Fun!

Another bug I've noticed in this demo release: If you win in the one-player mode and the non-playing game is cycling back and forth between the win screen and the score & playfield screen and you then pull the game select switch, the game select screen will be corrupted.  You can first hit game reset switch or the (couch compliant) fire button when on the win screen to reset the game completely, then select the game (1 or 2).

imm_2player_20221106.bin

[Sohl]

Using the "Big Sprite" drawing method used in the game select screens as shown above, I've revamped many of the non-play screens for title, winning, two-player prompts, credits etc.  Here is my current title screen.  I still have a bit more work to do to fix regressions caused by the non-play screen changes, plus a few more things to get the non-play screens switching/cycling as intended.  But I'm starting to see a glimmer of light at the end of the tunnel of coding!

[Albert]

That title screen looks great!

 

 ..AL

[Sohl]

12 hours ago, Albert said:

That title screen looks great!

 

 ..AL

Thanks Al!

[+ZeroPage Homebrew]

ZeroPage Homebrew is playing Immunity on tomorrow's ZPH stream LIVE on Twitch, hope you can join us!

 

Tue Nov 29, 2022 | LIVE @ 6PM PT | 9PM ET | 2AM GMT+1Day

WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/
WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• Chaotic Grill (2022 WIP Update | 2600) by Philip Blackman @splendidnut (Code, Graphics, Sound) / NostAlgae37 @NostAlgae37 (Sprites) / Kurt Woloch @Kurt_Woloch (Misc)
• Immunity (2022 Exclusive WIP Update | 2600) by Mike Losh @Sohl
• Top & Tom 2 (2022 WIP Update | 2600) by Thomas Jentzsch @Thomas Jentzsch

 (WATCH AT 1080P60 FOR BEST QUALITY)

 

 

[Sohl]

Here is the ROM image of the version of Immunity played last night on the ZPH Twitch stream.  Thanks @ZeroPage Homebrew!  I'll need to look into that "orange screen" crash! 

 

immunity_wip_20221126.bin

[Sohl]

Many new updates to my game code and some graphics updates as well.

• Many fixes for virus motion bugs, scanline count inconsistencies, and a few visual glitches
• Did some tuning of virus motion rates in the various tissues to be more interesting and challenging. Probably will tweak a bit more with further testing
• I changed the order that tissues are played to be more bio-inspired:   Lung - Mucous Membrane - Bloodstream - Muscle - Brain - Bone - (then repeats)
• Bone tissue is a lighter color, to differentiate it from Brain tissue better, but it will make virus and antibody visibility a little more challenging for the player
  
• I have a hint of a "skin" tissue that shows up only in the upper part of the first "intra" (mostly blue) screen the first time it is played per game in the one player version. 
  
• I've recolored part of the two-player score display so the score numerals and player sprites are on top of a blue background, which helps contrast.  
  
• "Three items at a time" update animations in the scoring/bonus review intermission screens so they are faster - nice when there's a lot of new antibodies
  
• Monophonic but better-sounding splash screen music; main title screen theme music is the same
• New "Rest" feature, described below

The new "rest" feature allows you to skip ahead to the end of the exo-cellular screen when your antibody level is very low and you need to build up more in the intra-cellular (mostly blue) screen.  I'd like to add an audible alert that the antibody levels are low to help players know when to "rest", but not done so yet. (ROM is starting to run out and it is quite challenging to add more code and/or data in some parts of the ROM!) 

Resting is triggered pulling the joystick down and holding a few seconds.  You will see a non-play screen with a clock icon and the word "Rest" ... but if hold long enough, you will see a "sleeping" ribosome character, which lets you know you have committed to the rest period.  Then when you release the joystick, it will immediately trigger the exo-cellular intermission/score-review screen.  You will still loose health for any viruses that had or can latch or are still free in the tissue, but unless that takes your health down to zero, you will have a chance to build up antibodies again so you "live to fight another day."   

     

I'm planning to hold this "rest" feature out from any new playable demos I post to save a few elements for those who purchase a packaged version of the game someday soon (I hope). Might also reserve the last two tissue levels for the commercial release. Stay tuned for further updates!  

 

 

[Sohl]

Based on some feedback during the @ZeroPage Homebrew Twitch stream, I have implemented an antibody "rapid-fling" option, enabled by selecting game variant 3 (one-player rapid-fling) or variant 4 (two-player rapid fling).  A small "r" is shown with the game variants 3 & 4 digits to better indicate the "rapid-fire" option.

In the rapid-fling mode, you still cannot have more than one antibody flinging upward at a time, but each fire button release will restart any currently flinging antibody back to the current ribosome location; meaning, you don't need to wait for the antibody to reach the top of the playfield if you miss a virus... you can fling again as soon as you want.  But be judicious with this option... you can more quickly run out of antibodies, which is GAME OVER!

I've also found and fixed a few other bugs.  I hope to get a playable demo with these new game variants out before Christmas, which will also feature some of the other changes mentioned above, minus any "commercial only" features. 
 

[Sohl]

New gameplay feature for the two-player game... brief virus "shield" when player controlling virus hits the fire button.  When active, an antibody flung by the ribosome player will not hit & stick to the virus.  The virus shield state is shown by a different virus body color (green currently).  The length of time will be very short, so the virus player needs to time it precisely. If the player continues to hold the fire button, the shield will no longer be active, and can only be re-activated by releasing the fire button and pressing fire again.  

 

P.S. This will only apply to the game variant 4 (the rapid-fling two-player game)

Edited December 23, 2022 by Sohl

[Bomberman94]

Is there a actual PAL60 version available for this please? 😃

[Sohl]

7 hours ago, Bomberman94 said:

Is there a actual PAL60 version available for this please? 😃

Hi @Bomberman94 ! I have zero experience making PAL versions of games.  The Immunity code has very many drawing kernels with hard-coded scanline limits and not a lot of extra ROM or RAM to make it dynamically adaptable, but perhaps it's possible. Otherwise, eventually, I can use conditional assembly statements to be able to build a PAL version instead of a the NTSC version with different hardcoded loop limits, color values, etc.).  I'm not sure if this could be carried as a separate item in the AA store (assuming I get it there, as hoped), but perhaps at least I could release a demo version in PAL at least. 

[Albert]

1 minute ago, Sohl said:

Hi @Bomberman94 ! I have zero experience making PAL versions of games.  The Immunity code has very many drawing kernels with hard-coded scanline limits and not a lot of extra ROM or RAM to make it dynamically adaptable, but perhaps it's possible. Otherwise, eventually, I can use conditional assembly statements to be able to build a PAL version instead of a the NTSC version with different hardcoded loop limits, color values, etc.).  I'm not sure if this could be carried as a separate item in the AA store (assuming I get it there, as hoped), but perhaps at least I could release a demo version in PAL at least. 

A PAL60 version of the game is just the NTSC version with a PAL color palette.  So you don't need to change anything else about the game code-wise.

 

 ..Al

[Sohl]

7 hours ago, Albert said:

A PAL60 version of the game is just the NTSC version with a PAL color palette.  So you don't need to change anything else about the game code-wise.

 

 ..Al

Ahh, see how ignorant I am?  

It would be easy to make a separate ROM image with alternative colors.  It would be nice to be able to support dynamically with the color/bw switch, but I don't think there's any way to do that and still fit the 16K F6 bank-switching scheme.  My latest build has approximately has 52 bytes free.  

[Albert]

31 minutes ago, Sohl said:

but I don't think there's any way to do that and still fit the 16K F6 bank-switching scheme

Creating two binaries, one for NTSC and one for PAL60, is just fine. That's what most games do to support PAL60. Some do support both versions with the same binary if space is available. 

 

  ..Al

[Sohl]

Here is a new playable demo.  It has the new features described in my recent posts minus two that I'm holding for potential commercial release:
1) Resting (skip ahead) 

2) Two of the six tissue types

I increased some of the movement rates to make it a bit more challenging.  The beginner difficulty level is perhaps still a bit easy, but the advanced difficulty is quite hard to beat in my opinion.

I don't know of any major issues with this, but if you notice a bug or weird issue, let me know!  Also if you have feedback on the gameplay challenge level, etc. that would be great to hear.

Happy Holidays!

imm _demo_2022dec23.bin