Monday, December 26, 2011

v1.0 release and post release updates

On July 17, 2011, BlastZone 2 v1.0 was officially released.  The initial reaction was good and I was excited to finally get the game out there, but I immediately jumped into post release patches.  These initially focused on small gameplay tweaks and bug fixes while I sent out letters to various indie game review sites.  It was exciting to see a few game news sites pick up on the release and publish announcements for others to see.

It was exciting to see the first major review posted for BlastZone 2 on  While there was a lot of praise for the game on there, with one of the reviewers awarding an 8/10 score, other reviewers gave lower scores, citing the repetitive background graphics.  I noticed that the negatives in the reviews didn't mention gameplay elements much, so I decided to revamp much of the graphics.  My hope for this was so players wouldn't have a bad first impression from the background graphics and not give the gameplay enough of a chance from that.  I thought the initial graphics looked good, having a lot of detail, but the same pattern would repeat several times across the screen.  I knew the solution to this would be to have much more expansive and varied environments that wouldn't repeat across the screen at all.

At the time I was following the new id Tech 5 technology by John Carmack, and I wanted to take a step in that direction with BlastZone 2.  I wasn't going to attempt megatexture, but I wanted to push larger texture sizes with S3TC compression and eliminate texture tiling in the game.  I did some research and found a powerful terrain editor to accomplish what I set out to do.  I used it to build 16 times as much unique texture data draped across the terrain and over 9 times as much unique geometry data for 3 of the 4 backgrounds.  At the same time, I managed to figure out a few good terrain optimizations to offset much of the performance penalty for the increased detail, which worked out great so I didn't have to increase the minimum requirements to run the game.

BlastZone 2 v1.09b with new terrain and shader water

After I accomplished the background upgrades, I moved to adding Fragment and Vertex shader support to the game engine.  Using these allow me to add much more detail to the game by doing all the lighting vector calculations for every pixel on the screen. This allows models to have much more definition, bumpiness, shadowing, and realistic reflections with only a very small reduction of performance. This wasn't implemented for the v1.0 release because this is a much more sophisticated form of graphics programming than whats used in most of the game.  It took a while to learn how to leverage these features, but it was very gratifying to see them working in the end.  I developed shaders to add normal mapping and specular mapping to all the player ships and enemy ships and bosses in the game and I developed a water shader for the home planet environment as well.  They it was incredible how much detail I was able to add through these methods.  Look below for a good before and after shot.

Original model on top, new model with shaders on bottom

Once all these updates were released for the game, a reviewer from the indie game review site contacted me about BlastZone 2.  I gladly provided a review copy and the article posted was very positive!  The reviewer pointed out the graphics and varied gameplay as big positives for the game and awarded a 84% score!  I was happy to read this review and glad the graphics updates turned a negative point from previous reviews into a positive point for the new review.  My hard work had payed off!

See the review HERE!

Sunday, December 18, 2011

Progress to completion and the final stretch

Welcome to the fourth entry for BlastZone 2!  This entry will cover the progress leading up to the final PC release of BlastZone 2 and a bunch of technical "behind the scenes" info along the way for those who are curious.  Enjoy!

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
Additional polish progressed on the game and was shaping up for a March '11 release, but in February '11 I did some focus testing and found that there was significant demand for an online multiplayer component.  Very early on I had built a local co-op multiplayer component and always considered online multiplayer to be out of scope, delving into an area of programming I had little experience with and is very difficult.  However, talking to a few people made me decide to give online multiplayer a try.  I started planning it out and for the first time it really started looking feasible.  I decided to go for it, combining together a few skills I had very little experience with; socket communication, and multithreading.

** 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
Development of BlastZone 2 was quickly approaching retail release and excitement was building up!

Monday, December 12, 2011

Continued development, level design, and a huge turning point for the game

Hello, and welcome to the third blog entry for BlastZone 2!  In my previous blog entry, I described my experiences developing the game up to December '06 when I won my first game development contest at my college.  Steady progress continued for the game until September '07.  At that time, I considered the technical features of the game 95% complete, but I only had the first two levels of mission mode complete.  I thought it was a good breaking point for the game so I released the first official public demo of the game including the two mission mode levels built so far and the classic survival mode that mimicked the gameplay of BlastZone 1.  People who played that demo release provided a lot of useful feedback.  Above all else, the response I got was that the game was way too hard.  Since I had been working on the game for about a year and a half at that point, I had too much practice to be a good gauge of difficulty.  I could beat those first two levels without dying, but I knew that if new players died too quickly, they wouldn't have enough fun to drive them to play through the rest of the game.  I had to figure out ways to reduce the difficulty while keeping up the same level of intensity I wanted.  It's easy to just reduce the amount of enemies and bullets in the levels, but that would make the game boring, and I didn't want that.

From the BlastZone 2 v0.95 demo released Sept '07

I needed to take a break from the game for a few months while I finished my Computer Science degree.  I figured it was a good time to take in all the feedback and decide what direction I wanted to take the game from there while I devoted most of my time to other things in my life.  Around that same time, the demo release of my game got quite a bit of attention, including a freelance sound designer who wanted to help with the game.  I graciously accepted his offer and he supplied a wealth of great new sound effects for the game.

