Birth of a Game

This calls for a celebration!

The Title Update is out now and will download next time you start up Monday Night Combat on Xbox Live. Along with a ton of fixes and gameplay balance, we’ve increased the Trial time to 60 minutes. If you already have the Trial and have used up your 30 minutes, guess what, you get 30 more. For those of you haven’t downloaded the game yet, you get a full 60 minutes of bacon goodness over Xbox Live and unlimited Local Blitz play.

Also, to celebrate this momentous occasion, follow http://twitter.com/uberent for lots of free code giveaways of full versions of Monday Night Combat for the rest of the week.

So what took so long?

Our general philosophy on Monday Night Combat is that it is a service based model of game. For a multiplayer game like ours to be successful, we need to adjust balance, fix exploits, and add new content based on feedback from our community and do it quickly. Unfortunately for the our first Title Update, which was handed off to Microsoft for certification over a month ago, got caught up in a perfect storm of software changes and tons of new games coming out. This caused our Title Update to get backlogged along with other smaller titles. They tell us this won’t happen again in the future so our first free DLC should be out sooner than later. We’ll have announcements of what’s in that DLC in the coming weeks.

For a full list of changes in the Title Update:

Title Update Details

One of the first and most important evaluations you have to make when creating a game is what your technology situation looks like. This is driven by many factors including what platforms you see the game releasing on and of course what the game actually is. In our case there is an additional factor, we simply don’t have the time to build an engine from scratch. This is a huge departure for me personally as I’ve never worked on a game where I didn’t have a hand in writing large chunks of the engine. Typically we would go through a large technical design process to figure out what tech we need to build for the game. In our case the technical design process still exists but it’s more along the lines of making sure that the technology we license will work for the game we want to make. In addition game design decisions have to be measured against the technology we are using.

Games have gotten bigger and more complex to the point where it’s not impossible to build your own engine but there are so many fingers and toes that the amount of time to write it all becomes a huge issue. Luckily there are several competent engines around that can do the job for the type of game we are creating. We have primarily settled on one engine but we can’t announce which one it is until the final decision is made and all of the contracts are in place.

Of course once you’ve made an engine decision you still have a lot of work ahead of you. Assuming that you’ve done the technical due diligence on your engine you now actually have to setup your development environment to deal with that technology. In our case this consists of having a Perforce repository with all of the engine code and setting up the appropriate directories for all of our source code and assets. This is usually called “the pipeline”. Generally speaking dealing with the code aspect of the pipeline is easy, it’s the many gigs of art assets that need to be carefully tracked and controlled.

You also need to have a system in place to deal with updates from the engine company so that you are able to get bug fixes and additions to the engine. This sounds like it shouldn’t be a problem but if you make any modifications to the engine they may conflict with updates and make it difficult to integrate new features. In general we are trying to avoid modifying any licensed technology as much as possible.

Now once you have a skeleton game up and running on a new piece of technology the really hard stuff begins. You have to begin to figure out how to realize your vision with the technology that you have. At this point we are really just concentrating on prototyping the style of game play that we want to create. This learning process can happen in parallel with us defining the key feature set of the game during this prototype phase. This allows us to ease into development and gradually learn the in’s and out’s of the technology that we’ll need to know to finish the game.

Hi, my name is Bob Berry. I’m the president of Uber Entertainment, a new startup video game company. We talked about doing a developer diary for our new game and we’re finally making that happen. We decided to call it “Birth of a Game”, a name that has special meaning for me. My wife gave birth to our second child in March right around the same time I left my previous company to start up Uber. In a sense I felt like I was having two children at once! Giving birth to a new company is like being in labor for a whole year. It’s an emotional rollercoaster filled with waves of pain, periods of calm, and finally at the end, a final push with all your might. Now we’re at the point where the newborn company needs 100% attention all the time. And yeah, I have to change the diapers.

I’m so excited to finally be at a point where we can speak openly about the company. For the past several months we’ve been flying under the radar working on prototyping our game and securing financing. It’s been a lot of fun being back in startup mode again. The last time I did this was about 10 years ago!

I was fortunate enough to be able to work out of my house for the first few months. This was a blessing for my wife as I was always around to help out with our newborn or our rambunctious two year-old. When we finally reached a certain critical mass it was time to exit the virtual and enter the physical. Having the development team working together in an office increased productivity dramatically on many fronts.

Some other key members will be posting introductions in the near term. I look forward to sharing with you details of our trials and tribulations!

“o”
President
Uber Entertainment