Design #1: Primordial Ooze

[+Andrew Davie]

I've been thinking for quite a while about developing a game to go along with the tutorial sessions. It should be something simple, yet fun. And I don't particularly like making games that have already been done. But now I have an idea I like, and for now we're going with the title "Ooze"

 

Now the plan is to develop the game here, in conjunction with the occasional post to the [stella] list - you should ALL be using the stella list for solving problems, brainstorming, and general good advice. The purpose of me posting here is to provide a record of game development.

 

Now remember this is just here to show you how the process CAN be done. Like most efforts, it's HIGHLY LIKELY that I won't complete this - or even get very far at all. But we'll have a fun concept to explore, and you may see how some of the problems are solved.

 

So let's get started - here's the actual log (only the names have been changed to protect the innocent) of my first conversation about this game idea. Hence, our title for today... "Primordial Ooze"...

 

Ooze

#1 September 9, 2003

 

adavie2: you're bored, aren't you. i can tell.

anon:actually I'm at a friend's house on a wireless net. But I'm going home now. I will be back online in five minutes.

anon:Later.

adavie2: i had a new game idea.

adavie2: ok bye

anon:Will you be on in 5?

adavie2: i may not be here after 10 though

anon:oh no

adavie2: its 4:30 - leaving at 4:45 for sure

anon:oh.

anon:

anon:what is the idea?

adavie2: haven't got a name for it, but "slime" might be appropriate

anon:go on

adavie2: it starts at the top of the screen

adavie2: across the whole screen

adavie2: and slowly starts descending

adavie2: a whole blanket. like slime.

anon:go on

adavie2: and you shoot stuff at it, and that locally pushes some of it back

adavie2: but meanwhile other parts are accelerating

anon:interesting.

anon:sounds like a game you cannot win

adavie2: so you're constantly.... right

adavie2: it's old-school

adavie2: gets faster and faster, you might get more tools/weapons

anon:could be interesting, certainly easy to do.

adavie2: detergent, etc.

anon:there could be "items" hidden in the slime.

adavie2: matches well to '2600 capability, yet you get full-screen BG graphics

anon:so you would be encouraged to shoot at those areas.

adavie2: yep

anon:yes, that's why I said it would be easy to do.

anon:you could do some nice gradient effects as well.

adavie2: i'd have to put speech in the end "he slimed me!"

anon:LMAO

anon:no, when it gets to the bottom,

adavie2: anyway, just thought of it today

anon:"I'm melllllleting!"

adavie2:

anon:melting, even.

anon:I don't know what "melleting" is.

anon:except bad typing on my part.

adavie2: oh one other thing

adavie2: it accelerates due to gravity, right?

anon:sounds like an interesting idea, I can think of some cool powerups.

anon:no

adavie2: so if you hit a bit, then locally that bit stops - or goes back a bit - and then starts accelerating

adavie2: so all over the screen you have bits of slime going different speeds

anon:you should be able to "push it back" a bit or three.

adavie2: yes, push back

adavie2: and maybe you can "win" a powerup by pushing it all beyond a certain point

adavie2: but the general gist of the game is there. the fiddly bits of gameplay can be thought about

adavie2: i don't think i've seen this idea anywhere before

anon:that could be pretty cool, I like shooters

anon:and it's pretty unique.

anon:I still want to do Arkanoid.

adavie2: i can see lots of things going on the screen, lots of slime shrapnel

adavie2: as you blast it away

adavie2: and flicker for that bit would be perfectly ok - rapidly moving, going down off the screen

anon:yes, it could be quite lively.

anon:Perhaps pieces of it woudl also fall every now and aagain, and if they hit you you would die.

adavie2: you could freeze/solidify sections, etc.

anon:

adavie2: yes, good idea

anon:Yes, you could also get a "wider" weapon sometimes that perhaps shoots three bits wide.

adavie2: slimeactites

anon:yes.

anon:and maybe another that lets you penetrate further.

adavie2: and maybe they could collect on the bottom, too, and restrict your sideways movement

adavie2: or make it slippery and hard to aim properly

anon:a "bomb" that you shoot in and it blows up from within, taking out a chunk.

