Ethan

I haven't been brain-ing correctly today, but hopefully I can still get some stuff done.

I took another swipe at the dialog code. It's not really "finished" -- I didn't do dependencies -- but I also realized that maybe that's OK -- how long before dependencies changes things into spaghetti mayhem? We'll see what Chiz thinks. Chiz wanted a more complicated dialog system, I think, and I want to support that if possible, but I guess he's decided that a simpler linear dialog would be good for this kind of game. Maybe we'll expand on the dialog system in the campaign after this. Anyhow, that's why I didn't do much on the dialog system today.

I've been working on a song, which is tentatively called "The Jaws of Victory". It's supposed to be title music, and it still needs a bit of polishing. Maybe I'll send it to one or another of my friends and see if they have any advice; I don't feel right sending them the OGG or whatever without the source code, but maybe they'll have something good to say just on hearing it. (Me, I always need to play with it.)

Lastly, I told myself I would work on the site, possibly by integrating more of Carl's layout and content, but it isn't happening right now, so don't hold your breath..

Ethan

Ethan

Here is one approach that don't work: Testing the new position for collisions and rejecting the reel-in if there are any.

• What if you're reeling in a powerup or something? You want there to be a collision.

• If you're already up against a wall, it's possible that reeling should give you velocity in one direction even as it doesn't work in the other.

I think I have a pretty good solution right now, but that just means I don't know all the problems with it. The basic approach is to check on any collision whether it was caused by reeling in; if so, don't change the physics at all, but merely move the objects so that they don't overlap. Then, recalculate HiStop so that this is a valid position.

There are still some bugs -- under certain high-velocity collisions, things freak out, and I'm not sure why. Reeling in the "up-against" case doesn't look quite realistic enough. And it would be nice to have something like the stutter back, but I can always add that in later.

We met with Carl's advisor again today. He suggested Carl work on the artwork, and maybe that the "narrative" hooks grab a little firmer (with "narrative" meaning the progression of the game, in whatever way we define it -- plot, advancement, whatever. In other words, we need to be more compelling right off the bat. Well, maybe so, but I'd kind of like to get a move on this thing, and so I feel like I should be working on the healbeam campaign.

Ethan

Ethan

[Edit: with further testing, this doesn't actually seem to work. Either you end up extending the rope when it shouldn't be extended (i.e. when you aren't reeling in) or you still have the "dumping energy in" bug. I'm not quite sure how to fix this..]

So, the pull beam is a fun mechanic, but the physics of it are a little problematic. Even using ODE, which does a lot of the physics for us, there are a couple of tight spots. Namely, reeling in and reeling out can be a pain.

Our pull beam is implemented internally using a set of ODE joints connected to some intermediate bodies. This is all encapsulated in the ODERope class in src/data/Rope.py. The joints are:

j0: a hinge joint that connects the rope to the target body (the body the hook connected with) j1: a slider joint that represents the rope itself j2: a hinge joint that connects the rope to the parent body (the body that fired the hook)

Theoretically, you might get better modelling if you used a long series of joints and bodies, but I prototyped it separately about a year ago and didn't like the way it looked or felt, so I did it this way. This works pretty well for a default rope -- if the bodies move closer together, no problem, the slider joint just slides in. The slider joint needs to get a HiStop parameter to know when to stop extending; we used 10 (0 is the initial position of the slider), so you can move out by about ten pixels from where you first shot the beam before being restrained.

Reeling in the rope conceptually means moving the HiStop parameter so that it constrains "stronger". There are a few issues to be concerned with:

1) If the player is at the end of his rope, so to speak, what happens when the rope is reeled in?

If you move down the HiStop so that the player is beyond it, ODE will "snap" the player back in. This might give the player too much velocity, however. What we do is check if the histop is less than the player's position on the rope; if so, move the player in by however much is being reeled in.

Similarly, if the player is at the end of the rope, and the rope is reeled out, then we push the player out. There's no centripetal force acting to hold the player in orbit on the rope, so this simulates the player being flung out to the rope.

If you've gotten this far, you'll have a pretty good quick-and-dirty rope approximation. But there's still some bugs:

2) If the player is at the beginning of his rope, and reeling in will overlap the player with an object, then what?

If you've lowered the HiStop by too much (and moved the player correspondingly into the object it overlaps), collision detection goes crazy. However, you can detect that this happens by the fact that the slider joint is overextended -- player's position is beyond the HiStop. So, the first step to fix this is to institute a check every frame; if the player is outside the HiStop, readjust the HiStop up. However, by this point, the collision has already dumped too much energy into the system; this might not be so bad, but if the player is stuck to a non-static object, both have just gained a bunch of velocity. Not good.

So the next step is to do this check every "step" (Project Alexandria does 10 physics steps per frame), and if the rope is overextended, stop reeling in immediately (before the next frame). The only problem now is that there are other cases when the player's position is a little above HiStop, namely when they're reeling in but trying to apply force in the opposite direction. So we implemented a tradeoff; check if the rope is overextended two steps in a row before stopping the reeling in. This gives a very cool "stutter" reel in if the player is reeling in while accelerating in the other direction.

