Jump to content
IGNORED

Intellidiscs: Weekly development log


Ryan Witmer

Recommended Posts

It should be duly noted that most, if not all, the Mattel manuals are written by the marketing department and not the actual programmers, or anyone in that department. 

 

So at this point it sounds like the rest is up to your interpretation and how you want the game to be for the system. 

 

Also maybe make a post over in the Intellivision area, or the Intellivision programming area, to see if someone could take a deep dive into the rom and try to get the answers you need. 

Link to comment
Share on other sites

What an interesting day this has been.

 

I started off by trying to push forward on the difficulty curve, but while testing the Inty game I started to notice a few things...

 

I was trying to figure some of the logic behind the reinforcement enemies after the advanced enemies start appearing, and then suddenly it hit me.  I think I finally cracked the code.  I think I completely understand the way the original game determines which enemies appear, both the full waves and the reinforcements.

 

I'm not 100% sure I'm right, but all of the testing I've done since I got this idea has backed it up.  I'm not planning to write any more code today, I need to do a lot more testing.

 

If I'm right, and I'm pretty sure I'm at least partially right, the way I've been handling enemy spawns is wrong.  In a way, this is good because the way I was doing it is clumsy and tedious.  If my testing doesn't break my theory, the right way is much simpler and will make the rest of the difficulty ramp implementation so much easier.

 

This does mean I'll need to step back for a bit and rewrite the enemy spawn code.  It will totally be worth it though.  Off to do more testing!

  • Like 3
Link to comment
Share on other sites

  

OK, just got done rewriting the enemy generation to do things the right way.  It's so much simpler and smaller.  This weekend's progress has been... sideways I guess.  This is still super important because the path forward is so much easier now.

 

If anyone wants to nerd out to the details of exactly how the game works, keep reading.  If you want to keep a sense of mystery and awe around Deadly Discs, you should probably stop.

 

________________
|    1  2  3    |
|               |
|1             1|
|2             2|
|3             3|
|               |
|____1__2__3____|

This is basically the door layout.  Each side has three doors, and they have this relationship.  1 is the primary door, 2 is the secondary door, and 3 is the last door.

 

At any given score level, there is a completely fixed "formation" of enemies that will come from a random side.  The enemies are each assigned to a door, enemy #1 goes through door #1 of that side, and so on.

 

The key here is that the enemy mix is 100% predictable.  I never noticed it before because of the way the doors are arranged, I expected a clockwise ordering so for example, door #1 on the bottom would be on the right, but that's not how it works.

 

So, since the composition of a new wave is predictable if you know the score table, what about the reinforcement enemies?  I learned the following:

 

The reinforcements enemies always enter through door #1, but on a random side.  I don't know how I never noticed this before, but now that I've seen it I can't un-see it.  I've been playing for hours and this always seems to hold.  The next question is, what kind of enemy is the reinforcement?

 

Well, it turns out this is very simple.  If enemy #1 is dead, the reinforcement is whatever enemy #1 should be at your current score level.  If enemy #1 is alive, then the same applies to enemy #2, and so on.  Note that the reinforcement enemy is chosen based on your score at the time of reinforcement.  One way to see this is to go above 10,000 points by killing enemy #1 in a wave.  At 10,000 points, enemy #1 becomes a leader, so the reinforcement will be a leader.

 

The leader discs appear to be totally random, with the caveat that the homing discs show up (I think) at 20,000 points.  So, the only random aspects of enemy generation are the side of entry and the leader discs.  Everything else is deterministic.

 

This simplifies the code enormously.  Before figuring this out, I was coding each difficulty step based on what I thought I was seeing.  I also had to handle reinforcement enemies separately.  Now I know they all come from the same source, so things are so much simpler.

 

I have this table:

 

enemy_table.thumb.png.927944631de1a80a8d9eec337c7a7282.png

 

Now that I have the code written (excluding homing disc generation and the final guard enemies) all I need to do is keep playing the game and note the formation changes at each score level.  Simple.

 

