Game Idea: Frantic Freddie 2600

[Feralstorm]

Wheee, lookit the newbie buggin' people his first registered day!

 

Anyway, a favorite game of my Commodore 64 days has been Frantic Freddie. I seem to recall when tracking the game down for my C64 emulator that the original author had released it to the public domain (don't quote me on that though). After learning about the hefty Atari homebrew industry, I started thinking Freddie, being a rather simple game by C64 stadards, would translate to the 2600 quite well, and made a mockup screen based on my limited understanding of 2600 limits to illustrate the idea.

 

I'm not a programmer by any stretch, so I doubt I'd ever get anything like this made myself. I won't hold any delusions that coming in with a "hey talented programmers, do this!" would get any results, so I'll just ask the knowledgable folks here what the pitfalls are to making a game like this.

 

Frantic Freddie is a 'run around the screen collecting all the stuff without hitting the monsters' game, with some minor twists. It was hardly graphically taxing for a C64, so that shouldn't be too tough for a 2600. The main thing that set Frantic Freddie apart IMO was that it had buttloads of music - over ten tunes, some of considerable length - to the expense of almost any other sound effects. The music is what makes the game, and would seem to be the biggest envelope-pusher (if not breaker) for the 2600.

 

Anyone here remember Frantic Freddie? I'll answer any questions I can.

[Nukey Shay]

So it's like Fast Eddie?

[Feralstorm]

Hadn't played Fast Eddie before now, so I had to check that out. They do look very similar on the surface.

 

Frantic Freddie: Freddie runs around the platforms, collecting ten "pots of gold" randomly strewn about the level. there is no jumping, so Fred has to stay away from the monsters. the 'ladders' in this game are different than others in that they are also like barriers. For example if Fred wanted to just go form the left side of the ladder to the right, he would have to travel all the way up one side of the ladder and down the other. The monsters do not have this restriction, so they actually have better mobility than Fred (but less speed).

 

Different levels have different arrangements of ladders. The third level (in the mockup screen) is challenging because one ladder divides the entire screen in half.

[Feralstorm]

Not sure if it helps anything, but here's a screen of the C64 original.

 

P.S. Loved Hack'em!, BTW

[Thomas Jentzsch]

The problem is the asymmetric playfield (platforms and ladders) combined with a lot of other objects (sprites). The 2600 simply doesn't have enough CPU time for drawing all of that.

 

A striped playfield (like in Dig Dug, Mr. Do or Thrust) would free some CPU time, but also change the look of it.

[Feralstorm]

I tried reading up in the programming section about that. Didn't realize how much is maintained on a scanline-by-scanline basis, even if the playfield blocks themselves are more than 1 line tall. I don't think some stripes would hurt the look, as long as it's not like 4 blank lines for every 1 drawn one. The game is hardly a graphical tour de force on any platform. I'll have to try an updated mockup to reflect some/all of this new info.

 

On the sprite side of things, there are only five moving objects on screen at any one time - Fred, three monsters, and a item like fruit in Pac-games (the sailboat and ice cream in the screens) which travels from left to right and back unless grabbed. I'd assume flicker is inevitable, since the monsters would be free-roaming.

 

I'll bother folks with an updated mockup later.

 

It's been a fun day. I just made a 7800 power supply by hacking together parts from a Sega power supply and a Zoids toy.

[Feralstorm]

Here comes mockup screen Mk. 2.

 

I tried incorporating blank scanlines for (possible) improved performance, as well as trying to give the protagonist sprite a little better look. And now a question or two...

 

The object of the game is to collect ten 'pots of gold' scattered randomly around the screen. After doing the second mockup, I thought of two possible ways to do these (reduced to 'gold bricks' for this version). One way would be to use playfield blocks for them (as seen in the mockup) - I could place them as I please, but they would have to be the same color as the ladders (unless there's some special tricks I don't understand). The other option would be to use the 'missile' or 'ball' objects. I don't know the limitations on redrawing them to appear ten times though, or which option would be easier on the CPU cycles.

 

The other question is asking how difficult/CPU intensive it is to have music during gameplay (no sound fx except when the player dies, and the music shuts off for that) I don't know of a lot of 2600 games with much music during gameplay - Dig Dug and Mr. Do's Castle being the obvious ones.

 

(I've come to realize Dig Dug must be a 2600 programming feat, assymetrical playfield, music, lots of independently moving objects)

[Thomas Jentzsch]

I could place them as I please, but they would have to be the same color as the ladders (unless there's some special tricks I don't understand).

No tricks, they had to be the same color.

 

The other option would be to use the 'missile' or 'ball' objects. I don't know the limitations on redrawing them to appear ten times though, or which option would be easier on the CPU cycles.

The problem here is, that you already use the two sprites for other objects, which leaves the ball (makes no sense, since it has shares the playfield color) and the missile (wo share the colors with the sprites).

 

So, you better use the PF here too.

 

But now we have another problem: How do we store the plattform/ladder/gold graphics?

The plattforms and ladders are static, so we could store them in ROM. But the gold isn't, so we would need RAM for it. Storing all the ladders and platforms in RAM too is impossible, since there are only 128 bytes. Each block is 40 pixel wide and therefore requires 5 bytes, and your screenshot shows about 45 of those rows (45x5=220!).

 

But I suppose the gold is vertically limited, right? It can only be on of a platform and not somewhere in the air, right?

 

Then we could mix two display kernels, one displaying the completely static rows and one for the potential gold rows. There would be only 10 (or maybe 5) of those rows, so RAM shouldn't be problem anymore.

 

The other question is asking how difficult/CPU intensive it is to have music during gameplay (no sound fx except when the player dies, and the music shuts off for that) I don't know of a lot of 2600 games with much music during gameplay - Dig Dug and Mr. Do's Castle being the obvious ones.

Music is no problem, it uses only very few CPU cycles outside the visible screen.

 

I am still not sure, if one single blank line (which IMO looks very good) offeres enough free CPU time for doing all the necessary calculations (actually I doubt it).

 

And more than two sprites on the same line would automatically cause flicker.

[wrenchien]

i'd take it the first mockup, if the game was designed to look that way.. would be the more fun one.

[Feralstorm]

The gameplay itself shouldn't be any different. So far it's a matter of getting the game graphics to a point where a 2600 could handle them semi-realistically.

 

Speaking of, I think I'd knock the collectable 'bricks' to one block tall instead of two, to look a little better and save RAM.

[Feralstorm]

I have another mockup, actually a modified version of my last one, to illustrate some odd ideas/questions.

 

This screen adds more blank scanlines to the ladder areas, but not to the platforms/bricks. This helps the look a bit IMO, but also changes around the nature of how its all displayed (for example, the bricks would use ram for three scanlines per platform instead of one 3-line block per)

 

Would doing stuff like this help matters, or just convolute things more?

 

I'm gathering the tools needed to do 2600 programming, and will probably be able to make this game in about ten or twenty years.

[Thomas Jentzsch]

If you add blank lines, it only makes sense if you make them completely blank. So the gold bars would have to be blank there too.

 

No blank lines inside the platforms should be ok if the enemies are vertically restricted and don't use the ladders.

 

But this is all only theoretical. We are getting into details here and unless someone starts to really code the kernel any further discussion is getting very speculative.

[Feralstorm]

I suppose that's a character flaw of mine - I like to speculate heavily on details of things that have a strong likelyhood of never happening.

 

Anyway, I did a little research on the sprites and level designs of the C64 game. (the game becomes much easier to play if one turns off the sprite collisions in the emulator, I've found) and found a lot of level designs that lead me to think I could easily avoid using assymetrical playfields. (except for the gold bricks stored in RAM.)

 

There are two methods to do symmetrical playfields, either repeat the data from the first half of the screen in the same order, or mirrored, right? If it's possible to do game screens with either type, it means the amount of needed data to do one assymetrical playfield could potentailly make four symmetrical ones (two halves, with mirrored and non-mirrored versions of each)

 

Speculatin' iz fun!

[Thomas Jentzsch]

There are two methods to do symmetrical playfields, either repeat the data from the first half of the screen in the same order, or mirrored, right?

Right.

 

If it's possible to do game screens with either type, it means the amount of needed data to do one assymetrical playfield could potentailly make four symmetrical ones (two halves, with mirrored and non-mirrored versions of each)

Yup, and it would save you a lot of CPU time, since you don't have to rewrite the registers each scan line, only when the pattern changes.

[Feralstorm]

> Yup, and it would save you a lot of CPU time, since you don't have to rewrite the registers each scan line, only when the pattern changes.

 

 

That's the other obvious goodie.

[Feralstorm]

Oh god, he's posting them two at a time now!

 

Anyway, more playful screen mockups, this time two levels of the same data in mirrored and repeated symmetrical modes, which leads me to another question...

 

Is there a method for 'flipping' sprite data left-to-right (or even top-to bottom for that matter) so data for a character facing one direction can be reused for the reverse, or do full sets of data need to be made for both left and right?

[Thomas Jentzsch]

Is there a method for 'flipping' sprite data left-to-right (or even top-to bottom for that matter) so data for a character facing one direction can be reused for the reverse, or do full sets of data need to be made for both left and right?

Yup, the Atari 2600 can flip left/right. Up/Down had to be done in software, but that's not really an option inside a tight kernel.

[Dr. Van Thorp]

If you are going to modify the background color on the pot-of-gold scanlines so that the ladder steps are golden yellow, then the ball object will also be golden yellow, and you can use the ball for the pots of gold, and not have to store those portions of the playfield in RAM.

[Feralstorm]

Aside from the RAM savings, what's the pros/cons to using the ball object versus playfield graphics?

[Dr. Van Thorp]

The RAM savings is the big thing.

[vb_master]

Looks like Adventures of Tron...

[Pac Munchkin]

Yes I loved Frantic Freddie, but have to wonder if it could be hacked from Fast Eddie, the ladders would need be changed of course and the sprites. That music would probably need that Pitfall II sound chip? I do remember it was very fun and very fast. also the ladders were like walls so that made it very challenging, a very fun and unique game really!

 

Wade

[Feralstorm]

Wow, my dead thread of "hey programmers, I've got a game idea!" newbieness returns!

 

I don't think the game would need any extra hardware for the music, since it had almost no sound effects during gameplay. As long as the music could be pared down to two channels, it would be doable. I've seen some nice music come out of a 2600 when there's no other demands on the sound system.

[Pac Munchkin]

You are right I don't remember sound effects only that music constantly playing. Was it the Entertainer I don't remember what it was but I remember it was constant.

 

Wade

[keilbaca]

I was thinking, with the rise of superchip boards from CPUWIZ, that could fix the limited RAM problem.