Jump to content
Ryan Witmer

Intellidiscs: Weekly development log

Recommended Posts

On 8/2/2020 at 9:17 PM, Ryan Witmer said:

Just wanted to do a little bit of "thinking out loud" about this game.

 

When I do a game project, I always try to identify THE PROBLEM.  What is THE PROBLEM?  It's the one thing that I need to get right, or else there is no game.

 

The best example of THE PROBLEM I can give was from RealSports Curling.  It was possible, however unlikely, for sixteen rocks to be active at the same time in that game.  So THE PROBLEM for that game was how to actually put sixteen rocks on the screen in a way that would work.  The 5200 only offers eight sprites, and four of them are two-pixel wide missiles.  Those wouldn't work at all.  The solution was to build all the rocks out of the playfield.  The player sprites actually make up the rings, and the missiles are used for various vertical lines.  The rocks are, in effect, a really fancy moving background.

 

I first got the idea for a Deadly Discs port way back before my first game, and I quickly identified THE PROBLEM even back then.  In the Intellivision original, there are four enemy types and they're distinguished by color.  Normal dudes are light blue, armored dudes are purplish, leader dudes are dark blue, and the orange dudes show up at 1,000,000 points.  In addition to this, there are four types of enemy weapons.  Normal discs are dark blue, double-damage discs are kind of a dark purple, seeking discs are white, and the orange dudes have white staff things.

 

The 5200 provides eight sprites.  Four of them are 8 pixel wide "players" and the others are 2 pixel wide "missiles."  On the surface, this seems perfect!  There are four people on the screen at once, each has a small weapon!  THE PROBLEM lies in the colors.  There are two ways to do color for the sprites.  Normally, each player has an associated missile that shares its color.  There's also something called "fifth player" mode which allows you set the four missiles to an independent color, but it's one color that all four missiles share.  The 5200 doesn't have enough sprite colors to do this the way the Intellivision does.

 

So, what are the possible solutions to THE PROBLEM?  The first decision to make is whether or not to try to preserve the color-coded approach that the Intellivision used.  It's worth mentioning that the final orange enemies don't throw their weapons, they're just decorative, so there's less of a need to make a solution work for those guys.

 

If the is answer is yes, the color coding should be preserved, how can it be done?  I have one solution and I don't like it.  Flicker.

 

I could flicker between the players and their weapons, changing the color every frame to simulate 8 sprite colors.  Against the mostly black background of the game, this might not actually look that bad.  It also has the advantage of being really easy to do.  The disadvantage is that when flicker does look bad, it looks really bad.  It also breaks hardware missile-to-player collision detection, since the players and missiles will never actually be on-screen at the same time.  I'm not sure I'm willing to give that up.

 

Any other approach that I can think of involves dropping the Intellivision's color coding, at least in part.  This allows some other possibilities.

 

It's clear that the enemies can be color-coded or the weapons can be color-coded, but not both.  So how to differentiate the things that aren't color-coded?  Make them look different.

 

This leads to two approaches:

  1. The enemies all look the same, but are colored based on their type.  The enemy weapons are shaped differently based on their type.
  2. The weapons all look the same, but the enemies are colored based on the type of their weapon.  The enemies themselves look different to represent their type.

Option 2 seems to be the best.  The players are 8 pixels wide, so there's a lot more room to come up with different designs to make them distinguishable.  There's only so much you can do with a 2 pixel wide weapon sprite.

 

So what will I do?  I haven't decided yet.  I'm not exaggerating when I say that this is a problem that's been on my mind for over six years.  I was hoping that after a few 5200 games I would have come up with a good answer, but I'm pretty sure that answer isn't coming.  Now that I'm committed to doing the game, I'll finally have to make a call.  I'm leaning toward different enemy designs, colored based on their weapons.  Time will tell, I guess.  Sometimes the way these things turn out surprises me.

There are a number of solutions ... it may be possible to use raster interrupts.  You can theoretically have multiple enemies as long as they are not on the same hirizontal line, by taking the same player, and having its horizontal position change down the screen.  The player colors can also be changed in this fashion as well.

 

 

Share this post


Link to post
Share on other sites
1 hour ago, Cafeman said:

Actually, this is what I was wondering when I asked you how you'd translate it to POKEY.  I don't know if there is a MIDI utility to translate it to pokey chips.  There are A8 sound packages that you can devote a chunk or ROM for in your program, and use the util to compose a tune with various FX, but I've never used those either.  

I believe I have the Atari 8bit Music Composer program.  I wonder if I notated the music in the 8bit and saved the file if it could be ported to the atari 5200.  I don't know what format or if it can even work.  lol.

Share this post


Link to post
Share on other sites
22 hours ago, Synthpopalooza said:

There are a number of solutions ... it may be possible to use raster interrupts.  You can theoretically have multiple enemies as long as they are not on the same hirizontal line, by taking the same player, and having its horizontal position change down the screen.  The player colors can also be changed in this fashion as well.

