+Andrew Davie Posted April 10, 2004 Author Share Posted April 10, 2004 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 Quote Link to comment Share on other sites More sharing options...
kisrael Posted April 10, 2004 Share Posted April 10, 2004 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. Quote Link to comment Share on other sites More sharing options...
K3V Posted April 10, 2004 Share Posted April 10, 2004 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 Quote Link to comment Share on other sites More sharing options...
Sheldon Sims Posted April 10, 2004 Share Posted April 10, 2004 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! Quote Link to comment Share on other sites More sharing options...
Albert Posted April 10, 2004 Share Posted April 10, 2004 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 Quote Link to comment Share on other sites More sharing options...
TheRedEye Posted April 11, 2004 Share Posted April 11, 2004 "load: class GreatBallsOfSlime.GreatBallsOfSlime not found" Quote Link to comment Share on other sites More sharing options...
StanJr Posted April 11, 2004 Share Posted April 11, 2004 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? Quote Link to comment Share on other sites More sharing options...
Mindfield Posted April 11, 2004 Share Posted April 11, 2004 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. :-) Quote Link to comment Share on other sites More sharing options...
Kuddy Posted April 11, 2004 Share Posted April 11, 2004 "load: class GreatBallsOfSlime.GreatBallsOfSlime not found" Quote Link to comment Share on other sites More sharing options...
Albert Posted April 11, 2004 Share Posted April 11, 2004 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 Quote Link to comment Share on other sites More sharing options...
StanJr Posted April 11, 2004 Share Posted April 11, 2004 ah, that explains it perfectly thanks Al. So are you trying to avoid getting to the next level then? Quote Link to comment Share on other sites More sharing options...
Jack Spencer Jr Posted April 11, 2004 Share Posted April 11, 2004 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? Quote Link to comment Share on other sites More sharing options...
Albert Posted April 11, 2004 Share Posted April 11, 2004 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 Quote Link to comment Share on other sites More sharing options...
+-^CrossBow^- Posted April 11, 2004 Share Posted April 11, 2004 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted April 11, 2004 Author Share Posted April 11, 2004 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 Quote Link to comment Share on other sites More sharing options...
xmetalhedx Posted April 12, 2004 Share Posted April 12, 2004 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. Quote Link to comment Share on other sites More sharing options...
Dragonforce-Europe Posted April 13, 2004 Share Posted April 13, 2004 y dont you learn how to develop it for the atari jaguar? Quote Link to comment Share on other sites More sharing options...
supercat Posted June 3, 2005 Share Posted June 3, 2005 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. Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted June 3, 2005 Share Posted June 3, 2005 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 Quote Link to comment Share on other sites More sharing options...
supercat Posted June 3, 2005 Share Posted June 3, 2005 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. Quote Link to comment Share on other sites More sharing options...
skirmish Posted June 7, 2005 Share Posted June 7, 2005 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 Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 1, 2005 Share Posted August 1, 2005 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. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted February 11, 2009 Share Posted February 11, 2009 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 Quote Link to comment Share on other sites More sharing options...
+Pat Brady Posted November 29, 2009 Share Posted November 29, 2009 (edited) 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? ooze.zip Edited November 29, 2009 by bizarrostormy Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted November 29, 2009 Share Posted November 29, 2009 (edited) 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 November 29, 2009 by Wickeycolumbus Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.