Current and future work on BlastZone 2

Welcome to another blog entry for BlastZone 2!  In this entry, I will go over some of the future plans for BlastZone 2 and my game development work in general.

As of the time of this writing, the latest v1.10.2 free update for the iOS version has been released, and the feedback has been great!  People really like the new relative touch control scheme and auto-fire option and achievements support.

The new relative touch iOS control scheme with movement cursor

Also, I recently completed the iOS 4.x compatibility update which will help bring BlastZone 2 to a much broader group of iOS users.  When I started working on the iOS version, I made sure I updated to the latest Apple development tools.  However, doing this created several dependencies on the latest iOS 5 and broke compatibility with iOS 4 and earlier.  For the initial release, I decided to require iOS 5 to play the game, as I briefly attempted to backport the code to iOS 4 and things broke apart rather quickly.  I didn't want to risk a broken game or buggy release.  However, this time I've spent a lot of extra time researching the differences between iOS versions from a technical perspective.

I've had to completely rewrite the OpenGL ES initialization code in a much more advanced way for it to work across multiple iOS versions. The iOS 5 development tools had some convenient built-in infrastructure that allowed me to complete the initial version quicker, but this broke compatibility with previous iOS versions so it wasn't a good long term solution.  I've also had to write code to enable certain features for people with higher iOS versions while maintaining compatibility with earlier versions.  I've tested and confirmed the new update to work for all iOS versions including 4.0 and above.

Since the compatibility update is done and waiting on Apple to push to the App Store, I have already moved onto the multiplayer update.  This one will take a bit longer than the previous updates as I have to port over all the PC multiplayer code and do the iOS Game Center integration for it.  Game Center is a great platform to develop support for server lists, friend challenges, and match making.  This will all help foster a great multiplayer community and help grow popularity for the game.  I will also be looking into bluetooth ad-hoc support.

I've done a lot of research for iOS multiplayer so far and it will be an interesting challenge for me.  I got the PC online multiplayer support to run very fast through some CPU-intensive delta detection and bit-level compression algorithms.  I was able to offset the additional CPU load by making the PC implementation multithreaded.  For iOS, I will be able to leverage a decent amount of multithreading, but the problem is only the latest iPhone 4S and iPad 2 have a multicore CPU to benefit from from that kind of design.  Crunching this down to perform well on the iPhone 3GS for example will be an interesting task, but if I make big efficiency improvements like I did for several other areas of the game, I will definitely release a patch for the PC version with them as well.

From there, I will move onto researching other platforms to port BlastZone 2 to.  First on the list will be Android.  I've been getting a lot of demand for an Android version and I did a lot of research on a possible Android version back in September of 2010.  The idea back then was to develop simultaneously on Android and PC, but I was having problems getting C++ code to compile at all.  I started spinning my wheels at that point, so I decided to refocus on the PC version and revisit Android later on.  It turned out compiling C++ code on iOS was much easier, so that's why I put off Android support a bit more.  Through all this, I can confirm that I will put effort into an Android version in the future, but I can't guarantee it will be released for the platform at this point.

I have ideas for entire new games in the future as well.  Some of these games are smaller in scope, and others are larger in gameplay scope, but will take significantly less time to develop due to their design.  Either way, I will be reusing a lot of code from the current BlastZone 2 game engine, so there won't be any more 5 year long development cycles.

The future looks exciting and I can't wait to get more content and updates out for everyone to enjoy!  I am totally committed to releasing all of these BlastZone 2 updates for free!  So keep the feedback coming and I'll be happy to comply!

BlastZone 2 Makes its way to iOS!

Once I accomplished all the goals I set out to do for the PC version post release, I decided to start working on the iOS port for the game in November '11.  A year prior, I had already done a lot of work on an alternate render path for OpenGL ES, which is used for graphics programming on mobile devices.  Since the PC version uses the desktop version of OpenGL, this transition doesn't require replacing all the graphics code.  There were other systems I had to rebuild to work on iOS, such as the sound and input systems, but they are much smaller than the rendering system.

** This section gets a bit technical if you're curious **

