Game Idea: Pool Hoppers

[salstadt]

Hey all,

 

I came up with a very basic idea (a little similar to my "Fade Out" concept) that I think could work very nicely on the 2600. I'm pretty sure the drop shadows will have to be nixed, but that aside it's a pretty simple design. Basically, it's a 2-player (or 1-player v. computer) game in which the player is trying to get across a pool. How do they do this? By hopping from little platform to platform. The platforms are each a square, and exist like amoebas -- they replicate constantly. Each platform will, every few seconds sprout from two of it's four sides, two new platforms. However, on the following turn the original platform will disappear.

 

So players have to hop from platform to platform. They can either play it safe and only hop to a new square they see appear, or they can hop as fast as they want and chance a platform disappearing right underneath them. The difficult part is that the guys are the same color as the platforms, so after fifteen or twenty moves, like that game of following the ball under three cups. you might very well forget exactly where you are. To help you, a distinct sound will BEEP for each player whenever they take one step, however beyond that keeping track of your player is all memory. Confusing? Here's a basic walkthrough:

 

1. Two little guys, two starter squares. Note the score (0 to 0).

 

2. Where'd the guys go? Why, they hopped onto the squares.

 

3. Boom, the platform replication begins! The player on the left can now choose to go either up or right. The player on the right can go either up or down. They don't have to move, but....

 

4. See? Look at the right, where the original square was. Empty. Two turns after it appeared, the block is gone. The same goes for every block in the game. Notice now that on both sides, each of those two new squares has spawned, creating 4 more squares on each side of the field. But why hasn't the original square on the right vanished? Oh, but it has! It's just that another new square has been spawned where it originally was. Where are the two sprites? Who knows, that's the players' responsibility to remember where they're moving.

 

5. More duplicating and eventually...

 

6. The board will look something like this. Since for every 1 square we lose, we get two more, the board will fill up pretty quickly (though there will still be gaps appearing and disappearing, because if two squares, or even four all spawn in the same spot, obviously only one is displayed, leaving more empty areas elsewhere).

 

7. Oh, what happened? One of the players hopped off their square!

 

8. Splat! They die, and look at the score. It's now 1 to 0.

 

9. The other way to score points? Simple -- get to the other side, like this little guy did. The game will be played until a certain point value is reached by one of the players (ie, first to 5).

 

