At these early stages of prototyping, with game design decisions abound, the question of 'how many' is very prevalent. Every part of the game design begs this question. How many classes? How many abilities? How many entrances to a part of the map? How many players? How many points? How many types of X? How many woodchucks?
Ever wonder why football has 11 players on the field? Why are field goals worth 3 and most touch downs worth 7? 11 players in soccer? 3 outs in baseball? 5 pitches for a full count? 5 players in basketball? 5 colors in "Magic: The Gathering"? 3 factions in the best RTS games? 3 possibilities in "Rock-Paper-Scissors"? Chuck wood, who chucks wood?
The answer to all these questions is simple: Prime numbers. Prime numbers force conflict. Prime numbers unbalance the game and encourage players to push on the imbalance. When designing a game and you have the question of 'how many', fall back to a prime number. So for me, when I was trying to figure out how many base chassis we should have, I started with 3. When I needed to decide how many variations on a skill we needed I started with 7 and then cut it down to 3. (More on what 'chassis' and 'skill' means in our game at a later date.)
Prime numbers are a guideline, not a rule. The best game design guidelines are the one that the great designer knows when to break. Break this guideline, on occasion, and you'll be left with an even more interesting mechanic. One could say that the NFL got more interesting when they started allowing the two point conversion. All of a sudden we have a game that every once in a while an 8 or 6 point touchdown adds an interesting wrinkle to the whole game.
Level designers should take note of this idea as well. The best level designs also use prime numbers. I have something I call 'The rule of 3' and that is: Every main combat area on a level should have three different entrances per team. Again, this forces conflict. Break this 'rule' if you want to tilt the favor to one team over another. "Team Fortress: 2" does this very well. The "Call of Duty" series also has spectacular level design in this regard.
With this knowledge, you will be primed for success. Good luck.
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.
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:
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!
For an interactive medium like ours, generally speaking, the first time an audience gets to experience our game will be through passive screenshots, gameplay videos and trailers. It's so crucial to make those memorable because they will be dissected to the nth degree.
Here are some images from current and upcoming 360/PS3 games that I think are successful in visual immersion and standing out from the crowd.
There's no mistaking Rapture's decaying art deco styling to any other game. That combined with the iconic Big Daddys and Little Sisters make the game memorable.
From the familiar chorus and orchestral music on the title screen to dropping the player into a HDR showcase lush jungle separates this sci-fi shooter from the rest. Very polished game.
Team Fortress 2
a perfect marriage of visuals/gameplay/tech. The character teasers Valve did sold the world so well. This game overnight became the de facto "stylized" look that all other games are compared to.
Gears of War
amazing amount of detail and interesting believable characters. Gears used post-processed color correction, desaturation, and Depth of Field to sell the mood well.
Simply epic. As a player you really got a sense of being a small part of a much bigger picture. An RPG like this one lends itself to more subtle character interactions and developments.
closest thing to an interactive painting. Great use of subtle layering.
Prince of Persia NextGen
Interesting re imagining of the franchise. Reminds me of a stylized graphic novel in motion. The look is suited well to the gameplay mechanics of corruption/restoration.
ultraviolent post apocolyptic world with twisted humor and deep gameplay. I never played the original Fallouts but this one looks very interesting.
bleached clean sci-fi setting, color cueing to help the free running gameplay. Good use of visuals for gameplay immersion.
I'm Chandana Ekanayake, Art Director at Uber Entertainment. People that know me call me Eka. It was 12 years ago in October 1996 that I started as an artist at Bethesda Softworks. Earlier that year I worked out of a house with several other guys at a startup CG studio. We pretty much took on anything that paid the bills, from architectural renderings, interactive virtual flythroughs to rendered game cinematics. I was working 80+ hours a week; learning modeling, animation, motion graphics, editing; and whatever else I could get my hands on. It was an intense crash course in CG production and those memories and the time we had as a small group I still treasure to this day. Even though we were pretty naive about the business and production practices, our hunger for knowledge (and just general hunger ) kept us going until Bethesda brought us in as full-time employees.
Since that time I've worked with both small teams and very large teams on a variety of projects and genres. What drew me to Uber was the collection of talent and the opportunity to work on a project from the ground up with a small focused team. I'm about to start on my third week and already we have a fun playable game that we playtest daily. I've been replacing the early prototype assets with more presentable temp assets that will be iterated on and turned into shippable quality. At the same time we're establishing the world, themes, mood and fleshing out gameplay mechanics which translates well into figuring out an aesthetic direction for the game.
I've been thinking a lot about how to stand out in the current and future marketplace. What is the style and the visual hook? How do we differentiate ourselves from the competition? What are the current trends and how will that change over the course of the project when we ship?
When starting a new project my motto is "Find the Fun First". I've seen too many projects ramp up a full production team based on a loosely written design document (or tome). They grind out new tech subsystems and art resources for a year or two only to discover the game isn't any fun. Why isn't it fun? Is it because the design doc is so incomplete? Are the programmers not delivering tech on time? are the artists falling behind in the production schedule? Having ramped up too early it's quite likely all of these are true, however they're not to blame for why the game isn't fun.
When we prototype our gameplay we use a process called "whiteboxing". This simply means we create the absolute minimal amount of code and art in order to support a particular game mechanic or feature. Often times the minimal visual representation is simply a white box, hence the term. If your game isn't fun with 100% whitebox assets and code then it isn't going to be fun with $10 million in beautiful art and robust game subsystems. The less you've invested in art and code during the prototyping phase, the cheaper it is to change things when they don't work out. What sounds fun on paper doesn't always work in game.
You can spend a year or more in this phase and spend relatively little money. The unfortunate part is that when trying to sign a deal with a publisher you're likely going to have to create something "pretty". This usually means the dreaded "vertical slice" which is one of the worst industry practices in existence. That's not to say there is no place for a vertical slice, but it certainly doesn't belong anywhere near the prototyping phase. This is a topic that deserves it's own post in the future. For now, I'll just leave it saying it's in our best interest to stay as long as possible in the prototyping phase. Lean and mean.
Once upon a time Scathis and I had the pleasure of working on a project together, just the two of us, for a solid year before even bringing on an artist. Our goal was to come up with some innovative gameplay that could be executed on some existing technology with relatively little changes. In that time we tested tons of ideas, threw out most, and eventually honed in on some really great gameplay. When we brought in our art director he brought in a welcome breath of creativity and was vital to bringing our fun, yet ugly game, to life. For this reason, we're very excited to have had our art director come on board last week. We intentionally wanted to bring him on early in the process as his virtuoso ability will enable us to prototype ideas that have advanced technical art requirements such as intricate animations and material compositions. Expect to hear from him soon!
We at Uber Entertainment make games by iteration. We basically build a bunch of white boxes to represent the game play so that we can make lots of stuff really fast and we can see if it works really fast and we can test it and find if its fun really fast. Every time we get to a playable point we can jump in and play the game and see if its fun and then jump right out and decide what wasn't fun and what was more fun. Once we find out what wasn't fun and what was more fun we can quickly go in and change the game to be the more fun way. Every time we do this the game gets more and more fun and more and more nicer.
We at Uber entertainment iterate on our early prototypes. Iteration on our early prototypes means we basically build a bunch of white boxes to represent the game play so that we can know what is fun to play and what is not. We build the game until we get to a point where we consider a section playable and them jump in and actually play the game. Then we ask, is this fun? Can it be more fun? Then we go in and change the game to be the more fun way. Then the games just gets more and more fun with each iteration.
At Uber Entertainment we create our game by iterating on the game first. The game prototype is made by creating white box art. Those white boxes allow us to put in and pull out new features at will, without losing man months worth of work on real art assets. We play the game, once a new feature goes in, so that we can readily see what works and what doesn't work. We 'find the fun first'.
Each iteration makes whatever you're working on better and better with each try. How good will the next iteration be?