Questions for You to Answer - Game Developing

Here are some straightforward questions; your mission is to take some time, grab a piece of paper, and write down the answers.

  • What are you trying to accomplish with this game?
  • When must you complete this game project?
  • How much money do you have to produce it?
  • Who do you have to get the job done?

What to Do with These Answers

An Ultra-Low Budget Game
If you are funding the project yourself with your free time and hobby money, you have a very distinct limit on how much money you can afford to spend on this project. The goals for your project should be correspondingly low. your project should amount to no more than 500 to 1,000 hours of work per person to finish your project in a year. A way to partially solve your budget problem is to share your project with others: friends, family, and even folks across the Internet. Coordinating a group of volunteers to work together on a game project is very challenging, and their creators abandon the overwhelming majority of these projects. However, id Software used essentially this method to escape their stay at Softdisk. The goal for this type of project for the creators is most often to do the project for fun and to act as a compelling demonstration of their abilities to land a full-time position in the game industry. There are two principal paths to take: Make a small game or produce a modification to an existing commercial game (called a mod).

JARGON: Mod is the name for a game that is made from the engine and assets of another game.

Ambitious mods that offer extensive changes are often called total conversions. Making a small game and making a mod are two different sorts of projects; each has its own challenges, and you will learn different things by accomplishing them.

Many people might think that creating a demo of a simple real-time strategy (RTS) game that has incomplete AI, poor art, and no sound could still represent your passion for creating a large, commercial RTS. Yes, you might get your passion across, but in my opinion it would not be the best demonstration. Just like consumers of games, we do not want to have ten features shoddily executed. Instead we would rather see just three or four polished features that are shippable. It is not interesting to know how long it will take you to implement feature X, rather it is much more compelling to know how long it will take you to drive feature X to shipping quality. The folks at Silver Creek Entertainment have taken this to heart and have produced the most excellent card games: Hardwood Spades, Hardwood Hearts, and Hardwood Solitaire.

These folks have taken the very simple feature sets of these classic card games and have added gorgeous 2D graphics, flawless online multiplayer format, and clever added features such as customizing your avatar’s look and tossing fireballs at your opponents. Silver Creek started with an artist passionate about quality for his card games and two other developers; they now are running their own development company and are hosting their own online games without funding from a publisher. This is a significant accomplishment, for these folks have achieved what many developers aspire to self-funded games; and they have done it in an area of high risk online games.

This is such an excellent model driving a few features to perfection that the folks at Silver Creek are not sending out their resumes and seeking a job working for someone else in the industry; instead, their hobby project was developed in a product with real value to thousands of players.

To be successful with this model you need to find a game concept that is simple but playable and would require a minimum of engineering to get it functional. This would leave the balance of your time to create lush polish to that feature set.

Creating a mod of a commercial game is another way to work with an ultra-low budget. Principally, two guys, Cliffe and Minh Le, created the phenomenally successful mod to Half-Life called Counter-Strike (CS) with some textures created by three other guys. They started with the Half-Life engine, which is in turn a variation of the Quake engine. Half-Life itself is a mega-hit from Valve Software that taps into the underserved market of players looking for a compelling story to engross them as they enjoy the action of the first-person shooter genre.

Starting with a commercial hit game has the same compelling marketing potential for your mod as it does for a publisher’s sequel to a hit game. The Half-Life engine was eminently amendable to user modification, to the point where even the menus of the game support choosing a custom game type. The CS project was created by an experienced team that had worked together on Action Quake 2 and other mod projects before, so a single mod project was just the first step for these guys. It was their third project that really blew everyone away including Valve. This team, due to its experience and reputation on previous mod projects, received unprecedented support from Valve including design feedback, technical support, and even project financing.

Counter-Strike perfectly illustrates a project that is on budget and is of very high quality, but the time side of the triangle had to be as flexible as they come. CS was released in the summer of 1999 as beta 1, and it took nearly two years for it to proceed through four more major releases and ship as an expansion to Half-Life in retail.

Fixed Budget, Fixed Deadline
I am most familiar with projects with these sorts of parameters, as all of my shipping titles have had these parameters. I have worked on one professional title that had a ridiculously low budget, PlanetNET, that never shipped. At Taldren we are now working on several game concepts that have a variety of business parameters to fulfill different roles for the future of Taldren. But fixed budget, fixed deadline games are what my reputation is built on. To make these projects work you must walk backwards from your shipping date and determine your beta and alpha dates. This will give you a gross amount of time available for your production and preproduction phases. I am a strong supporter of preproduction and feel that any project worth doing should spend about 15 to 35 percent of the total development time in preproduction. This will give you a crude estimate of the man-months you have available for production. This is your budget for man-months.