This is probably where I quit for the weekend, but this is pretty huge.  Next week I'll start pushing further up the difficulty ramp with this system in place.  I expect to start making much faster progress.

  • Like 3
Link to comment
Share on other sites

I pushed the difficulty ramp up a couple of levels, the 15,000 and 20,000 point levels are now in place.  This was so easy after the work I did last week, just add new values to the table and update the code that checks your score.

 

A couple of important things happen at 20,000 points and now I need to stop and work on those.  The first is that the homing disc enemies start showing up.  The second is that the player gains a health point (3 -> 4) and the game just generally speeds up.  The player health goes from 4 -> 5 at a later point, 100,000 I think, it's in the manual so I can look it up when I need it.

 

The health/speed increases are easy, except for one interesting detail.  Does the player's health increase once you cross 20,000 points, or does the maximum health just go up?  For example, if at the moment I cross 20k I only have 1 HP remaining, do I gain 1HP for crossing 20k, or does the maximum just go up to 4 and I need to recover all the way up?  Minor detail, but I'd like to get this right.  This is going to tricky to figure it out from observation of the original game and if I can't tell, I'll probably just bump up both health and max health at the appropriate places.

 

I'd would like to get both of these things done this weekend.  Tomorrow appears to be launch day for this year's AtariAge homebrews and I have a game in that batch, so I may lose some time tomorrow just reveling in that.

 

Once these two details are settled, I'm going to pause on the difficulty ramp and start working on the recognizer battles.  I don't know how long it's going to take to get those working, but I want to at least get going on it.

  • Like 1
Link to comment
Share on other sites

After some research, this is what I believe happens at 20,000 (and presumably 100,000) points:

 

Enemies become one step faster.

Player gains 1 HP.

Player becomes one step faster.

 

However, none of these things happen until the first full wave spawn after 20,000/100,000 points.  That's the way I've coded it for now, and the code I wrote already works for 100,000 so I guess I jumped ahead a little on that one.  If I'm wrong, I'm sure I'll see a counterexample as I continue to test and I can always change it.

 

Tomorrow I start working on those nasty homing disks.  This will also require quite a bit of time with the original game to nail down their behavior, but I don't expect too much difficulty.

  • Like 2
Link to comment
Share on other sites

So here they are, the notorious homing disk leaders:

 

large.seeker.png.f7759412b72314a7809fd6895b407e5a.png

 

Due the sprite color limitations of the system, the enemies and their discs must be the same color.  The white homing disc is such an iconic part of the game so I had to keep that color.  Unfortunately, this means that the leader enemies will change color when they get a replacement disc after you block their original special discs.  Oh well, such is life.

 

The disc redirection uses the same aiming logic as the original throw does, and it's currently awful.  When I get around to writing a better algorithm, the enemy aim and the homing behavior will both improve, so I guess that's nice.

 

This is enough for this weekend.  Next week I'm going to work on putting together the recognizer battles.  This is going to require a lot of planning so I may not have anything to concrete to show for a couple weeks.  I also need to do the guard enemies at some point, but since they don't throw their weapons they should be pretty easy.  It's just a matter of figuring out how they move.  I have a sneaking suspicion that their movement is based on the same logic that's used for disc aiming.  We'll see.

  • Like 8
Link to comment
Share on other sites

So here's the first screenshot of anything recognizer related:

 

large.recognizer.png.6a5d6a01ab8699cbc79afa7f324d135a.png

It doesn't do anything, it's just sitting there.  I don't even have the logic written to make it appear yet, this is just a test to see how I can make things look with the sprite plan I have in mind.  I actually think it might be too tall relative to the size of the arena.

 

It will take some extra work to make the "head" a different color.  I can do it, I just need to set up some screen interrupts.  For anyone interested, this is made of two of the player sprites in double-wide mode.  It looks pretty close to the Intellivision version.

 

recognizer.thumb.png.693ef63b1a1ee1c26343649d28f6be99.png

 

Note that in this test screenshot the recognizer decided to show up when I had 5200 points.

 

This is a good start.  I have a basic plan for how I'm going to use the screen objects in this fight and it just might work.

  • Like 5