adavie2: yep

anon:interesting.

anon:I hope you are writing all this down.

adavie2: nope

adavie2: i have a memory like something or other, i forget

adavie2: anyway ideas are a dime a dozen

anon:LMAO

anon:oh really.

adavie2: on the other hand unique game ideas aren't that common

anon:well then, I won't continue.

adavie2: i like it because its old-school, sounds do-able, is unique, and probably fun

anon:yes, I agree with you thus far.

anon:I like old-skool also.

adavie2: i'd probably try and animate bubbles in the slime sections too

adavie2: which would also lend itself to nice gloopy sound effects

anon:yeah, you'd definitely need some type of animation within that section to make it more visually appealing.

adavie2: so maybe I should start this as part of the tutorial section

adavie2: "slimeball" is a nice name

anon:I don't lik eit.

anon:the name, that is.

anon:but that's not a major problem right now.

adavie2: it could be a sort of take on "the thing" that old movie with the slime thingy

anon:Okay, I am going to take off. Talk to you later.

adavie2: seeya

anon:take care! We will speak of this more soon.

adavie2: ok

anon:ta ta

anon:ta ta

*** "anon" signed off at Tue Sep 09 16:40:59 2003.

 

(end of discussion)

 

I welcome your input to this design - feel free to comment in this thread. Add what you want, do drawings if you want. Begin to design the sections that interest you. How would you handle the slime? What limitations would you expect? What sort of gameplay difficulty ramp can there be. Lots of these things need to be thought about before we have a good initial design.

[kisrael]

Huh, I almost missed this, didn't show up all orange.

 

Some preliminary thoughts:

Slime would probably have to be playfield graphic. PF is a little interesting, because it's max 40 pixels across, but 192 pixels up and down.

 

One idea would be to store the whole PF in RAM. At 6 bytes across for the 40 columns, you could store only like 20 rows, a far cry from the 192...

 

Or, you could store 40 "heights", i.e. a number that represents how far down the column of slime extends. 1 byte stores up to 255, so that's plenty of memory. I'm not sure if you'd be able to translate those numbers into determining whether each playfield pixel is on or off in time though...the kernal would be a real bear. (you could store the height bytes in the same order they get placed into the PF memory locations, and then compute which height bytes are modified by a push during the vertical blank, but still)

 

You could gain some time (and/or memory) by not using the full width of the screen, or by making the slime decend in "blocks" of 2 or more scanlines.

 

Still, I'd definately think this kernal is beyond my capabilities... (and not to be a naysayer, but I don't know if it's a great tutorial project since it sounds so difficult...ataris are good at pushing sprites around and creating lots of movement, this is definately a tough (but interesting) row to hoe.)

[Nukey Shay]

I once coded a game like this in Basic I'd just watched a movie called "The Stuff" earlier, so that is what I called it. Just so you know, it wasn't very fun

[+Andrew Davie]