Most of the OpenGL commands that aren't available for mobile devices I was able to replace with generic code that works on both the mobile and desktop versions of the game.  However, there is one big feature of desktop OpenGL that I didn't want to remove for the mobile version, which is why I built the engine to have two render paths.  The PC version of BlastZone 2 renders most of the graphics using something called a "Display List", which is very fast to draw even on slow computers, which allows me to add more detail to the game without slowdowns.  This method of drawing can only be used in specific circumstances effectively, but BlastZone 2 just happens to be the perfect game for this.  Virtually every model in the game is perfect for this method of drawing, such as airplanes, space ships, and terrain.  The types of models that are bad for this drawing method are more animated ones, such as people and animals.  Instead of Display Lists, OpenGL ES has to fall back to using Vertex Buffer Objects(VBOs) to speed up rendering.  While the speed of this method is respectable, the main reason I assume this was favored is because it can be used for any model type and isn't restrained by favoring specific types of models over others.  However, VBO's are much slower to render than Display Lists, and are roughly half the speed during my tests on the PC version.  Having a slower device that uses a slower rendering method really compounds performance issues, so it was an uphill battle to bring performance up to where I wanted it.  I put a lot of optimization work into the VBO render path for the game and had really tangible results doing so, but it never cought up to the performance of the Display List render path.

** End technical jargon **


When I finally got the game to compile and run on the device, it was a huge moment for me.  While the game was only chugging along at around 5 to 6 frames per second, it was so incredible to see my creation running on such a tiny device that can fit in your pocket.  Up to now I was only used to seeing BlastZone 2 run on a big desktop pc or a laptop.

BlastZone 2 up and running on the iPhone for the first time!

As an engineer, developing for iOS is an interesting and fun problem to solve.  I had to squeeze my existing game into a device that has much less memory and processing power by figuring out a lot of slick optimization techniques, pushing my programming abilities to the limits.  I had to do this while getting the same amount of work done in the end and keeping the game looking almost identical to the PC version.  Fortunately, all iOS devices use a PowerVR graphics chip that supports a very efficient texture compression technique that worked really well crunching down memory requirements without affecting image quality.

The other big goal I was shooting for was crunching the app download down to 20mb so it can be downloaded over a 3G connection and therefore more accessible to my audience.  It was tough, but I managed to do that as well, compressing down the audio and textures without a noticable difference to the player.

All the above helped a lot, but it still wasn't enough to get the performance to a level I wanted.  I had to fall back to reducing geometry complexity as an easy speedup.  I managed to do this in an intelligent way, and with the smaller screen of the iPhone, the game looks almost exactly the same as the PC version.  This brings the graphics fidelity to be very close to some of the best looking games on the platform, which really helps BlastZone 2 stand out on the Apple app store.

Working with iOS gave some great opportunities for adding new control schemes to the game.  The first control scheme I implemented used a virtual d-pad that mimicked how a PC controller or keyboard would play.  From there, I added an accelerometer tilt control option to give an intuitive way to control the ship without having the touch the screen and cover the gameplay. The third control option I implemented was a direct touch control, which moves the ship to your finger, giving the player much more direct and precise positioning not possible on other platforms.

iOS version shaping up really well!

The iOS development had one other good side effect.  I had to put a lot of work into optimizing the performance and memory usage to help the game run acceptably on the iPhone.  Since the game uses a unified code base, I was able to easily bring those optimizations to the PC version, reducing the minimum specs even more without any loss in quality.  I was even able to get the game running at full detail at 60 fps on a netbook which is quite an accomplishment.

Overall, it took about a month and a half to complete the initial port of BlastZone 2 to iOS, which greatly exceeded my expectations.  There were two main reasons for this.  The iOS development environment is very  friendly to C++ development, which integrates seamlessly into the Objective-C based development kit.  Secondly, as I mentioned earlier, iOS uses OpenGL ES to render 3D content, which is very similar to the desktop OpenGL the PC version was written in, but with several functions removed.

Even though the iOS port was done rather quickly, this was at the expense of a few features to get it done in time for the holidays.  The main functionality missing was Apple Game Center integration, which most of the upscale iOS releases do have.  I was able to release an update soon after release to add basic Game Center support and leaderboards since these didn't require much code and I could reuse much of the leaderboard code from the PC version.  At the time of this blog entry writing, I am researching and will begin porting over online multiplayer support very soon.  Online multiplayer support will be a killer feature for BlastZone 2, as its very rare for an iOS side scrolling shooter to have it.  The big advantage I have is that I already wrote all the core logic to get online multiplayer working from the PC version.  The main task now is to integrate it into the Apple Game Center and have Ad-Hoc support at the same time for really low latency play.

BlastZone 2 shortly before the iOS release

