50 replies to this topic

[Andrew Davie]

http://www.taswegian.com/twoheaded/atari26...llsofslime.html is a pretty basic implementation in Java of a game I'd like to do for the '2600. Before starting the '2600 version I thought it might be easier to write it in Java and fixup the gameplay -- and see if the game idea is good enough. My Java is very average, so the above may be buggy and/or slow and/or not work at all.
Controls are

left arrow -- move left
right arrow -- move right
control key -- fire
shift key -- fire

The green stuff at top of screen is slime.
The orange stuff is slime that's solidified into ground.
Your task is to keep the slime at bay by shooting.
Slime falls to ground, increasing the ground level.
When you get to the top of the screen, game over.
When slime TOTALLY covers the screen, you get pushed to the next level.
On the next level, ground is the same as before, but you have faster slime.

To Do:
improve game mechanics with various weapons, power ups and better visuals.

Anyway, thought I'd see what people think of the idea.
Cheers
A

[kisrael]

Cool idea!

Right now thought the character is tough to control, especially in the firing and moving at the same time depertment...is that intentional or going to be changed as the game progresses?

The undulation of the "solified" slime was pretty nifty.

[K3V]

kisrael said:

Right now thought the character is tough to control, especially in the firing and moving at the same time depertment...is that intentional or going to be changed as the game progresses?

Agreed there. Cool concept though

[Sheldon Sims]

Great Balls of Slime is definitely cool, but definitely needs to start out slower. Haha. I tried out your Java version, and it is sweet!

[Albert]

Sheldon Sims said:

Great Balls of Slime is definitely cool, but definitely needs to start out slower.  Haha.  I tried out your Java version, and it is sweet!  

I think the speed depends a lot on your computer and version of Java. I was able to get 12,000+ points the first time I tried it and I was no danger of dying. This was on a fairly slow machine, though. I have not tried it on the machine I'm using now, which is much faster.

It is a cool concept and it should translate very well to the 2600 (except for the rabbit on the skateboard, of course). And as Andrew said, more gameplay elements can be added to make the game more interesting. I look forward to watching as it evolves!

..Al

[TheRedEye]

"load: class GreatBallsOfSlime.GreatBallsOfSlime not found"

[StanJr]

Andrew Davie said:

 
When slime TOTALLY covers the screen, you get pushed to the next level.
On the next level, ground is the same as before, but you have faster slime.

extrapolate. If the slime covers the screen, BEFORE you reach the top, it advances to the next level? Why shoot at all? Why not just sit there, let the slime fall and keep advancing?

[Mindfield]

Very nice! Rediculously fast on my machine though; my games seem to last an average of about 30 seconds and top out at about 1100 points. :-)

Play mechanics certainly need improvement, but as a proof of concept, I like it! I think there should be a level-based theme to it though, so that there's only so much slime per level (increasing slightly in quantity and speed with each successive level of course). It'll given the players a break from the action periodically, and give more of a sense of accomplishment to the final product. Maybe add bonuses for how much slime didn't make it to the ground. And the ability to shoot falling droplets of slime. That'd definitely perk things up a bit. :-)

[Kuddy]

TheRedEye said:

"load: class GreatBallsOfSlime.GreatBallsOfSlime not found"

[Albert]

StanJr said:

extrapolate.  If the slime covers the screen, BEFORE you reach the top, it advances to the next level?  Why shoot at all?  Why not just sit there, let the slime fall and keep advancing?

First, you don't get any points if you don't shoot the slime. Second, the slime covering the floor is cumulative and remains as you progress through each level. It does *not* reset when you get to the next level. If you don't shoot, you'll just end up with a game that ends relatively quickly, and no score.

..Al

[StanJr]

ah, that explains it perfectly thanks Al.

So are you trying to avoid getting to the next level then?

[Jack Spencer Jr]

It needs a shark. The present java game, buggy as was already noted, has little to it. The slime drips down, you shoot the slime and you're eventually overrun and the game ends. There is not stopping it and my games thus far are clocked under 10 seconds. I shoot one piece of slime and six other pseudopods drip down further than the one I shot. No hope of lasting more than a few seconds. A novel concept in danger of becoming repetitive fast.

