Birth of a Game

We are hiring!

Uber is looking to hire a gameplay programmer.  

Requirements:

• Experience shipping at least one game title or a solid game mod.
• Exceptional programming and debugging skills across a range of languages including C++ and Unrealscript.
• Exceptional sense of game design and the ability to implement and contribute gameplay ideas.
• Strong teamwork skills.

We offer a very strong benefits package including fully paid health insurance, 401k, a generous bonus plan and a fun team environment.

If you are a superstar and want to find out more please email jobs@uberent.com.

Practical Programming

A common definition of a "Code Nazi" is something like "a programmer who rigidly enforces arbitrary programming standards for their own unexplained reasons." Personally I think this definition misses the mark. Most of the time there are very good reasons for enforcing programming standards. Over time though, the explanation as to why may be lost in the history of an organization. The point here is that you have to have a set of guidelines that apply to the code that's written in your organization. Understanding the "whys" of these guidelines is in my opinion what separates the master from the apprentice. In addition understanding the intent of a particular rule allows you to make a solid determination as to when to break or bend a rule. This is what practical programming is all about. In our case where the rubber meets the road is in the handling of licensed technology. I have chosen an extend instead of replace methodology that in some cases creates additional up-front work but should generally make our interactions with the underlying technology easier to deal with.  

I think at this point in time most people would agree that the maintenance cost of a piece of code is often times the vast majority of the cost of the code. This implies that correctly writing any piece of code upfront, even it if takes significantly longer, will give you future cost savings. This has to be tempered by a realistic view of what the future of that particular code is going to be. In practice this often takes the form of using your most senior programmers to handle the most important pieces of code. This probably does a disservice to those who are new to the craft as they often end up writing one-off or throwaway type code.  So getting your more experienced people working side by side with your best people on your most difficult problems seems like a good idea to me. If you can get everyone on the team hitting the high notes (to paraphrase Joel http://www.joelonsoftware.com/) your team will do better work. There is no better way to understand a difficult problem than to explain it someone else in enough detail to have them implement the solution.

So, understand the lifetime of the code you are writing. Engage others on the team when working on hard problems. Mentor and invest in your more inexperienced people. Look at things from a practical perspective and don't lose sight of the big picture.

Successful Technology Licensing

When the game engine licensing business started to take off in the mid 90's we saw a lot of pain and suffering occur. Publishers bought bulk licenses and would force the technology on game teams, sometimes halfway through development. In other cases the thinking was, "we just licensed this really expensive tech so we don't have to keep a bunch of expensive engine programmers on staff." This was obviously dangerous thinking and a lot of projects crashed and burned due to lack of technical capabilities. There are some cases where you can get away with treating licensed tech like a black box. For example, RAD Game Tool's Bink Video has been used in over 4,000 games. It just works and I doubt most people using it read the source code thoroughly. However in the case of a 3D Game engine, where it is the central nervous system of your game development effort, it's important to know the technology inside and out in order to use it efficiently.

Rule #1: Successful game engine licensing requires you have the technical capability to create the technology but choose not to.

This has several implications:

• You only need a team capable of understanding the technology completely but not necessarily the manpower to create it from scratch. This could be one person leading a team of less knowledgeable and less experienced programmers. Obviously strong leadership here is critical.
• Choosing not to create the technology is why you license in the first place. However, teams still find reasons (NIH) to gut and rewrite large portions of the engine. This is a recipe for failure and requires serious technical discipline to overcome.
• Choosing not to create the technology but having the capability to do so allows you to focus on differentiating features rather than reinventing the wheel.

Equally important albeit more obvious is when licensing an engine the game design should be adjusted to play to the strengths of the engine.

Rule #2: Technology and Design must be adapted to fit one another. If one can not bend, the other must.

It's important to be realistic about this up front. Some game designs are created well before the technology and the development process is largely about creating the engine to accommodate the game design. This can work if planned properly, however if you bring in a game engine expecting to apply it directly to a game design you could be in for a world of hurt. A good game designer will work with the programmers and technical artists to understand the strengths and limitations of the technology and adapt the game design to fit. In the case of a licensed engine, design needs to be the more flexible. Otherwise you're likely not playing to the strengths of the engine. Spend your technology capital where it counts; on differentiating features.

Licensing technology can be a big win, especially for a small company looking to bootstrap their business while keeping overhead low. It is half of the equation for us and we'll be discussing the other half in future posts. Stay tuned!