Finding solutions to problems…

I have been enjoying my journey through the XNA very much. It all started with a little project to move a sprite around, and now I can control a number of sprites, spawning different behaviors, animations and sounds. It wouldn’t be fair to say that I have done all this entirely on my own. The XNA has a great number of resources that I have tried to take as much advantage of as possible. It is not a bad thing to admit that have copied at lot of source code from the resources when it fits my needs. However, more importantly, I have tried to write my own code as much as possible. I have only copied it when it fits my exact needs, and when I think I can learn more from copying it, than from writing my own.

That was the case of this latest step in the process. Sound was something that I was not entirely sure how to bring into the world. I knew the basics such as initializing the engine, the soundbank and the wav. I had some trouble getting the Cues to play, but that had to do with not knowing much about XACT (the sound rendering engine in the XNA). FYI, if anyone ever has trouble getting their cues to play, just make sure you actually added the cue from the soundbank to the cue list at the bottom. One of the issues with sound (and this is an issue with a number of things when making games), is that a lot of elements in the game need access to the sound engine and sound cues. There are several way to solve this issue; for instance, you can inialize the engine in the “world” class, and pass a reference to every sub class. This is not very portable, and certainly makes for a mess of very ugly code. Another option is to allocate a sound engine and intialize it in every sub class. This is portable… but holy cow would it be expensive and unnecessary use of resources. It also makes for ugly code.

Then I found the Marble Game way. It’s one of those moments when you find out that the simplest answer is the correct and takes you some time to realize that you have been doing it all wrong. The easiest and most effective way to do this is to create a static class and initialize it in the “world”. The great advantage of this is that it makes it portable, accessible, economic, and very elegant code. The static class can be called from any other sub class and the initialization can take place with a single call. It was brilliant. The execution on the example of the Marblet Game was also very elegant. When things meet all this needs, it would be silly to attempt and create my own, so I learned what to do next time, and moved on!

The next step will be setting a player based AI with mouse selection and way points. Looks like a very hard task but it should be fun.

I also need to implement a HUD. I honestly think this should be one of the last things to even think about. Having said that, I also believe that it’s one of the things that can really bring a game to life.

No screenie today. Source code might be up later this week, after I clean up and make it pretty.

Comments are closed.