Link to comment
Share on other sites

3 hours ago, Ryan Witmer said:

So here's the first screenshot of anything recognizer related:

 

large.recognizer.png.6a5d6a01ab8699cbc79afa7f324d135a.png

It doesn't do anything, it's just sitting there.  I don't even have the logic written to make it appear yet, this is just a test to see how I can make things look with the sprite plan I have in mind.  I actually think it might be too tall relative to the size of the arena.

 

It will take some extra work to make the "head" a different color.  I can do it, I just need to set up some screen interrupts.  For anyone interested, this is made of two of the player sprites in double-wide mode.  It looks pretty close to the Intellivision version.

 

imageproxy.php?img=&key=f4dcc336a70d5c68recognizer.thumb.png.693ef63b1a1ee1c26343649d28f6be99.png

 

Note that in this test screenshot the recognizer decided to show up when I had 5200 points.

 

This is a good start.  I have a basic plan for how I'm going to use the screen objects in this fight and it just might work.

Very cool!

Link to comment
Share on other sites

The recognizer fights can be broken into three stages:

 

1. Recognizer enters the screen.  It enters from a seemingly random side, but never the bottom.

2. Recognizer starts fixing doors and sends out that white thing to stun you.

3. Recognizer leaves through the bottom, either because the doors have all been fixed or the player destroyed the eye.

 

Right now I'm working on phase 1.  I have the recognizer successfully entering from the left and right sides.  The top needs some more work.  Moving objects horizontally on the 5200 is trivial, moving them vertically is much harder, and my grand unified plan for phase 1 isn't working for the top entry.

 

This is probably where I'm going to stop for today.  I need to spend some time thinking about the top entry.  I might be able to combine my fix for it with the fix for another issue.  I'd like to clip the recognizer at the score line.  These two issues are closely related and I want to come up with a way to make them both work.

  • Like 1
Link to comment
Share on other sites

Today I worked on some of the player/recognizer interactions.  I had three things I wanted to get done and I did all three, although the last one ended up being more work than I expected.

 

First, I got the player on the screen.  This doesn't seem like much, but the player logic and disc handling was wrapped up in the main game loop and the recognizer is a separate game loop.  I knew that I needed to fix this at some point, so I got it done and now the player's movement and disc code is accessible from both places.

 

Secondly, player collision with the recognizer.  This is instantly fatal and it was trivial to implement.

 

Third, and this is the tough one, getting the player's disc to bounce off the recognizer's body.  I spent some time playing the Intellivision version and I couldn't nail down exactly how the angle is determined.  Every time I thought I had it figured out I would see some really weird thing happen and all my ideas were thrown out.  I've concluded the even the Intellivision game doesn't know what the hell it's doing here half the time so I decided not to sweat it.  In this game, the disc direction just reverses on impact.  There's little gameplay effect caused by this change and at least it's consistent.

 

I also got the "wobbly" disc effect that shows up after it clangs off the recognizer.  You can kind of see it in this screenshot:

large.floppy_disc.png.b87b287d2b01f61af082f7ffb6eca68d.png

In the code this disk state is called "floppy" and that just gets funnier every time I see it.

 

So yeah, I hit my target for the day.  Tomorrow I plan to start working on the getting the recognizer to start repairing the doors.  I'm not sure how far I'll get on that but I should at least get the basics down.

  • Like 1
Link to comment
Share on other sites

So the here's the paralyzer probe and one of the door repair panels:

 

large.probe.png.b30352c55d69e13c4f62aebd351daeea.png

They're both using the same sprite and I'm flipping between them each frame.  This creates a cool transparency effect that works well for these two objects.  They don't do anything yet, but they exist and that's pretty cool.

 

I've started working out the logic behind the door repairs.  Right now the recognizer is able to choose a door to fix and it recognizes (ha!) when it has finished all the repairs.  I still need to make it actually DO the repairs, but I think that's where I pick up next week.

  • Like 4
Link to comment
Share on other sites