By December '07 I was done with school and could finally devote much more time to my game.  At that point I decided to take a long break from the technical side of the game and solely focus on level design for the rest of mission mode.  I had a goal of choreographing a half hour long experience for it.  I knew it would take a long time for such a task, but I knew it would be worth it in the end and really make my game stand out from other shooters out there.  Most shooters I played only had a handful of standard enemy types and each level would throw handfuls of them at the player, only varying where and when they would appear.  This I thought would detract from other shooter games that were otherwise very well designed.  My goal was to hand animate every individual enemy in the game to make the experience completely unique from beginning to end.  While I made sure the game had cool weapons and abilities for the player to use, I made the conscious decision to focus the vast majority of my gameplay design on level design.  I knew there would be players out there who would look for the kind of level design many other shooters have, so I addressed that with the "Enhanced Survival" mode, which used a dozen or so base enemy types and generated levels on the fly, but with the extra speed and intensity I wanted to maintain in the game to keep its identity.

My process for designing each level was to create storyboards scene by scene, then animate them all out using 3D Studio Max.  I did this to save time over creating my own level editor from scratch.  I created several 3DS Max plugins to export to the level file formats I created for the game and effectively turned 3DS Max into a level editor.

Progress on level design went very well and most of it was done until November '08, which was a big turning point for the project from the technical side.  I had an interview with a bigger game company in NYC.  I was happy with where I was working at the time, but I wanted to test the waters and see what other opportunities were out there for me.  Since BlastZone 2 was the center piece of my portfolio, I had them analyze parts of my codebase.  The response I got was rather jarring, pretty much saying that while I was able to accomplish amazing things, my codebase was poorly designed.  Looking at my code, this response made sense to me, since BlastZone 2 initially had a very small scope, then was expanded later on.  The basis I started with was not designed to manage such a huge game and adding new features was getting more painful to do and maintain.  In the end I did not get the position I interviewed for, but the lesson I learned from that experience was extremely beneficial.  At that point, I decided it would be worth while to redesign my entire codebase from the ground up and do it right this time.  This process took about 11 months to complete, ending in October '09, but the benefits were huge.  Now I could add new features and polish existing ones with much less effort and I even created an alternate render path for OpenGL ES support, which is used for iOS and Android devices.  In the end, I was able to create a much better and more polished game from the redesigned code.

Stay tuned for the next blog entry for BlastZone 2 and its continued development!

Monday, December 5, 2011

The early years of development

Welcome to the second blog post for BlastZone 2! In the previous post, I talked about how the BlastZone 2 project started and now I will describe the first few years of its development.

About 3 months into the project's development, there was a game development competition at my college. At that point I had already made significant progress beyond the original BlastZone remake and created two new game modes; Mission mode and Enhanced survival mode. However, these modes were still in their infancy with only the most basic features implemented to make them playable. Even so, I figured that my game was going to win the contest no matter what since everyone else entering the contest only worked on their games for 2-3 weeks and they were all 2D games. Even though my game used 3D graphics, the models in the game were simple and boxy with sine-wave hills in the background. My game ended up coming in second place and I was really devastated considering the work I put into it so far. However, that feeling didn't last long and I used that game contest as motivation to redouble my efforts to make my game the best it could be.

BlastZone 2 after 3 months of development, entered into the game development competition

Over the next few months, my renewed determination really payed off; BlastZone 2 made huge strides of improvement and quickly got the attention of job recruiters. I got my first internship within a month of the game contest, and then a full time position in the games industry 2 months after that! When I started working on my game, a few people asked me if I was working to get into the games industry, but I always laughed at the question as I figured it was only a distant dream and I had no real chance at all. Little did I know that only 6 months after starting my game I got my first full time game industry job! The job was for doing casino and betting games, but I still had a blast doing it and was proud of what I had achieved. However, I didn't let it stop me from continuing work on BlastZone 2 during nights and weekends.

The fall semester of '06 was my senior project.  As soon as it was mentioned that there was an entrepreneurial track for it, I immediately thought of my game.  I sent in a proposal to my senior project professor and he approved it!  I was excited at first but then felt a little guilty since everyone else on the entrepreneurial track was starting a new project from scratch.  I decided to start two new support projects for BlastZone 2 for the senior project to make it more "legitimate"; A website and an online leaderboard.  I had an interesting opportunity for feedback about half way through the semester.  I presented BlastZone 2 in front of a group of students and several entrepreneurial advisors in the college program.  I got some good feedback from the session, but above all else they wanted multiplayer support in the game.  I never considered multiplayer up to that point, but if people really wanted it, I was going to do my best to deliver it.  The final senior project presentation and public showcase was only a few weeks away, but I worked really hard and just barely got local multiplayer in there in time.  During the public showcase it was great to see people having so much fun playing the game and they loved the multiplayer support!  Several people even said they wanted to buy the game on the spot which was great to hear.  In the end, the senior project experience was very positive, although the subprojects developed during it ended up being replaced later on during the game's development.

BlastZone 2 after 10 months of development, for the senior project and second game competition

Near the end of the same semester, there was another college game development competition that I entered. This time my game won by a large margin and I was so ecstatic! Attendies couldn't believe how far BlastZone 2 had come in just a few months and they were really interested to hear about how I did it. I was happy to share my enthusiasm for game development and hoped I would inspire others to start games of their own.  However, I didn't let this victory make me complacent.  I used the enthusiasm from the competition power me into expanding the scope of the game even further.

I hope you enjoyed reading about my experiences developing BlastZone 2 so far.  In the next entry, I will cover the later development stages including some drastic shifts that occurred during the project.  Also, for those who are interested, in future entries I will cover some of the technical details of how the game was developed and the kinds of choices made in its architecture and gameplay elements.

If you or anyone you know wants to make their own game or any other kind of personal project, make sure you stick with it and don't let failures early on discourage you from following your dreams.  Don't let your successes make you complacent in your work either.  Always strive to keep improving your skills and never give up!