Game Idea: Depth

[salstadt]

"Depth"

 

 

This is the hyper-action game I always wanted to make. Basically, you play a little white and grey samurai, who's stranded in an evil red sea. Monsters are coming out of the ocean (I'll hafta modify their animations so they're swimming, instead of walking) and you attack them as they get near you. You can run around freely, but what makes the game unique is the fact that the sea poisons the samurai. So to survive, you must kill the monsters, then in Frogger style stand on their bodies to stay afloat. Slice, hop, slice, slice, hop, and so on.

 

Each enemy only takes a hit to kill (maybe more for the biggies) and will remain floating and dead for only a few seconds before they begin to sink (they flash and grow darker as they do). While the samurai is on water, his energy (at the top) will decrease. So yes, he can make quick sprints from body to body if he's not able to group his foes close enough, but too much time in the water will kill him. The basic idea is to rack up the highest number of kills (bottom right corner) before energy runs out.

 

The mockup was designed as close to 2600 specs as I could think. Chris (Tumber) has said that you can 2x or 3x any sprite, hence the big baddies, and I think I kept each linechange to around 5 or less. Both of these could be minimized or eliminated if necessary. So feel free to post comments, and as always if anyone might be interested in partnering up to code a project like this, let me know. I think this would be a pretty strong game; Lord knows the 2600 could use a solid actioner, and I've got some good animation designs in mind for his attacks.

 

- Adam

[Thomas Jentzsch]

Sorry, but way too many sprites in one row (vertical area).

 

Basically (without flicker), you can only display two sprites each row independently. You can however display larger (2x, 4x) or multiple (2, 3) copies of each sprite with a few different, but fixed spacings (starting each 16th, 32th, 64th pixel). But that won't help solving the problems here.

[salstadt]

Ah, you're right! Ok, here's take 2. Enemies enter and remain in horizontal patterns.

 

 

- Adam

[Thomas Jentzsch]

That one is almost 100% possible, except for those more than two blocky playfield colors in one row.

 

IMO you should keep a few of the larger ones. They would just block some more vertically space for that sprite.

 

And maybe you could use multiple copies somehow too (Frogger did this almost perfect).

[salstadt]

"except for those more than two blocky playfield colors in one row."

 

Which ones? And yeah, I could have them as repeated sprites, the only problem being what happens when the hero kills one of them? Suddenly they're no longer identical, unless we could figure out some system where as soon as the hero killed sprite 3, #1 would disappear, killing #4 would make #2 disappear and so on. The only problem then is that we're making the bodies sink based on enemies slain, rather than time. Of course I guess we could make it essentially like -- strings of enemies come along, and as you kill them, the older bodies disappear. But it's still best to kill them because waiting too long will make them sink anyway. Something like that.

 

- Adam

 

Here's try #3 at the mockup:

[salstadt]

Actually, ya know limiting each line to only 2 unique sprites (so maybe 1 dead and 3 in a row, or 2 dead, etc) probably wouldn't be too bad because we want to limit the player's island options. If there are too many bodies floating around, it will just be too easy so maybe limiting the number of guys coming at once will make it more puzzle-y and force the player to put more thought into which order they kill in.

 

Also I forgot to mention it, but the enemies can also attack the hero and drain his energy, if he faisl to swipe at them.

 

- Adam

[salstadt]

(dang lack of edit button)

 

And of course some strategy will come in as the player lets them get in very close, because if you kill off enemies too far away (look at how the bottoms at the bottom of screen 3 are distant) they will block other enemies from reaching you, forcing the player to run over the water to get to them. So gameplay will be trying to draw them all into the same locale, but at the same time making sure the player isn't vulnerable (for example, having enemies hungering on all sides of the 'bridge' is good for lining up more islands, but it'll be a helluva gauntlet to run because if there are enemies on both sides of the hero, as he swipes one the other will scratch him on the back).

 

- Adam

[Thomas Jentzsch]

Those dark shadows below the mountains. There we have three brown to orange colors in one row. This is possbile but requires to extra color writes each scanline.

[salstadt]

Ah, ok. This should work then.

[Thomas Jentzsch]

Yup!

[Out_of_Gas]

This would so rock as a cart. Really looking foward to more updates on this.

[jetset]

Am I missing where the file is to try this one out ?

[bjk7382]

Am I missing where the file is to try this one out ?

 

 

Title of the thread says it all

 

Only a mockup, no game exists (yet)

[raindog]

I don't see how that last shot can work with the samurai plus four enemies all on the same scanline, at least without flicker.

[salstadt]

Because the monsters are duplicates. Same reason you can have 6 or even 9 sprites in line for a game like Space Invaders/Instigators. Obviously, when the hero attacks one of the lined badguys, and they die, any previous floating body on that line will have to vanish. But I'm sure some system could be worked out so that it was effective, driving and predictable.

 

- Adam

[raindog]

I'm sorry, I should have phrased that better, I realize this isn't [stella].

 

I don't understand how you can have five objects comprised of three independent (and independently moving) shapes on one scanline - three left-facing enemies, one right-facing enemy, and the samurai. The Space Invaders "2 sets of 3 copies" thing explains the three enemies facing left, but that's all. The enemies can't be drawn with the ball or missiles as far as I can tell; can the samurai? (holy color register strobing batman)

[salstadt]

Ah, I see (you'll have to forgive me, I'm not a coder). I didn't factor the samurai in with the limitations. If he was absent, it would work, correct? (of the two sprites one can have per line, does a straing of them only count for one, ie. leaving another spare?) If this is the case, I think what I'll have to do is simply redesign the movement of the game into something more specifically puzzle-oriented about the way the monsters emerge, their patterns, etc. because it's looking like the rampant free-for-all action idea isn't panning out. If anyone has any ideas of how the above screenshot 4 coudl work (I know you're all innovators here) voice your ideas.

 

"The enemies can't be drawn with the ball or missiles as far as I can tell; can the samurai?"

 

Is this problem regarding shape and color? I tried to get a little more detailed on this mockup, but obviously every aspect could be whittled down. I'm sure the game could be strong even with little 4x4 cubes for every sprite, so the visuals can absolutely be modified or toned down if that's the issue.

 

- Adam

[Thomas Jentzsch]

Sorry, I had missed that problem.

 

"The enemies can't be drawn with the ball or missiles as far as I can tell; can the samurai?"

Not in the current shape and color.

 

The missile share the color with the sprites, the ball with the playfield.

 

The shape is limited to 1, 2, 4 or 8 pixel wide bars, which can be resized and moved horizontally each scanline. I am sure you can still make some nice graphics out of this restriction.

 

BTW: IMO flickering the enemies at 30Hz should be acceptable.

[salstadt]

So, no one's interested? Of all my mockups, I think this has the most potential for becoming a really solid game.

[+Nathan Strum]

I think it has more to do with a lack of time, than anything else. There are only so many 2600 programmers who have the time to work on projects of their own, much less someone else's.

 

Have you considered checking out the 2600 Programming for Newbies forum? It might be worthwhile to take a shot at programming it yourself, or at least laying some of the groundwork.

[raindog]

I think you'll find that most of the 2600 programmers who actually produce stuff tend to be working on only one thing at a time, as opposed to people like me with my delusions of Ballblazer, Moon Cresta, and Astro Invader (for only two of which I've written any code. ) Your collaboration with Christopher seems to be bearing some tasty fruit now; if no one hooks up with you immediately on Depth, why not wait till Fadeout is done and try to talk him into another project together? I know I would cheer.