Here's a video of that stutter. There's still room for improvement; the end of the video shows me trying to get the reel out to work, and not succeeding. And the reeling in just stops when the player happens to be going too fast in some unfriendly direction. So, back to work, I guess.

Ethan

Ethan

More sound effects today. I made three, but they suck a lot. It's OK, the music will drown them out. Well, but the music sucks too. But that's OK, the sound effects will drown it out..

I think there's some kind of precarious balance I have to reach; just a square wave sounds too primitive, but ordinary whitenoise sounds too "modern". I have to be careful to have sound effects that sound just primitive enough.

Gonna try to write another song tomorrow (the title screen song) and also work on the site so that it doesn't look like ass when we actually go live, whenever that is.

Ethan

Ethan

All of a sudden I've been accomplishing things like crazy.

1) Added some nice chrome to training1, training2 and training5.

2) Helped do some research into the effects of alpha/colorkey and RLEACCEL on blit speeds: http://thread.gmane.org/gmane.comp.python.pygame/11361.

3) Fixed a bug I introduced into the menu stuff.

4) training4 was too easy, I tightened it a little bit. It might be too hard now, I'm not sure?

To borrow a phrase from jwz: "Mozilla is actually starting to smell like a product; maybe we're not doomed after all." I sure hope so.

Ethan

Ethan

I've been caught up trying to refine the "hiss" sound. Interesting discoveries: tremolo to white noise can make fascinating noises. Tremolo at 100 Hz makes a buzz; tremolo at 10 Hz sounds like a helicopter. Very cool.

Damn, there's a vibrato effect in here, and has been here the whole time! It's "TAP Vibrato". I wish these plugins were alphabetized by function instead of by name. Still, cool.

And what the heck is the Slide plugin (LADSPA 2741 in the Omins package) do? I ran it on a square wave, but all I got were some crackles. But if you change-speed that by 100%, it makes some much cooler crackles. But they don't play well with other sounds -- all those negative numbers. But if you invert it.. wow, that sounds pretty crunchy! But, hmm, you can't envelope it? Woah, all the numbers are above 1! I'm so confused.

Ethan

Ethan

Getting a good, solid "crunch" sound is very tricky. I thought I could just make a crackly kind of sound, but even that is really hard. I tried to use (Nyquist code):

(defun crackles (dur)
 (let* ((samples (truncate (* dur *sound-srate*)))
        (a (snd-samples (force-srate *sound-srate* (const 0 dur)) samples)))

   (dotimes (i (/ samples 128))
    (setf (aref a (my-random 0 samples)) (my-rrandom 0.0 1.0)))
   (snd-from-array 0 *sound-srate* a)))

But, lo and behold, it just sounds like a crappy white noise.

Now I guess I'm back to square one. I have my decimated white noise -- maybe I can get something good going on with the "echo" function in Audacity. But quickly, because I have jury duty in the morning..

Ethan

[Edit: this sounds promising. Track one: Chirp, Sawtooth wave from 40 Hz to 20 Hz (both at amplitude 0.8). Track two: the same, except run Random Wave Generator FCSA on it (frequency 440 Hz). Hmm..]

Ethan

For some reason I've been fixating on sound effects for Project Alexandria. I've been working on a sound for the aliens to use when they get hit. I just wanted to drop some notes that I've found useful:

• If you're aiming for an NES sound, the decimator is your friend.

• You can also use the "Random Wave Generator" LADSPA plugin. In Audacity, you can use the FCSA variant on some random audio track, and specify a low-ish frequency to get a lo-fi white noise. I think this is how I made the "big explosion" which you hear at the end of training5.

I'm currently working on doing some kind of frequency modulation from within audacity, so I can make a sound that starts at a high pitch and drops a little. Will this sound good, or at least better? I have no idea. Audio stuff is hard!

Ethan

[Edit: It's called "chirp", it's in "generate". Sigh..]

Ethan

We're tweaking the acceleration code like crazy to try and get a good feel. The problems are as follows:

1) Sometimes you want to pour on the speed, especially when trying to dodge or when you're at a standstill.

2) Sometimes you want to make lots of little changes to your speed to get precise aiming.

How to tell the difference programmatically? Or how to provide a suitable mechanism for determining which to use?

In the "automagic" camp, there's an "acceleration model" known as "ethan1", which guesses based on your velocity and which way you're facing which of the two cases you're in. If you're thrusting in a direction you're mostly already travelling in, it looks at your speed -- too much speed throws you out of control. If you're moving opposite, then it looks at your speed, but the opposite way -- you're trying to slow down, so the faster you are going in the wrong direction, the more accel you want. These aspects feel pretty good, except when you're trying to reverse direction, which takes a little bit longer.

But then there are two cases when you're flying sort of perpendicular to where you're thrusting, and these aren't clear. Maybe you want to make a big course correction, but maybe you're tweaking your velocity or trying to come to a stop. Hmm, maybe I should look at velocity again.

Ethan