Initial reactions and feedback have been very positive and download rates have been great, but I quickly got a list of features people were looking for to improve popularity of the game.  The main control scheme people wanted for an iOS side scrolling shooter is relative touch, which allows the user to move the ship around the screen by the relative touch movement on any part of the screen so this ship doesn't get covered.  Also, people wanted an auto-fire option.  Thankfully, these features were fairly quick to implement.  At the time of this writing, these new input features have been completed along with Achievements support and I'm excited to ship the update out to my audience.

I hope you enjoyed reading about my experiences with the iOS version of BlastZone 2.  Its been a very exciting process and release for me, and the feedback has been incredible!  Downloads and sales have already far surpassed the PC version and I can't wait to ship more updates and features for the game!  As it turns out, BlastZone 2 is very well suited to the iOS platform!

In my next entry, I will detail the future of BlastZone 2 both for the iOS and PC versions along with the other directions the game may take.  See you next time!

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 GameTunnel.com.  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 Bytten.com 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!

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!

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!

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!

Introduction and Beginning of the journey

Hello, my name is Matt Edzenga, and I’d like to welcome you to the blog about my game, BlastZone 2! This game has been a huge passion of mine for the last five and a half years and it has been an exciting journey the whole way.

However, before I get into this game, I’ll give some background on the first game, BlastZone. This was a game I wrote in highschool on my TI calculator using TI basic and ASCII characters. The basic premise of the game was to mimic some elements of a side scrolling shooter. The player ship could only move up and down and the main goal was to destroy all enemies before they pass by the player. There was no end to the game, so the player just went for the high score. There were three weapons at the player’s disposal; a thin laser, a wide beam, and the omega cannon which covered most of the screen, and all enemies were destroyed in one shot. The laser had infinite ammo while the other weapons had limited use. This game took me about two weeks to build, and at that point I had already maxed out what the tiny 8mhz calculator processor could do. I enjoyed working on the game, but I knew I couldn’t add anything else to it. I was content with my creation at the time, but over the next few years I would always have an itch at the back of my mind to recreate the game on better hardware that would allow me to grow it further.

BlastZone 1 TI-85 calculator game

That is how things would stay until the first fateful night I started working on BlastZone 2. I remember the first night very well.

It was Friday, February 10th, 2006 and I just got back to my dorm room after having dinner with my friends. Just on a whim, I opened up the NeHe OpenGL graphics programming tutorial and started experimenting. I wanted to program in C++ and OpenGL because that is what many big game developers use and it would give me much more power and control over the computer hardware. I knew this path would be very difficult, but I really wanted to learn it from the ground up. I also felt I would get much more gratification building everything from scratch instead of taking shortcuts. I quickly became engrossed in the programming as the technical side of computer graphics has always interested me. After a few hours I programmed enough to initialize the graphics hardware in my computer and start up a blank window that accepted OpenGL API calls. I immediately started working on an early prototype of BlastZone 2, which was only supposed to be a quick and dirty version that had three main features. The game had to allow the player to move up and down, fire lasers, and destroy enemies. The game would end when 3 enemies passed the player. The hours went by that night and before I knew it, my game was up and running exactly how it used to on my old calculator! At that point, I knew it was time to get to sleep as I saw the sun peeking through my window. I didn’t even realize nearly that much time had gone by. I had programmed for 12 hours straight and loved every second of it! That’s how I knew BlastZone 2 would be something big, but even then I really had no idea how big it would eventually become.

BlastZone 2 after the first night of work

The next day, I started working on proper plans for BlastZone 2. My plan at the time was to spend roughly 3 months to finish off the remaining features from the original calculator game, such as a few more weapons, and add several new features, such as better difficulty levels, and multiple waves that would gradually increase the difficulty as the player played. In addition to this, I wanted to create simple 3D models for the player ship and enemies, and a few cool particle effects and level transitions to polish it off. I felt these plans were all I really needed in the game to finally achieve what I had always wanted to do, and I’d get plenty of programming experience while I was at it.

Much to my surprise, I was able to finish everything I planned for and more within 2 months! At that point, I was so excited with everything I was learning and the results I was getting that I didn’t want to stop there! I immediately started designing a much more ambitious version of BlastZone 2 that would include multiple game modes, and tons more enemy and weapon types. I was having so much fun developing my game and I didn’t want it to end! I didn’t have a target date for completion anymore and the sky was the limit!

This was the start of the great journey of developing BlastZone 2, and back then I had no idea it would get as huge as it has. I was just concentrating on doing what I loved to do!

In my future blog entries, I will follow the timeline of development and cover several significant events that happened along the way. The development hasn’t been a smooth ride the whole time, but it’s been very eventful!