The central problem is that the missile colors are tied to the player colors, and not independent.  Fifth player mode gets you an independent missile color, but it's the same for all four missiles.  Without resorting to sprite flickering or restricting the enemies to specific vertical zones (which I believe the 2600 version does) I can't get the enemy/disc color combinations that the Intellivision can do.  I'm a also using a five-color playfield mode, which means one of the playfield colors is shared with the missiles in fifth-player mode.  I would have to make some serious gameplay sacrifices to match the color scheme the Intellivision uses, and I'm just not willing to do that.  I also have some other surprises planned that would compromised by doing anything too crazy, so I'll just have to get by with a less than optimal solution.

 

Sadly, I won't be able to get much done this weekend because of real life stuff.  Today I went and mopped up a few little things that had been bothering for me a while.

 

In the original game, if a character catches their disc while in the blocking or crouching stance, they immediately stand up.  I've made this happen.

 

Related, you can now throw your disc from the blocking and crouching stances.  I think I had this working at point but I broke it when I made some changes to the crouching logic.  It works again.

 

I also made sure that the disc is thrown from a common position no matter what state the character is in when they throw it.  Previously it was thrown from where ever it happened to be located in the carrying or blocking state.  The new behavior more closely matches what the Intellivision does.

 

I also made sure you can go back to the blocking stance after crouching.  I missed this the first time through.

 

I'm not sure if I'll find time to work on this tomorrow, but if I do it will most likely be to fix up some similar little things.  The next big feature to implement is player damage and death, but that will have to wait for next week.

  • Like 4

Share this post


Link to post
Share on other sites
1 hour ago, phuzaxeman said:

Hey Ryan, how is the player damage and death in the game going?

It's closer.  I got the player taking damage and the game ends when your health hits 0.  The damage system is very simple right now, I still need to add the appropriate animation effects and make the player's speed decrease like it does in the real game.  I also haven't dealt with health recovery yet.

 

I fixed some glitches today, the biggest one probably being that the hit detection for blocking was actually totally wrong on one axis.  I've also been trying to nail down exactly when an enemy is considered dead for spawning purposes.  In the Inty game, enemy discs are allowed to continue in flight after the enemy dies, which makes this rather complicated.  I mostly got this whole mess sorted out today, but ended up introducing a bunch of bugs into the wave spawn code so I'm not quite there yet.

 

When the player "dies" the game just goes into a lock-up loop at the moment.  It does look for the reset key while in this loop, so I guess I sort of have game resetting working, after a fashion.

 

I also took the time to test on real hardware today.  It seems pretty good, although the block/crouch key seems to be a little off.  I'm not sure if that's my code, or the unreliable nature of the 5200 keypads.  Needs more investigation.

 

Here's a pointless picture of the game running on my 5200:

 

intellishot.thumb.jpg.791ec2c1184544fd1a02e59ad3faf5b6.jpg

  • Like 5

Share this post


Link to post
Share on other sites
8 hours ago, Ryan Witmer said:

It's closer.  I got the player taking damage and the game ends when your health hits 0.  The damage system is very simple right now, I still need to add the appropriate animation effects and make the player's speed decrease like it does in the real game.  I also haven't dealt with health recovery yet.

 

I fixed some glitches today, the biggest one probably being that the hit detection for blocking was actually totally wrong on one axis.  I've also been trying to nail down exactly when an enemy is considered dead for spawning purposes.  In the Inty game, enemy discs are allowed to continue in flight after the enemy dies, which makes this rather complicated.  I mostly got this whole mess sorted out today, but ended up introducing a bunch of bugs into the wave spawn code so I'm not quite there yet.

 

When the player "dies" the game just goes into a lock-up loop at the moment.  It does look for the reset key while in this loop, so I guess I sort of have game resetting working, after a fashion.

 

I also took the time to test on real hardware today.  It seems pretty good, although the block/crouch key seems to be a little off.  I'm not sure if that's my code, or the unreliable nature of the 5200 keypads.  Needs more investigation.

 

Here's a pointless picture of the game running on my 5200:

 

intellishot.thumb.jpg.791ec2c1184544fd1a02e59ad3faf5b6.jpg

Great to hear. If you need another tester, let me know and you can send it to me. Just let me know what you wanted tested. My keypads are gold dot upgrades so I would know if something wasn't working. 

Share this post


Link to post
Share on other sites
14 hours ago, phuzaxeman said:

Great to hear. If you need another tester, let me know and you can send it to me. Just let me know what you wanted tested. My keypads are gold dot upgrades so I would know if something wasn't working. 

Thanks, there will be plenty of test builds down the road, and I could use as many people as I can get.

 

I think I ironed out all the bugs I introduced yesterday.  Basically, the game was losing track of how many enemies were alive at any given time, which completely screws up the appearance of new enemies.  The way this is working right now is supremely hacky and I don't like it.  I might need to do a significant rewrite of some of this logic.  I decided to use the lowest digit of the score to track the enemy count so I could see it (this digit is normally always 0) and I left that code in there until I'm certain the issues are fixed.  If you see any screenshots with a number other than 0 at the end of the score, that's just debug code.

 

I also fixed up some of the timings surrounding enemy respawns.  They might need a little tweaking still, but there were some bugs in the areas where these timers got reset and started.

 

My coffee maker stopped working this morning, and since a programmer is just a machine that converts coffee into code, I think I'm done for this weekend.  Cleaning up this spawning logic was a big deal, even though it's not the sort of thing that shows up in screenshots and videos.  Next, I need to add the rest of the details to player damage, then I should be able to start adding the other enemy types.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...