I once coded a game like this in Basic I'd just watched a movie called "The Stuff" earlier' date=' so that is what I called it. Just so you know, it wasn't very fun [/quote']

 

Any chance you still have it somewhere? Even if it wasn't fun, I'd love to see it.

[Nukey Shay]

Yup...I have it on disk. Tho I don't have an SIO2PC Pretty short program tho...would you like me to type it up here?

[+Andrew Davie]

Yup...I have it on disk. Tho I don't have an SIO2PC Pretty short program tho...would you like me to type it up here?

 

Any way you can get it to me, or a screenshot, or something.. would be great, yes please! Always interested in what others have done.

[EricBall]

As for Kirk's idea about using the playfield registers and storing heights, hmm.

 

if we asume y = row number

 

cpy hpf0b4 ; height of pf0 bit 4

ror ; cpy sets the carry bit, shift it in

 

Okay, that makes it possible to create the playfield values on the fly. It's expensive though, 5 cycles per bit. That's far too many for a asymetric playfield which requires 36 cycles minimum per line. So that means a 6 line kernel ((40*5+3*6)/(76-36)). It would be a big 'un too. But not impossible. Two sets of PF shadow registers, update one set while the other is being displayed.

 

And there's no time for sprite updates ((240-216)/6=3.67). Do I hear a 7LK?

[Nukey Shay]

10 DIM A(80),AA(40):B=3:M=2:RESTORE:FOR I=1 TO 39:READ J:AA(I)=J:NEXT I:AA(0)=42

11 FOR I=0 TO 80:A(I)=0:NEXT I

12D.28,33,51,29,43,26,36,35,32,57,48,37,38,50,27,21,56,45,31,20,44,30,24,55,47,53,22,41,54,39,59,23,40,52,34,58,46,49,25

15 GR.21:XX=2:T=79:T1=0:T2=1:POKE 708,200:POKE 709,14:POKE 710,56:FOR I=20 TO 59:A(I)=0:NEXT I:IF B>0 THEN GOSUB 103

20 X=59-PADDLE(0)/5.7:COLOR 0:PLOT XX-2,46:DR.XX,44:DR.XX+2,46:COLOR 3:PLOT X-2,46:DR.X,44:DR.X+2,46:XX=X

23 S1=INT(SC/1000):POKE 764,255:IF PTRIG(0)<>0 THEN S=-1:SOUND 0,0,0,0:GOTO 27

24 S=7-A(X)/7:IF S>T THEN SOUND 0,3,4,1:S=-1:GOTO 27

25 S=7-A(X)/7:A(X)=A(X)-S:SC=SC+S:IF A(X)<0 THEN SC=SC+A(X):A(X)=0

26 COLOR 2:PLOT X,43:DR.X,A(X):SOUND 0,50,8,10:COLOR 0:PLOT X,43:DR.X,A(X)

27 T=T-S:IF T<0 THEN T=0

28 IF T>79 THEN T=79

29 COLOR 0:PLOT T,47:DR.79,47:IF T>0 THEN COLOR 2:PLOT 0,47:DR.T,47

30I=INT(RND(0)*40)+20:J=RND(0)*T2:A(I)=A(I)+J:TRAP200:IFA(I)>=1THEN COLOR1:PLOT I,0:DR.I,INT(A(I)):IF A(I)>=44THEN200

35 IF PEEK(764)<>255 THEN GOSUB 100

40 T1=T1+0.3:T2=1+T1/10:IF T2>9 THEN T2=9

90 S2=INT(SC/1000)-S1:IF S2>0 THEN B=B+S2:M=M+S2:GOSUB 103

99 GOTO 20

100 IF PEEK(764)=28 OR B=0 THEN 150

101 COLOR 0:FOR I=0 TO 39:J=A(AA(I)):J=J-RND(0)*45:IF J<0 THEN J=0

102 SC=SC+A(AA(I))-J:PLOT AA(I),J:DR.AA(I),A(AA(I)):A(AA(I))=J:NEXT I:B=B-1:PLOT 0,0:DR.19,0:IF B=0 THEN RETURN

103 COLOR 2:FOR I=1 TO B:PLOT I*2,0:NEXT I:COLOR 0:PLOT 79,0:DR.79,0:IF M<1 THEN RETURN

104 COLOR 3:FOR I=1 TO M:PLOT 79-I*2,0:NEXT I:RETURN

150 IF PTRIG(0)<>0 THEN 150

151 RETURN

200 FOR I=0 TO 255:II=INT(RND(0)*40)+20:J=RND(0)*7:A(II)=A(II)+J:TRAP 202

201 SOUND 0,I,4,8:COLOR 1:PLOT II,0:DR.II,INT(A(II))

202 NEXT I:SOUND 0,0,0,0:M=M-1:IF M>-1 THEN 15

203 GR.37:POKE 710,0:POKE 709,14:POKE 708,200:POKE 752,1:? "GAME OVER SCORE = ";SC

204 ? "PRESS PADDLE TRIGGER TO PLAY AGAIN":M=2:B=3

205 GOTO PTRIG(0)*190+15

 

Use the first paddle, and shoot the "stuff" back up to the top for points. Bonus points are aquired by shooting a line of goo all the way to the top...but be careful not to spend too long on one line! If you shoot too often, the gun will need to cool off. Fortunately, you have smart bombs that you can use when the action starts getting intense (press the Escape key...git me outta here!). 3 turns & smart bombs per game.

[Nukey Shay]

Hang on...the game is quitting right away in Atari800win...I must have mistyped something...

thestuff.zip

[Nukey Shay]

Oh...I missed a line Add this:

 

99 GOTO 20

[+Andrew Davie]

Oh...I missed a line Add this:

 

99 GOTO 20

 

 

Quite remarkable. This is almost exactly my visualisation of the fundamental game. Animate the slime, add in various tactics to remove slime, allow it to fall to the ground, allow you to move through it - game over when screen is completely filled rather than when slime touches you. But yes, I'll credit you with the design/concept credits on this one!

 

(edit) Forgot to mention, the further a slime bit gets down the screen, the more it accelerates. Long bits of slime break off and fall as slime droplets to the bottom, where they accumulate.

 

You can move through slime at the bottom, but it impedes your progress (slows you down). You can drop bombs on the ground, and they will blow holes in any slime there. They'll also throw you up/to the side, if you're wanting to move through some thick slime on the bottom of the screen this could be a good way to do it quickly.

 

Remember, it's not touching slime that kills you - it's having the whole screen filled with slime.

 

You don't have unlimited weaponry - you have to pick it up from various places (ie: weaponry may be embedded in slime as it comes down) or you might just get extra weaponry every x points. So unless you manage things carefully, you're going to run out of weapons before you can beat the slime back.

 

Clear the slime off the screen for the next level.

 

Each level introduces new weapon types/capability, but also has more rapidly moving slime.

[Nukey Shay]

I like the idea of power-ups and mucking through the sticky goo. Gut how would someone animate the slime trails on the 2600? With only 40 pixels across the screen, that doesn't leave much room for detail.

[+Andrew Davie]

I like the idea of power-ups and mucking through the sticky goo. Gut how would someone animate the slime trails on the 2600? With only 40 pixels across the screen' date=' that doesn't leave much room for detail.[/quote']

 

