Following the near complete rewrite and restructuring of the technical side of the game, which was finished in October '09, I was able to finish the remainder of the mission mode level designs, boss designs, and polishing of them.
Progress and polishing continued for the game until December '10 when I realized that the licensing fee for the sound system I was using had gone up significantly. When I started working on BlastZone 2, the price for an indie developer releasing a game using FMOD for sound was $100, but it now went up to over $3,000! This was far above what I was willing to invest financially into the game, so I decided to rewrite the entire sound system using OpenAL, which has no licensing fees, but is much more difficult to implement. In about two weeks I was able to accomplish this and had one less thing to worry about. It was satisfying to know what I was able to duplicate the functionality of a $3,000 software package myself in just a few weeks. My big advantage was that I only had to duplicate the few areas that my game used. FMOD had a lot of sound features BlastZone 2 didn't utilize, so my trimmed down custom sound system was indistinguishable from the former one in practice.
|BlastZone 2 polishing up|
** Some technical info for the curious **
For those who don't know, socket communication is a very advanced form of sending data between computers. It provides fine control of every individual bit and byte that is sent. This is especially difficult for real-time action games like BlastZone 2. I knew easier communication methods wouldn't be sufficient because they would put a higher strain on the internet connection and cause a lot of pausing and unresponsive controls. At a higher level perspective, the host computer needs to keep track of all the data that's been sent to the client so far and determine what has changed locally since the last transmit. From there, all the relevant delta information needs to be collected and sent at a rapid rate. You can think of it similar to the difference between an MPEG video vs an uncompressed video. An uncompressed video has data for the entire screen for every frame while the MPEG video only contains changes to be applied to the previous frame to make the new frame look as it should. It's one thing to do this to a static video, but its another to apply this method to dynamic data that needs to adapt on the fly and be seamless for both players in the game.
Drilling down to the lower level, every piece of data to be sent needs to be converted into the smallest byte equivalent possible so as not to blow the bandwidth budget of the users' internet connection. Once the byte string is constructed on one computer, it is run through a bit-level compression algorithm to make sure the least data possible is sent to the target computer while maintaining all the information needed.
I knew multithreading would be necessary for getting online multiplayer to work well. The way socket communication works, if the internet connection slows down, it will block the code, causing hitches and pauses that can really hurt the fun of playing the game. Multithreading is another advanced programming method that involves having code running in multiple areas simultaneously, each called a "thread". The two main advantages of multithreading is that it allows processing in other areas to continue while one area of code is paused or waiting for a response and it allows computers with multi-core CPU's to run your application faster, improving performance and efficiency. This may sound straight forward at first, but there are many ramifications to this. First off, each thread cannot access the same data currently being used by another thread. Also, each thread may operate at different speeds, so you can't assume data will be prepared in one thread and immediately usable in another. Another pitfall I encountered is that if one thread determines that a piece of data isn't needed anymore and deletes it before the other threads know it isn't needed, the other threads can try accessing it and fail, causing the game to crash. Lots of countermeasures need to be placed in the code for these and other potential issues for multithreading to work correctly.
** End tech info **
I stayed away from these two areas of programming for a while since they are so daunting. They are very advanced and it was possible I could spend months attempting them and have nothing to show for it. I decided to take the risk and go for it anyway, and it payed off.
It took about 2 months to complete it, far exceeding my expectations, and it was very exciting to see it working. I was able to implement a multithreaded online multiplayer component to the game and even added multithreading to the sound component with my new found skills. This delayed the game release, but I felt it was more than worth it and what my future customers really wanted. I also found that most shooters out there dont have an online component, and most of the ones that do are really laggy. After a lot of testing, tuning, and optimization, I was able to make online multiplayer for BlastZone 2 very fast and responsive, giving my game a great advantage.
|BlastZone 2 shortly before the v1.0 release|