10. As I write this, I realize that it might get confusing enough without the invisibility of your sprite (just on whether a square is gonna stay in front of you long enough). So I think two modes would be great -- 1. Hard Mode (in which your player is invisible, and you must rely only on your beeps and memory to know where you're going), and 2. Easy Mode (in which you can see your player, and only have to worry about hopping on platforms that will last.

 

11. And lastly, I thought a Battleship (the board game)-like bomb would be cool, especially with invisible players. Reach this bomb and the platforms freeze. You then get to select one platform to drop it on (or maybe it attacks a group of 9 platforms (3x3), it's up to the coder). If you guess where they are correctly, BOOM! They die, you get a point. Guess wrong, and the game continues (or maybe you die, not sure yet). In the visible game, it would be a matter of 'Do I make a break for the bomb, or do I go for the other side instead?' or maybe it would not be available in that mode.

 

So, that's my idea. If you have comments, post below. If you're interested in possibly producing this game, message me (or email me at adamctierney@hotmail.com). I'd be happy to whip up as many sprites and art as you need for it, and of course since the coder is everything on 2600 we could modify the idea all you want. Again, I'm pretty sure that drop shadow will hafta go away, and the red pool floor now is a little too similar to the sprites in the first 9 screens. But if it would be possible to simply program a demo where a square creates two new squares, then disappears (and yes, converse to the last couple of screens, left and right sides COULD be mirrored at all times, because chances are the players aren't taking the same routes) then this game is entirely possible. And to my knowledge, it's pretty original and should be a blast.

 

Ok, comment away. And if you did, thanks for taking the time to read through all this.

 

- Adam

[Video]

That Idea's the shiznite. I would say that the shadows would mostlikely have to be dropped though, as the easy way to make the game would be to use two background colors, rather than using missiles or balls to make them (which may not be possible) But BG would be fine. I like the Idea of the battleship bomb, taking out nine square grids, with inviso players, that'd be challenging still, as you have no Idea where the opponant is.

[moycon]

Another awesome idea from salstadt!!

 

Sayyyyyyyyy. You didnt used to work for Ideas Revolution did you!!!??

[Han]

Another awesome idea from salstadt!!

 

Sayyyyyyyyy. You didnt used to work for Ideas Revolution did you!!!??

 

In that case they certainly have gotten their act together ..

 

@salstadt: Sounds like a really cool idea. How about giving the players the possibility to press fire to reveal their position, if they get lost. Thus revealing their position for the other player, making them vulnerable to attack …

[Thomas Jentzsch]

Cool idea!

 

And looks very doable too. Even some kind of shading might be possible (e.g. striping with fore- and background colors).

 

But since I usually (have to) play my Atari games alone, do you have some single player variations in your mind?

[StanJr]

Very, very intriguing idea. I like that fire button reveal recommendation as well.

 

I'd love to see a game like this realized. Myabe someone will pick up the game, or maybe you can take a look at the "Programming for Beginners" forum and do it yourself!

 

Either way, great idea!

[salstadt]

Nah, never heard of Ideas Revolution.

 

Yeah, might as well use the button for something so a 'reveal' would be nice on the Hard Mode.

 

I think it could be done as a single-player by simply slapping some AI on Player #2. Of course, you could do variations. Maybe one mode where you can see everyone has three little badguys all running around, and you must step on them, then get to the other side before time runs out. Something like that -- little gremlin dudes.

 

Thanks for all the comments so far.

 

- Adam

[Thomas Jentzsch]

Nah, never heard of Ideas Revolution.

We haven't again too.

 

Those guys where announcing "great games", obviously without any knowlegde. Unfortunately they didn't even know that and didn't believe those who know. Anyway, it was fun.

[salstadt]

Do "Pool Hoppers"

 

Seriously though, if ya need any art just let me know.

 

- Adam

[Thomas Jentzsch]

Do "Pool Hoppers"

Good idea.

 

I once even made a quick demo for that.

pool_hoppers.zip

[Cybergoth]

Hi there!

 

I once even made a quick demo for that.

 

Can you generate this screen from RAM?

 

Greetings,

Manuel

[Thomas Jentzsch]

Can you generate this screen from RAM?

Don't know, this is just a mockup demo. Definitely not an easy task.

[Cybergoth]

Hi there!

 

Can you generate this screen from RAM?

Don't know, this is just a mockup demo. Definitely not an easy task.

 

I'm counting 21 lines and you're using PF1/2.

That'd make 168 bytes of data for this screen, or?

 

Greetings,

Manuel

[salstadt]

Wow, that demo screen even has the shadows below the platforms. Would that be possible in gameplay? I thought for sure that'd be the first feature to go.

 

Pool Hoppers was an idea I came up with and posted here that generated some interest, but never actually netted a coder. I think aside from Fade Out it's the strongest of the mockups so I'll probably go ahead and do the art even withotu anyone attached. The basic idea is crossing a pool on platforms that multiply and die like amoebas -- each cycle, a square will create two new squares (branching out from one of the four directions), but every two cycles that original square will vanish. So basicaly, you're trying to traverse a pit, and can either do so with risk (just running across any connected squares, hoping they don't vanish and you fall) or safety (only hopping onto a newly-created square each time). Lose track and you can easily step on an area that will vanish beneath you. Winner is the first to their opponent's side.

 

As for 3D, it's possible but Atari 2600 is possibly the worst venue for the idea, since 3D glasses hinge on displaying multiple images across the same horizontal axis, and 2600 is probably the most horizontally-limiting console out there (with sprites stretched 2x wide and bg's generall 8x as I understand it). The way it would be done is simply shaving off 1 pixel per original drawing from the sprites and BGs to seperate the two color layers. The problem is that in 3D the farther you distance the red and blue objects, the more the image pops out. Since Atari BGs are stretched 8 pixels per 1 vert, and sprites only 2 per 1 vert, you would essentially have a game where the BG seemed to pop out around the sprite, who would seem recessed into your TV.

 

Still very possible, although the end result would likely be ugly as hell. Here's a sprite example -- this little guy is offset 1 pixel between the red and blue so if you player a game with him in it, he would hover slightly off the TV set. Actually, you could make it work if you left the BGs 2D, and had three sets of offsets (by 1 pixel, 2 and 3) for the sprites. So for example, maybe your sprite hovers slightly off the TV (1 pixel offset) while powerups, which are smaller anyway are offset by 3, making them appear even closer.

 

Hmm, interesting ideas. Let me know if you want any help playing around with it (I'm essentially an 'I can't code but I love to pixel Atari sprites, so I bug everyone around here to use me' guy

 

- Adam

[salstadt]

Oh crud, I completely forgot that Atari sprites can't generally shift their color mid-line. Well, it might still be possible if you have your game running two to three sprites over each others, for the blue/red/purple, although it seems like that would pretty much eat up the majority of any sprite activity in your game. Still, you would have your little 3D walking man demo at the very least.

 

- Adam

[salstadt]

And of course if you could devise a system with the red and blue sprites seperating on the fly, and the purple crossover sprite adapting to them, you could do some really wild stuff, like making them fly really far out of the screen mid-jump, then pulling the R&B back together as they land. Hmm, how about a topdown adventure game where making your character jump really had them appear to hop out of the TV? That would actually be pretty fun to work on.

 

- Adam

[Thomas Jentzsch]

I'm counting 21 lines and you're using PF1/2.

That'd make 168 bytes of data for this screen, or?

21*4 = 84

 

Except when you are able create those shadows on the fly. Then you'd only need 10*4 = 40 bytes.

 

"Definitely not an easy task."

[Thomas Jentzsch]

Wow, that demo screen even has the shadows below the platforms. Would that be possible in gameplay? I thought for sure that'd be the first feature to go.

Most likely you are right, but maybe someone develops a clever trick for doing that without wasting to much precious CPU time and RAM.

[Cybergoth]

Hi there!

 

I'm counting 21 lines and you're using PF1/2.

That'd make 168 bytes of data for this screen, or?

21*4 = 84

 

That would create a screen with 2 types of solid blocks, but to do the rastered blocks you need twice the data, or am I missing something?

 

Or wait... It's the "same" data twice, or? Just shifted a bit.

 

"Definitely not an easy task."

 

I was asking because I thought of a game using a rastered background, with two uhm... wizards... being able to create solid blocks, each of their own color. A bit like a reversed Solomons Key...

 

Greetings,

Manuel

[Thomas Jentzsch]

That would create a screen with 2 types of solid blocks, but to do the rastered blocks you need twice the data, or am I missing something?

 

Or wait... It's the "same" data twice, or? Just shifted a bit.

Yup, I will try to convert the mockup code into something realistic. Maybe it works, maybe not...

[Thomas Jentzsch]

Works!

pool_hoppers.zip

[salstadt]

So now you're ready to do the real game, right? Right?

 

- Adam

[Thomas Jentzsch]

So now you're ready to do the real game, right? Right?

Unfortunately my ToDo list is still very long. The kernel code is there and maybe someone else will choose Pool Hoppers as his project.

[Thomas Jentzsch]

UPDATE: Now even nicer looking. (interleaved background flickering)

pool_hoopers_2.zip

[salstadt]

Why do you tease me so? Actually, I think of the other ideas I've pitched, Pool Hoppers is probably the strongest so I'm gonna go ahead and do all the animation now. I'll repost when it's done and we'll see if anyone wants to hop onboard then.

 

- Adam