Now with your man-month budget in hand it is time to sketch out the feature set of your project. Break down your list of features into three piles: primary features, secondary features, and tertiary features. This section discusses how to identify your core features and put the secondary and tertiary features into other piles. You must then create a project plan that clears away all of the dependencies and risks and supports the primary features.

During production on these titles you will find yourself shifting secondary tasks to tertiary and primary to secondary when you are low on time and popping the secondary and tertiary tasks up when you have available time. It is vitally important to your production team that you do not make all features must-do items that you reluctantly cross off as reality presents itself. People perform badly when under the cloud of being failures; for the sake of your team and your game, set them up to succeed by prioritizing your features into these three different categories.

In fact, your team members will cruise through their primary tasks so much more confidently that they will develop their features at the fastest rate possible. Feeling like winners and making progress only enables them to get excited and want to knock off the secondary and tertiary items. Perhaps the most compelling reason to separate your features into these three piles is that all features inherently have a priority, and you will make choices during production. But it is only through formally acknowledging these priorities and writing them up in your plan that you will derive all of the planning benefits of knowing what you really must get done.

AXIOM: All games inherently have primary, secondary, and tertiary features; the wise developer will embrace these prioritized features lists and turn them into an asset.

High-Profile/High-Quality Projects
For the high-profile, mega-hit titles from well-established houses like Blizzard, id, Verant, and BioWare, a different set of challenges present themselves all of them revolving around an industry and fan base with a high set of expectations for these great developers’ next titles. This means that quality must be so high that each release sets new high water marks for the industry to try to achieve.

To understand better what goes into a mega-hit game, it is a great idea to look under the hood of a mega-hit and start pulling on the hoses and unbolting the pieces and looking to see how things fit together. I call this process creating a reverse design document after the technique of reverse engineering. Chapter gives you an idea of the steps you should take when writing a reverse design document. For myself I wanted to see what went into the construction of Diablo, so I spent 27 pages of text detailing to myself how characters grew, how big the isometric tiles were, how the palette was laid out, how the inventory system worked, the user-interface, and all of the other parts that went into the production of Diablo, including the manual and box design. What I discovered astonished me: Diablo is actually a very simple game with a small set of features. This hit me like an epiphany. Now when I walk through E3 or flip through a game magazine I quickly project a mini-reverse design document in my mind for these games to get an idea of how complex they are. This led me to formulate Erik’s Axiom 13 of Game Design.

AXIOM : As the complexity of a game increases, its likelihood of commercial success decreases at a geometrical rate.

I highly encourage you to create a reverse design document for your favorite mega-hit whether it be Quake, The Sims, Total Annihilation, or another title. What you will find is that these games all have a clean, tightened feature set that is polished to a degree that their competitors have not been able to achieve. In fact, Michael Abrash decided to join id Software for many good reasons, but one of the reasons he chose to join the Quake team was because early in the project John Carmack wanted to put in a portal technology that would allow players to seamlessly jump from one Quake map to another in an extremely compelling version of action cyberspace. This feature was cut from production and in fact has yet to ship in a Quake game. This again is a reflection of the theme of concentrating on executing your features well.

But without knowing better I would have thought these very successful developers would give no thought to adding features to their projects heck, they don’t even have to be late. They could just hire teams and subteams to get these features done, right? No is the simple answer. The difference between a strong developer and a weak developer on your team is not just a linear difference in work output; it can literally be a tenfold, hundred- fold, or more difference in productivity. In fact for the networking code in Quake, John Carmack hired a programmer whose whole career was in creating networking code. For some reason this did not work out well for Quake, and the programmer moved on. In two months time John Carmack came up to speed on the issues involved in networked games and produced a solid networking layer that was only 2,000 lines long and, as usual for John Carmack, set a new standard for multiplayer Internet gaming performance.

Surprisingly, many people will attempt to add pressure to your project by asking you to hire more folks and get more done or much more commonly get it done for a specified quarter. You certainly can get useful work done by hiring crack independent contractors and extra staff, but it is not a magic bullet. You need to organize and manage this extra talent. Adding additional staff requires more administrative overhead, and there is a critical threshold of number of staff in an area on a project beyond which you get diminishing and ultimately negative returns on work, even if the people on the project are competent. This is probably due to the increasingly complex communication required between a large number of people on a project as it grows in team size.

These mega-hit developers have learned they cannot grow their teams to indefinite sizes and still produce clean, compelling hits. For this reason the features in these games are limited to roughly what their current team can produce.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Game Developing Topics