Oddly, it reminds me of a game concept I never did anything with back in high school. The concept was coins were falling from the sky and you had to catch then. If you missed, you couldn't pick it up and it would eventually fill the screen. Sort of a weird combination of Tetris and KaBoom. Oh, well.

I mention it because maybe shooting the slime should be a secondary power-up effect and you should catch the slime instead?

[Albert]

StanJr said:

ah, that explains it perfectly thanks Al.

So are you trying to avoid getting to the next level then?

As the game presently stands, yes. You want to keep the slime at bay as long as possible and prevent it from reaching the bottom and piling up.

..Al

[-^Cro§Bow^-]

It is cool concept..but on my P4 2ghz it is nearly impossible to really play. The Slime simply falls at a rate that is way way faster than my rabbit can move. also, I am not able to move and shoot at the same time. I have to move where I want...and then press fire and them move..and then fire.

Highest score I have managed was 390 points...that's it.

So it would seem that the faster your computer the more impossible this game is to play.

[Andrew Davie]

-^Cro§Bow^- said:

It is cool concept..but on my P4 2ghz it is nearly impossible to really play. The Slime simply falls at a rate that is way way faster than my rabbit can move. also, I am not able to move and shoot at the same time. I have to move where I want...and then press fire and them move..and then fire.

Highest score I have managed was 390 points...that's it.

So it would seem that the faster your computer the more impossible this game is to play.

There's a new version up. I hope I've addressed the speed issues; I've attempted to make it constant no matter what machine it's on (though it needs a minimum, say, 800MHz machine to be playable).

Those having trouble running it might check they have the Sun Java installed, not Microsoft's corrupted abomination.

I rather like the oddity of the gameplay -- specifically, do you decide to let the slime take over and start afresh with the next 'level' or do you keep blasting away, hoping to maximise your score and keep the ground from rising too high.

Anyway, more feedback most welcome -- and thanks to those who've had a go so far

Cheers
A

[xmetalhedx]

It's a fun game, but the java is still a little fast. I assume thats just an issue with the java game though and that the real thing would start out at a slower pace. It would be cool to add a few power ups dripping with the slime where you would have to shoot the slime out from around them and then shoot it to slow down the slime, reduce the level of solidified slime etc.

I'm also curious wether this will be a paddle game or joystick. Another thought is that you could use the driving controller and let the player warp fprm one side of the screen to the other as he goes off the edge. A two player coop mode would also be cool.

[Dragonforce-Europe]

y dont you learn how to develop it for the atari jaguar?

[supercat]

Andrew Davie, on Tue Sep 9, 2003 9:19 AM, said:

Has anyone been looking any more at the ooze concept? If one wanted to control 32 pixels (using reflected mode, and aiming for perfectly-timed stores to PF2) it should be possible to get two-line resolution using an eight-line kernel. The key would be to store the height of each column in two ways: the most significant bits would be stored using 32 bytes of RAM, one per column. The least-significant two would be stored in "bitplane" format, to allow for parallel processing of eight columns at once.

A rough sketch of the code necessary to handle one group of eight columns throughout eight scan lines would be:

