Ethan

Another prerelease: r1-rc3. Who knows when we'll actually release. If you've played r1-rc2 then the main difference is some bug fixes in fading in and out, and using the space bar to get past the title screen.

alexandria-r1-rc3.tar.gz -- source tarball

alexandria-r1-rc3-win32.zip -- py2exe'd Windows executable

Play it in good health!

Ethan

Ethan

The nature of polish is that it starts with fixing lots of little things that had before been overlooked. Spring cleaning. Refinement. Whee.

I knew the AI stuff needed a huge makeover, but I never realized just how bad it was! Apparently even the simple Shoots AI was wrong. It's still a little ugly but at least it behaves correctly in the case where the AI did not start on the first frame of the game. (Surprisingly common -- it even happens in training2.) There are two approaches I could take to implement an AI that shoots every n frames -- either calculate the frame it will have to shoot next at, or keep track of how much time it has left to pass, and every time the AI runs, it deducts how much time has passed. The first approach maintains its rate of fire even if the AI is turned off and then restored a frame later. The second one instead "picks up where it left off", and fires a frame later as a result. I'm not sure which is better or more right, so I went with the implementation that was in the class in the first place (which was a modified form of the first -- store the frame when it fired last and expect to fire again when the game's frame counter is greater than that frame + the AI's period). Time will tell, I guess.

I still haven't posted a notice on the Pygame site about our new release yesterday. I'm a little bit afraid, but I don't know why. I'll do it tomorrow, probably.

Ethan

Ethan

Hey guys, we've put up a prerelease of the initial first campaign which we intend to release when we eventually launch one day (possibly as soon as next week? Yeah, right). If you want to see what we've been up to lately, please feel free to grab:

alexandria-r1-rc2.tar.gz -- source tarball

alexandria-r1-rc2-win32.zip -- py2exe'd Windows executable

Note that I've completely failed to test either of these, so they may be even worse than they usually are. Feel free to let me know about any problems!

Ethan

Ethan

I asked my friend Chris Granger for advice. He minored in music, maybe he can tell me what to do to transition smoothly between Am and C. It shouldn't be hard, right? They're all the same keys, just in a different order.

I think Carl feels like more spaciness would be a good thing to have in this song that I'm working on. I might throw an echo or reverb or something on the sucker when it's done. Or, maybe make a good percussion track. Either way, later for that..

Also, made a new sound effect, it's pretty grand. Sound effects are so much easier than music -- not that they are easy, because they aren't, but they go so much faster sometimes.

Ethan

Ethan

I've spent most of the day working on this song. The good news is that I have the first 8 bars done. The horrible news is that I have no idea what to do next. It sounds like a change is needed, like a chorus is starting, or a bridge, or something. But I'm having a really rough time looking for something that fits with the feel of the first eight bars, that also sounds different. And it's pretty frustrating trying and failing over and over. This is the first day I'm actually working on it, but I came up with the melody last time I was working on music (a week or two ago?). I think (if I had the money) it would be more cost-effective to just hire a musician.

I was hoping to go live this weekend but that seems increasingly unlikely, since there are two to three pieces of music I'd like to have in place that I simply don't. And sound effects would be good also, of course. But tomorrow I should at least make a new build of -rel1 and probably post it to the pygame site, maybe get some feedback.

Ethan

Ethan

Made a few changes today. Looks like the major slowdown in the 50 or 60 mines was the AI which slows them down. Per-frame forces are dealt with in Game.add_force() and then in Geometry.collide_all(). It's done in Python -- there's a dictionary mapping objects to forces, and the force is applied each collision cycle (10 per frame, currently). I changed the forces of the Damps AI to impulses instead (happen for only one collision frame, but are scaled up to match the timeframe). This should lead to faster but less-accurate mine behavior. This just barely gets me under the wire for 30 FPS, but I'm sure when Carl adds some art, it'll lag again. I'm not really sure what else to do except benchmark a little more and hope I find something clever I can do.

Ethan

Ethan

Actually, I might have to do some optimization. I'm still getting lag and that's really not so good. Anyhow, have a screen shot..

Just look at that radar..

Ethan

Ethan

Carl's new idea for healbeam6 is much better than the old one. But the implementation has some issues -- lots and lots of objects. Slowdowns. What fun.

I think I can work around this if need be -- create a new collision class for mines, and don't collide within that category -- but it would be a hack and I'm leaving it for the time being. For now, I'm getting things working. The new level is about half working, I'd say -- most of the stuff is in place, but not all of the events and crap. Plus, I'll need better AI on the enemies. Still, much better than what I had.

Ethan

Ethan

Humorous to realize that the three or four optimizations I've implemented today and last night basically serve only to restore speed that I had before I started adding features. Similarly, most of the speed gains they achieve are mostly due to slowness that I put in with new features. Oh well, ever onward.

Ethan

Ethan

Some simple touches really go a long way. For instance: bad sound effects are much much better than no sound effects. The same way, you can add a lot of character to a game by having title screens fade in and out. So I took a few minutes today and added some fades to various parts of the game. Not all of them -- the main game is going to be tough, and I think there are a few that still need fade-outs when a key interrupts them (OpenView, MetaView). Still, it helps.

Also, I may have fixed Carl's weird slowness bug. He hasn't said that it worked but he hasn't said that it didn't work either, and I'm taking that to be positive. I fixed a weird bug in level5 where a dialog wasn't getting placed in the right place -- this was caused by the fact that meanwhile events recently became meanwhile patterns, and patterns don't play when physics is shut off (by "cinematic" command). Pretty weird combination but I think the patterns-don't-play behavior is wrong, so I changed it. Level5 is really the only level that uses the "cinematic" command so far, so I know it didn't break anything. I often wonder if weird bugs like this would crop up less if I had a better design, but I don't know how to test it without rewriting everything..

Lastly, I started work on the station's "two-thickness walls" nonsense. It's gonna take some work, but I just spent twenty or thirty minutes discovering one approach that didn't work.

I'm sorry I've been so quiet lately! Some days, you lose track of progress reports because there's so much else to do.