Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
  • entries
    945
  • comments
    4,956
  • views
    1,221,131

Spit into the Wind!

Nathan Strum

Entry posted by Nathan Strum

3,048 views

 Share

After reading Mezrabad's review of Human Cannonball, and the subsequent comments about the classic game Artillery, I remembered a graphical hack I did of Kirk Crawford's version of Artillery for the Mac.

 

I created this back around 1990. Re-titled "Spit into the wind", it featured two caricatures of my college profs hocking loogies at each other. So I thought, "Hey! This is another (fanfare please)... Stupid Game Idea!" It would be a natural for the 2600. While there's already an Artillery-type game in perpetual homebrew development, as well as Xonox's Artillery Duel, I'm unaware of any 2600 game in which you spit at each other!

 

As a little background, the two profs were design teachers at an art college I went to. I won't reveal their real names, but we called them Ramblin' Ray, and Butt-Ug Lee. Here are a couple of caricatures I drew of them back-in-the-day.

 

Ray:

ramblin.gif

 

Butt-Ug:

buttug.gif

(In case you're wondering, he tended to flail his arm around a lot and grab his butt.)

 

The irony isn't lost on me, that as I'm teaching college now, probably every last one of my students is similarly caricaturing me. (One of the hazards of working in the Character Animation department.) Well, what goes around comes around. ;)

 

Anyway, after a little digging, I actually found "Spit into the Wind". (Some days it's good to be a pack-rat.)

 

It doesn't completely work though, now. When I click to change the angle and amount of Cheetos™ (formerly gunpowder), the numbers just jump from minimum to maximum. (The newer version on Kirk's site does work properly under OS X's Classic, however. It just doesn't have the modified graphics.)

 

I'd completely forgotten that I'd also hacked the bird into a little flying version of Ray. :D

 

sitw.gif

 

Here's the application icon, of Ray getting hit in the face:

 

sitw-icon.gif

 

To do those graphics on the 2600 though, I'd have to use both sprites for each character to get reasonable detail. Although as long as they were kept vertically separated, it should work okay.

 

ray2600.gif

 

buttug2600.gif

 

The basic premise is simple. You have these two guys, facing each other, with some terrain in between them. There's a wind blowing (of course), and you have to determine how many Cheetos™ they need, and at what angle they need to spit, in order to hit the other guy. Once the parameters are set, you hit "Fire" and they both shoot at the same time. If they both miss, you adjust, and fire again.

 

One nice feature of Artillery (which probably can't be duplicated on the 2600) was that the trajectory for each shot was shown as an arc on screen, and was left in place so you could see how much each shot got changed. Still, I think it'd be a pretty fun game even without that.

 

And it'd be a blast to do the manual for it. ;)

 

 

Edit: Well, I decided to see what a mockup of this might look like. Now first, I'm not sure an asymmetrical playfield can be done the way I'd like it to. But the big problem I ran into was, well... big. The sprites were way too big. You couldn't not hit them...

 

sitw_mockup_1.gif

 

So that meant I had to at least try to make the sprites smaller. Much smaller. I wasn't sure I could come up with 8-pixel-wide versions of these guys, but I think they turned out pretty well...

 

sitw_mockup_2.gif

 

This also has the handy side-effect of not needing to keep the sprites vertically separated anymore. :)

 

With that solved, I continued mocking up the rest of the elements...

 

It'd be nice for each player to be able to enter a three-letter name for themselves. Their scores would be at the top.

 

sitw_mockup_3.gif

 

At the bottom is the amount of Cheetos™ per shot, the angle they spit at, and the wind speed and direction.

 

The diagonal lines represent the angle at which they'll shoot. Basically, an "aimer". Once they shoot, the aimer disappears, and their shots follow a parabolic arc.

 

Ideally, the terrain would be randomly generated each round, but provide platforms wide enough for each sprite to stand on (or alternately, just store a bunch of pre-designed ones). One thing I don't care for in either Artillery Duel or Incoming!, is that the sprites can just kind of hang out over the playfield.

 

Joystick controls couldn't be simpler: up/down for Cheetos™, left/right for angle, and fire locks it in. When both players have pressed fire, the spitting begins! In a one-player game, the computer controls the other character (but you get to choose).

 

Now all we need is a big bag of Cheetos™! And a programmer. :D

 

(Could make a nice mini-game compo entry. ;) )

 Share

22 Comments

Recommended Comments

cd-w

I think the main difficulty would be the parabolic arc for the spit, which may require a large lookup table. Can you post the equation that you used to calculate the trajectory of the spit (based on the wind speed and number of cheetos)?

 

Chris

Link to comment
Thomas Jentzsch