Great job.  I would recommend once you get further to put a call out for assistance to improve the characters. The 5200 is mightier than the Intellivision so the graphics can be better. And for upping the ante further, someone might've already made POKEY renditions of the Tron Legacy soundtrack.  :)

  • Like 1
Link to comment
Share on other sites

Alright, got the door repairs working today.  Here's a short video of most of the recognizer stuff to this point:

 

 

Only a few things left to do until the recognizer section is done.  Earlier this week I got the idea to try making the recognizer look more like the one from the movie rather than a solid red monster.  I took a preliminary shot at doing that but it came out terribly so I reverted it.  I need to sit down with some graph paper and plan it a little better.

 

This is where I stop for today because I've got stuff to do, but tomorrow I'm going to start working on that nasty little paralyzer prober.

  • Like 4
Link to comment
Share on other sites

57 minutes ago, Lynxpro said:

Great job.  I would recommend once you get further to put a call out for assistance to improve the characters. The 5200 is mightier than the Intellivision so the graphics can be better.

Unfortunately this is a game whose design actually works against the 5200's strengths, which shouldn't be terribly surprising since it was designed for a different system.

 

When it comes to cool 5200 graphics tricks, the secret is trying to keep sprites from sharing the same TV scanlines.  In this game, all 8 of the 5200's objects could potentially be on the same scanline.  This is makes fun color interrupt tricks basically impossible (there isn't enough time) without turning the game into a flickering mess by doing rotating sprite draws.  In short, on the 5200 there's a compromise between object mobility and graphics detail and in this game everything is completely free roaming, so sacrifices have to be made.

 

As a example, my last game, Magical Fairy Force has 3 color (4 if you count the wings) sprites for each player with completely different color palettes.  That only works because the design of the game keeps the players vertically separated and I planned that out from the beginning.

 

Here I'm going more for color choices that better represent the movie, which is probably the best I can do.

 

1 hour ago, Lynxpro said:

And for upping the ante further, someone might've already made POKEY renditions of the Tron Legacy soundtrack.  :)

Now, sound is a different story altogether.  Let's just say I've got some plans for that.

  • Like 2
Link to comment
Share on other sites

Ryan, I noticed the intellivision version's vertical lines (lines 1,2,4 and 5) starting from the edges of the playfield slant somewhat in to have a illusionary 3d setting effect. Would that be possible to do? I'm not a programmer but I think that would be cool to do. 

 

Everything is looking good.  Excited to hear the sound effects and music. 

Link to comment
Share on other sites

3 hours ago, phuzaxeman said:

Ryan, I noticed the intellivision version's vertical lines (lines 1,2,4 and 5) starting from the edges of the playfield slant somewhat in to have a illusionary 3d setting effect. Would that be possible to do? I'm not a programmer but I think that would be cool to do.

I would be possible, but this is an intentional design change on my part.  The Intellivision game's perspective made movement along the left and right walls really difficult and annoying, so I chose to do away with the perspective.

 

This morning, Vladimir Zúñiga, who's written a few things you may have heard of, posted a recognizer in the Discord chat that looks quite a bit more like the one in the movie.

 

large.probe_movement.png.12b1f047b22ca9431f8ea66f45c19b7e.png

I went ahead and put this design in, I may tweak it a bit further.  I also got the paralyzer probe moving but without any sort of intelligence.  I need to work out a pursuit algorithm.  One thing to note is that the probe's speed goes way up when you stand above the recognizer.  This is because the eye is unshielded from the top.

 

I also think the door panels move way too slowly.  I need to play with the speed tables, but that can be done later.  I'm not planning to do any more this weekend, just not feeling it today, but I'm happy with getting the door repairs done.

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Ryan Witmer said:

So right after I posted this I got the idea to hollow out the recognizer's legs.

 

https://media.discordapp.net/attachments/714647592792883261/792856448945750076/unknown.png?width=666&height=468

 

I like this a lot.  It's reasonably close to the movie version, certainly close than the Intellivision one.

 

TRON Recognizer | Tron, Tron legacy, Tron art

Those little details make a great game. Keep it going! 

 

Not sure if this was asked but will you be selling physical copies of your creation?  Would be really neat if you did. 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...