I'm thinking the main body of the slime "bubbles". We may get into matrix-based animation systems - essentially the screen is divided into a grid of m x n pixels, each of those grid elements can be one of n 'frames' and the frames are drawn so that they animate.

 

As for animating the slime trails, they won't get very long - remember the ones which DO get elongated just break off and fall as droplets. At that point they become sprites. So the main PF will be essentially a blob, animating, and the leading edges won't animate, but nor will they be very long. And one should probably make the whole thing ripple and quiver at its leading edge anyway, not just static.

 

So I don't think there will be too much of a problem.

[kisrael]

That is a very impressive bit o' Basic! The Atari really was one of the best computers for that stuff.

[Nukey Shay]

Not really Andrew's concept is much better...and now that I look at it...could easily be pulled off in Antic mode 4 right from Basic (powerups, animated ooze, and all). Add string-defined players/missiles and you don't even need to use m/l routines.

[+Andrew Davie]

THinking a bit more about the behaviour of slime -- consider there's slime at the top, and slime at the bottom. Assume we were treating this slime somehow as 40 columns of slime, corresponding to 40 pixels of PF.

 

On the top, the lowermost slime in any column will move toward any column which is lower. Thus encouraging slime to 'drip'. On the bottom, slime in any column will move toward any column which is lower, thus encouraging slime to flatten out (ie: spread).

 

So I think the kernel will need to maintain 80 bytes - giving the top and bottom line # of slime for each column - and the kernel will need to figure out how to draw the PF given those descriptors.

 

Might be too tricky, but let's keep going with the basic idea

[kisrael]