I think the main difficulty would be the parabolic arc for the spit, which may require a large lookup table.

Not at all. You just would have to add some constants (gravity and wind) to the vertical and horziontal speeds each frame and automatically get a pretty correct parabolic arc.

Link to comment
Nathan Strum

Seems pretty doable. It is round based, right?

Yep. You both shoot, and if you both miss, you try again in the same environment. If one (or both) get hit, a point gets added to the score(s) and then you move on to another environment. First one to a certain number of hits, wins.

 

I think the main difficulty would be the parabolic arc for the spit, which may require a large lookup table. Can you post the equation that you used to calculate the trajectory of the spit (based on the wind speed and number of cheetos)?

I didn't program the original. I just hacked the sprites. :)

 

I think the source code used to be available for the game. I can check with the original author if anyone is interested.

Link to comment
batari

I think the main difficulty would be the parabolic arc for the spit, which may require a large lookup table.

Not at all. You just would have to add some constants (gravity and wind) to the vertical and horziontal speeds each frame and automatically get a pretty correct parabolic arc.

Yes, but coming up with those initial velocities would require trigonometry, thus the lookup table.

Link to comment
batari

Yes, but coming up with those initial velocities would require trigonometry, thus the lookup table.

Yup. 45 bytes.

Yes, if you use a one byte fraction and don't mind a little futzing with the angles to represent sin and cos and all angles 0-90.

 

But I wonder if a one byte fraction would give enough precision to reasonably represent all angles and all possible magnitudes?

Link to comment
Thomas Jentzsch

But I wonder if a one byte fraction would give enough precision to reasonably represent all angles and all possible magnitudes?

Angles yes, but for the magnitudes you will have to do some math (fixed point multiplications).

Link to comment
Thomas Jentzsch

BTW: Since this is about spitting, air resistance becomes pretty important. I am not sure if a simple linear approach (like the one I usually use in my gravity/friction games) would look convincing and calculating squares won't be easy.

Link to comment
Nathan Strum

Also important, would be making sure that in the strongest wind the game could have, and given any relative position of the two players, that they could both manage to hit each other, given the right angle and amount of Cheetos™. In other words - no impossible to solve scenarios.

 

Part of the fun of the game would be firing into the wind, and watching your shot curve back to hit the other player from behind. :) So the game would (most likely) have to track trajectories that would go off screen and come back.

Link to comment
batari

But I wonder if a one byte fraction would give enough precision to reasonably represent all angles and all possible magnitudes?

Angles yes, but for the magnitudes you will have to do some math (fixed point multiplications).

Thinking further, I think we do need 90 values unless we want to do some complicated math.

 

Suppose we have a table of sin values 0-45. We want sin(23), no problem. We want cos(56), that's easy, as sin(a)=cos(90-a).

 

But suppose we want cos(23). Well, cos(23)=sqrt(1-sin^2(23)), but that's not exactly easy to calculate.

 

If we have all 90 values, we could use either cos or sin and be fine. But this brings up another problem - cos(0)-cos(5) are so close to 1 that they'd all be $FF if we used 8 bits for our fraction.

 

EDIT: I was missing something. The position variables would still probably need to be 8.8, so any additional precision we put in our table would be lost anyway. And although all values 85-95 degrees would have the same horizontal component, they would have different vertical components, so this would probably help.

Link to comment
supercat
But suppose we want cos(23). Well, cos(23)=sqrt(1-sin^2(23)), but that's not exactly easy to calculate.

 

If your table entries themselves have sufficient precision (e.g. 8.8 ) you could cut the number of entries in half by storing the values for even-numbered degrees and then, for any odd-numbered angle, averaging the even-numbered angles on either side.

Link to comment
Thomas Jentzsch

Thinking further, I think we do need 90 values unless we want to do some complicated math.

Yes, I think you are right. Calculationg a square root is probably too much. John's suggestion may help here.

 

Calculating square on the fly(!) will be also extremely hard, probably we have to cheat there too.

Link to comment
batari

Thinking further, I think we do need 90 values unless we want to do some complicated math.

Yes, I think you are right. Calculationg a square root is probably too much. John's suggestion may help here.

Yes, interpolation should work. I wrote some interpolation code just to see, and it took 15 bytes.

Calculating square on the fly(!) will be also extremely hard, probably we have to cheat there too.

If we're going to cheat here, maybe it would be adequate to take each component velocity and just pull a corresponding drag force out of a table? The table obviously couldn't represent every possible velocity, as if we allowed up to a 4.8 fixed point we'd need a 4k table. But maybe 256, 128 or even 64 bytes would be close enough?

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...