Jay McGavren's Journal

Infinite Suburbia...

So I drove around to the southern loop of the 202, the Santan Freeway, last night… It didn’t exist a couple years ago, and it’s still not connected all the way yet, but should be later this year.

I am simultaneously awestruck and horrified by how far this metro area reaches. And though it isn’t all filled in yet, it’s obvious our urban sprawl will reach the entire area the 202 encompasses, and beyond. It’s inevitable; the freeway aids and abets growth.

And you and I already knew this, but it was confirmed by what I saw last night: these are not going to be vibrant, artistic, intellectual communities. They’re going to be the same blocks of identical tract homes, interspersed with the same Super-Target-KFC-Petsmart mini malls that fill the rest of the valley. Forget about walking - it’s two miles to the corner store. Your kids will have to take up graffiti or drugs if they want accessible entertainment. And most of the people living there will have to commute all. the. way. back. to Phoenix or Scottsdale for work.

This smoggy, torrid hell is your new home. Good thing it has broadband…

Ahhhh!

Work e-mail inbox is empty. Hurray! (This should be a daily occurrence, but it happens so rarely I feel compelled to celebrate.)

Community brains...

I read an interview of a Halo 2 developer eons ago, without which I probably wouldn’t have gotten nearly as far as I have on Zyps. It was chock full of good ideas on networking.

And now I’m using the AI bits as well… He mentioned that the enemies had to “take turns thinking” due to the XBox’s limited processing power. Basically, an AI was given a few processor cycles to size up its situation and choose its action, which it would then dumbly perform until its next turn to “think”.

Zyps is getting really slow when there are dozens of creatures with 5-7 behaviors each on the screen. It’s time to assess splitting up my processor time as well.

Right now the plan is to add Behavior#condition_frequency, which will take an integer. If you set behavior.condition_frequency = 3, then every third update, it will get a chance to select a new group of targets to act on dumbly for the next 3 updates.

The problem with this is that if they’re created simultaneously, every behavior where condition_frequency = 3 will be called on the same update, meaning the first two updates will be ultra-smooth, and the third slow as hell.

I think I have a way to spread things out evenly: assign an incrementing offset to each Behavior that will decide which update number it receives from those allocated to its update frequency.

Here’s a prototype, with a Counter that shares its “brains” with all other Counters in existence:

OMG OMG OMG it’s SO much FASTER!!! This is freaking awesome!

Oh, and I was able to keep the Behavior API backwards-compatible. I’m pretty proud of that.

I still have to run CollisionConditions every update to ensure things don’t pass through each other, though, which sucks because it’s the slowest Condition I have. The GUI may develop telekinetic breeding and eating if I have to change those to ProximityConditions.

Enso 2.0 - Arggg nonononono!!!

Just saw Aza Raskin’s post to the Humanized Weblog regarding “Enso 2.0”…

…and I hope I’m wrong, but I’m filled with a sense of impending doom. The champions of amodality are turning to the Dark Side.

Enso shouldn't make you type all of "open" every time

Yes it should. If a command is important enough to use repeatedly, the user will get very fast at typing it. If it’s so important, make the command short (and “open” is short enough).

Enso should gracefully handle the case where there's no convenient place to enter text

Give us enough commands that we never have to leave our editor, then. (Remember The Humane Environment? The Canon Cat?) Don’t introduce unneeded complexity into the Enso interface itself.