Not really Andrew's concept is much better...and now that I look at it...could easily be pulled off in Antic mode 4 right from Basic (powerups' date=' animated ooze, and all). Add string-defined players/missiles and you don't even need to use m/l routines.[/quote']

Well, I didn't actually load it, but just from that screenshot, it's visually cooler than anything I remember making back in the day...I think my big idea was to do a simple scrolling, character-based trench:

_____/

__@__/

_____/

_____/

 

and the player had to swerve to avoid the sides.

 

Yours looks much cooler.

[+Andrew Davie]

Not really Andrew's concept is much better...and now that I look at it...could easily be pulled off in Antic mode 4 right from Basic (powerups' date=' animated ooze' date=' and all). Add string-defined players/missiles and you don't even need to use m/l routines.[/quote'']

Well, I didn't actually load it, but just from that screenshot, it's visually cooler than anything I remember making back in the day...I think my big idea was to do a simple scrolling, character-based trench:

_____/

__@__/

_____/

_____/

 

and the player had to swerve to avoid the sides.

 

Yours looks much cooler.

 

 

I think it looks pretty cool, too! It's a pity he didn't continue with and refine the concept. I think some modifications in the game design would have made for a fun, playable game.

[Gateway]

This reminds me of how, in U.S.games' "Eggomania", when you miss the eggs, then the yolk fills the entire floor that the blue bear moves across. It's harder to see where he is when trying to catch eggs until, you miss too many eggs and are submerged in yolk!

 

This is an option for how the slime appears after a certain amount has accumulated on the floor.

 

Overall, I think this game idea is interesting. More brainstorming...

[kisrael]

Might be too tricky' date=' but let's keep going with the basic idea [/quote']

One final wet blanket post, and then I'll shut up and/or join in w/ more ideas on how to get the Slime flowin'...

 

I do worry this is project going to be an exercise in frustration...

actually, http://www.atariage.com/forums/viewtopic.php?t=33473 seemed like a more plausible and atari-ish but still challenging to write game--

 

re: slime, with the goop that drops, the oozing out on th floor might look a little stitled assuming its limited to PF-block wide bloops.

 

Heh, reminds me of the idea for a digital hourglass I had.

(that might be an amusing little useful miniproject, a 30 or 60 second animated hourglass timer, you could use it for games like pictionary...)

[+Andrew Davie]

Might be too tricky' date=' but let's keep going with the basic idea [/quote']

One final wet blanket post, and then I'll shut up and/or join in w/ more ideas on how to get the Slime flowin'...

 

I do worry this is project going to be an exercise in frustration...

actually, http://www.atariage.com/forums/viewtopic.php?t=33473 seemed like a more plausible and atari-ish but still challenging to write game--

 

re: slime, with the goop that drops, the oozing out on th floor might look a little stitled assuming its limited to PF-block wide bloops.

 

Heh, reminds me of the idea for a digital hourglass I had.

(that might be an amusing little useful miniproject, a 30 or 60 second animated hourglass timer, you could use it for games like pictionary...)

 

 

The idea here is not so much to promise a do-able or completed game, but to work through the design process to see what sort of compromises and decisions we have to make, and the things we have to think about to bring a game idea to reality.

 

If it's not do-able, fine. But we're going to find out WHY, rather than just leave it at "hey, I have a great game idea, will somebody program it for me?"

[Nukey Shay]

I think it looks pretty cool' date=' too! It's a pity he didn't continue with and refine the concept. I think some modifications in the game design would have made for a fun, playable game.[/quote']

I dunno. I got bored with it about an hour after getting that much done, so I didn't have the fire to expand it much further. Basic is pretty handy that way...you can slap together an idea pretty quickly to see if it's a fun game or not.

[+Andrew Davie]

I think it looks pretty cool' date=' too! It's a pity he didn't continue with and refine the concept. I think some modifications in the game design would have made for a fun' date=' playable game.[/quote'']

I dunno. I got bored with it about an hour after getting that much done, so I didn't have the fire to expand it much further. Basic is pretty handy that way...you can slap together an idea pretty quickly to see if it's a fun game or not.

 

 

So how about building us a prototype of what we're discussing here? Shouldn't be too difficult, and you can help us refine the gameplay!

[Nukey Shay]

Nah...you are talking to the wrong guy. It's just not all that fun anymore. I'll stick to just playing the games But the Antic 4 method should work well if anyone wants to do it in Basic...multiple character sets to animate via a DLI/tile graphics ...and another one to display the "gun" ...and perhaps one for some spiff background tune ...and ...and ...

Aw...the game is just not all that fun to me

[mutil8]

Uhm actually thats a pretty good game idea - nice simple and clean.

Can you imagine how much $ you would make if you came out with a polished assembly language version of this in 1981?