It’s been a pretty good week. At this point, I’ve got maybe 90% of my total sound code finished. As I wrote about this previously I’d developed a bunch of the foundational classes and I was just about to integrate them into the main game: I ended up basically copying the architecture I developed for playing animations for my Sound playing behavior, which means that it’s now a system every bit as flexible and powerful as the animation system – and, as well, it gave me another opportunity to look over the animation system, and catch a couple of small problems I hadn’t noticed the first time.
After that… actually, I had a really hard time for a while after that. I spent a few days looking at my requirements for a music player system, what kinds of information it would need to have access to in order to do its job. I pondered how to organize it with the same kind of command architecture that the Animation and Sound behaviors used, and frankly I just didn’t get anywhere. In the meanwhile, spurred on by the vague ideas I did have, I developed a couple of utility behaviors, such as a tag system which allowed entities to be labeled. So, for instance, a demon enemy could be tagged with “moving entity”, “enemy”, and “demon”. Entities thus tagged can be quickly retrieved… well, they can be retrieved anyway, I’m not sure how quickly, though I do have some optimization ideas should it turn out to be an issue that they aren’t retrieving quickly enough.
But I digress. The point is that, after a few days of bashing my head on the problem of a music interface, I all but gave up on a single elegant solution and resigned myself to just writing a bunch of custom code for each section of the game. It might be ugly, but it would get the job done. I started working on a simplest-case solution, a basic behavior that would play one track when you walked into an area.
For that to work, I would need an object to handle the music track’s information, so that the music behavior didn’t, for instance, accidentally play multiple instances of the same track. While I was at it, I figured, I should make this music track class able to handle fading the music in and out, so I added a couple of variables to handle that. At that point it occurred to me that if I wanted to be able to sync music tracks up to one another, this was the most logical place to store the information that handled that… and, everything started falling into place, and before I knew it I had made – well, maybe not what I’d wanted all along, but the more reasonable grounded version of it. It wasn’t a one-size-fits all system for handling music playback, but it was a music interface powerful and flexible enough that it should handle most general cases and, when it comes time to inevitably write custom code to handle level-specific interactive music needs, should be easily up to the task.
Up next, it’s time to actually test out all of the classes I’ve been developing. Within a week, barring unexpected circumstances, I should have all of the non-level-specific sound and music code functional.
I’m feeling pretty good about that. Let’s see if I can ride that good feeling long enough to get this entity editor I’ve been avoiding launched off the ground.