; Assume Y is line counter
; This first bit of code may be split among scan lines
 lda now0
 sta was0
 cpy lineheight00
 rol
 cpy lineheight01
 rol
 cpy lineheight02
 rol
 cpy lineheight03
 rol
 cpy lineheight04
 rol
 cpy lineheight05
 rol
 cpy lineheight06
 rol
 cpy lineheight07
 rol
 sta now0
 ;49 cycles for this bit [plus a little more if it's necessary to save/restore regs]

; Remaining code is one snippet per scan line.
 lda bitL0
 ora bitH0
 ora now0
 and was0
 sta temp0
 sta pf1
...; 18
 lda temp0
 sta pf1
...; 6
 lda bitH0
 ora now
 and was0
 sta temp0
 sta pf1
...; 15
 lda temp0
 sta pf1
...; 6
 lda bitL0
 and bitH0
 ora now0
 and was0
 sta temp0
 sta pf1
...; 18
 lda temp0
 sta pf1
...; 6
 lda now0
 sta pf1
 sta was0
...; 9
 lda now0
 sta pf1
...; 6

This takes 49 plus 84 cycles to do about 1/4 of the work necessary for eight scan lines. Multiplying this by four yields 532 cycles (out of 608). Not exactly huge gobs of slack time left, but there should be enough. I would expect the code could be optimized further, but the key here is to note the approach. Actually, using the bitplaned-counter approach might be more efficient than using the discrete counters for even the upper bits, but I haven't worked out how to do it really efficiently.

[Cybergoth]

Hi there!

Any on-the-fly calculations like this wouldn't work, as you'll have to rewrite PF1 and PF2 twice every single scannline...

Greetings,
Manuel

[supercat]

Cybergoth, on Fri Jun 3, 2005 6:05 PM, said:

Any on-the-fly calculations like this wouldn't work, as you'll have to rewrite PF1 and PF2 twice every single scannline...

I already took that into consideration. Note that on half the scan lines I do nothing except load a PF register from a temp. The idea would be to arrange the code so that the store would occur at a suitable time. Getting the timing might require adding a few extra register save/restores, but since the X register isn't used for anything it may not, and even if it does there should still be enough cycles to handle it.

The most notable oddity would probably be that the four sets of columns would likely end up not all appearing the same length for any particular 'programmed' length (depending upon where the ror/cpy code was placed). This shouldn't be a problem, though, since the code that sets up the lengths could take that into consideration.

[skirmish]

Hmm,

This is a very rough attempt at ooze, don't expect it to work on the real thing I threw this together in my lunch time after spotting this idea yesterday evening. Timing is way off, I'll try and get the source cleaned up, understandable, and working properly before I post it. Should work in both stella and Z26.

32 pixel wide ooze in Playfield, 1LK, pressing the down button resets the ooze.


 ooze.zip   533bytes   180 downloads

[potatohead]

This is an old thread, but I thought some of you might be interested in playing my ooze game. It's in the 2600 Basic forum. Just posted v1 this morning.

[Primordial Ooze]

I'm planning on reading your tutorials and making this game in the process. I`m gonna start a web site on it soon. Would this be ok with you? Also since it wasn't my idea would you give me permission to sell it commercially?

2600 Hero

[bizarrostormy]

I know this is a super-old thread, but I thought it was an interesting idea, so I worked up an interpretation. I got 16 columns with a one-line kernel. The key is keeping the columns sorted by length, then just masking off the columns in order. No two columns can have the same length, but otherwise they are completely independent.

The top of the player can wobble, but it shouldn't be very noticeable when actually playing.

To-do list:
1. Find and fix the glitches (they become more apparent as things quicken)
2. Randomize column speeds and starting lengths
3. Identify game-over conditions
4. Add sound
5. Paddle control

How many people read this sub-forum? Should I cross-post this to some of the other forums here?

Attached Files

•  ooze.zip   851bytes   73 downloads

Edited by bizarrostormy, Sat Nov 28, 2009 6:11 PM.

[Wickeycolumbus]

bizarrostormy, on Sat Nov 28, 2009 6:01 PM, said:

I know this is a super-old thread, but I thought it was an interesting idea, so I worked up an interpretation. I got 16 columns with a one-line kernel. The key is keeping the columns sorted by length, then just masking off the columns in order. No two columns can have the same length, but otherwise they are completely independent.

The top of the player can wobble, but it shouldn't be very noticeable when actually playing.

To-do list:
1. Find and fix the glitches (they become more apparent as things quicken)
2. Randomize column speeds and starting lengths
3. Identify game-over conditions
4. Add sound
5. Paddle control

How many people read this sub-forum? Should I cross-post this to some of the other forums here?

Welcome to AtariAge That is a great start

You may want to start a thread in the Homebrew Discussion section.

Edited by Wickeycolumbus, Sat Nov 28, 2009 6:51 PM.