Grand Theft Auto IV: Matt's Take

It's been quite a while since anyone has posted anything here on the MISoft devblog. We've been extremely busy these past few months trying to wrap up work on Real Estate Magnate and Redemption 9mm, plus all of our design work on Eternal Equinox II and other future games, so the blog and website have taken a backseat to those things. And I don't have enough time today to write a proper article (people have been asking about the team building series, I need to get on that!). So instead, I'm going to post a quick "designer's review" of the newest game in my collection, Grand Theft Auto IV.

First and foremost, I need to tell you that no, I haven't finished the game yet. I've had a technical error with my Playstation 3 and I'm stuck until that issue is resolved. My last completed mission was in Alderney, driving powerboats with Phil. As a result, I'm not going to write a standard "review" of the game. You can read reviews like that anywhere. Instead, I'm going to critique a few points that I think are worth looking at through the focused lens of developer's scope. Chiefly, I'd like to talk about a few features I think the series desperately needs, and take a moment to congratulate Rockstar on another job well done.

Let's start with story and character development. In my humble opinion, Nikko Bellic is the most beautifully crafted video game character I've ever seen... yes, I'm definitely serious, before you ask. He's strife with personal conflict and emotional scarring, "content with contempt" I guess you could say. He has a hilarious boastful approach to most scenarios with a biting sarcasm that you rarely see video game characters pulling off. I almost think putting Nikko Bellic in Grand Theft Auto is a parameter mismatch. He's developed enough to warrant his own series I think, and knowing Rockstar's previous endeavors, there's a chance we won't see him in future games. In terms of story, they put tons of focus on the serious, gritty realism of Nikko's life, and encased his own personal tales in the most breathtaking virtual city I've ever seen. Long story short, GTA is getting more serious and detail-oriented, and it's about time.

Nikko Bellic aside, GTA4 is, quite simply, a brilliant game. Rockstar's attention to detail is astounding, and they've far surpassed anything they've done before. Every character has a unique personality and an interesting story to tell, and they aren't as rife with cliches as they've been in past iterations of the game. There's a car wash, people react to your clothing choices, you can hail cabs (with fun internal backseat views), go on dates, etc. To stir up some controversy, you can... *ahem*... "see" prostitutes performing their services for you. The game is filled with a billion little details like that that are vast improvements over previous entries into the franchise. But that's not to say there aren't issues. It isn't as massive as San Andreas and doesn't boast the same features. For instance, you can't modify cars like you could previously, and you still can't choose a car color at the pay n' spray. You can't alter your physical appearance besides a very limited selection of clothing options. There are small details like that that the team at Rockstar overlooked, a list of issues caused by their apparent attempt to make it more aesthetically pleasing than content-heavy.

Matt's Suggestions

Here are a few ideas that I think would make the next GTA fantastic:

• Keep Nikko Bellic. Send him to Vice City for some reason. I'd love to see this character continued into future games and further progressed. I didn't like the gimmicky retro stuff in Vice City or San Andreas. Great soundtracks, bad hair. Playing GTA4, I've been left with the sour taste in my mouth that Rockstar might try taking the franchise into the 1970's in the next game, and as much as I love glam rock and jokes about the Bay City Rollers, I think sending GTA into the 1970's will be an absolutely horrible mistake. You've created a masterpiece Character in Nikko Bellic, and you should think twice, or three or fifty times, before deciding to ditch him!
• More UI. If I pull into a car painting establishment, and they paint my Ferrari lime green, someone is going to end up hurt and/ or killed. Adding a Pay n' Spray UI that lets the player pick a color or color combination out of a box would help reduce the number of cars I drive off of cliffs, making the world safer and helping the virtual environment, too. This would be handy in clothing options as well. Let me see boxes with my various articles of clothing in each little box, and let me pick what I'll wear that way. And cooler still, let me save my "dresser" and retain set outfits that I can throw on in the future.
• Showers. I imagine I'm pretty smelly after running a quarter of a mile, getting into a gunfight, and leaping into the Liberty City version of the Hudson River. Characters could have a "stink-o-meter," with various alterations to character interactions as a result. Wash crotch thoroughly before date. Rinse and repeat as desired.
• Bring Back Mod Shops! I'm thinking Rockstar may already be heading this way, but I noticed a few broken down Vigero cars that barely ran. It'd be cool if you could take these crappy vehicles to a shop and fix them up. Also, the ability to mod cars with custom parts and paint jobs. Maybe some performance enhancements, too. I miss that feature from San Andreas.
• Dude, where the **** is my car? Something that has ALWAYS annoyed the CRAP out of me in GTA. So I have this Sabre GT, right? I got it painted just the way I like it, I've used it for three missions now. But I do a mission where I need to drive some other vehicle, and when I return, my car is gone! Do I load from my last save and lose my progress just to park my car before the mission? Or do I bite the bullet and bid farewell to my awesome car? I think the game should track the last two or three vehicles the player has driven, so they can return to pick up the vehicle in the future. Or better yet, do away with parking zones and garages, and allow the player to "lock the doors," saving any vehicle anywhere you want it saved. This way, my Patriot will still be parked where I left it before I started a mission, and I can go offroading/ mountain climbing when the mission is done. I take great pride and afford great care in my GTA car collections, and it's a shame that I lose some of my favorites to certain missions. And think about how fun it will be to get a parking ticket or a boot strapped to your wheel because you parked in a handicapped spot or in front of a fire hydrant! Details... I'm all about the minute details.
• Fueling. Cars should eventually run out of fuel. I see gas stations all over the place, but I can't fuel up my vehicles. It's a great way to balance the player economy and can add a number of plot twists to missions, races, and outrunning the fuzz.
• Connect Cities. I'm not sure what information is installed, but it would be neat if the player had to travel to an old city for a few missions before returning to the newest city, sort of like the Libery City mission in San Andreas. How cool would it be to fly from the San Fierro airport to Liberty City, drive around on a few missions, then fly back? And in the same style of San Andreas, perhaps all of the areas could be connected with a big fat land mass between them all. I don't mind driving down a highway in a game for three hours... I spent ungodly amounts of time in San Andreas driving the highway system just to see if it would get boring, and it never did. For people who don't like doing that, they can take a train or fly a plane in a fraction of the time, or skip it altogether as you can skip cab and train rides in GTA4.
• GTA MMO? I won't go into graphic detail, but if you decide to connect all of the cities, an MMO would be outrageously killer. You could create a gang ("guild"), engage in zone wars, complete missions, etc. Everyone in the gang could have a t-shirt or something. If you're looking to find a World of Warcraft killer, you don't need to look further than a GTA MMO. WoW has decent number, but compared to some "regular," non-MMO games, like GTA, WoW is... well... nothing, sales-wise.

Anyway, those are a few of my ideas to make the GTA franchise better. If people at Rockstar find this blog somehow and decide to invest some thought into my afforementioned suggestions, I'd really appreciate an email. Maybe a Rockstar T-shirt and a copy of the next game for free. And money. Definitely some money. I like money.

Chapter IV - Odds & Ends (Building an indie dev team)

Chapter I - Getting Started
Chapter II - Sizing Up
Chapter III - Structuring the Team

Chapter IV Preamble
This fourth chapter in the series will discuss a few key points that need sorting prior to gathering people for development. Now that we have a good understanding of how small or large our team needs to be, and what positions the team will have, we need to discuss what these team members will actually be doing, and how to establish ourselves so that potential developers would be interesting in coming onto the project.

Soil, seeds, and water...
Let's start with one of the most over-used analogs in history. If making a game were anything like planting a flower, we'd have the pot at this point, but nothing else. Let's start filling that pot, shall we? First, we'll need soil... in this case, a strong game design. You should never start even the simplest game without some form of conceptual design on paper. I might be wrong, but I'd be willing to bet that the guys who made Pong had a piece of paper somewhere that said "two blocks knock a ball around," or something to that effect. Then we'd need the seed for our flower: some groundwork laid out for our new title, so that people coming into the project have something to work from, and aren't doing everything from scratch. Last but not least, we'd add the water, giving us a strong base for our flower/ development team to grow. In other words, expect to get your hands dirty in this chapter as we get into serious work!

Elements of a good game design
The theories and practices of creating a game design simply can't be summed up easily in a paragraph or two... I'd have to write a full book to really get into game design theory. So instead, we'll just discuss some of the most basic and practical elements of a game design document. Some projects (like our game Cheney Hunter) are remarkably simple in design, and only require a few sentences of writing to establish the concept. But larger, more complicated games (like Eternal Equinox or Real Estate Magnate) need to be explained to your team in great detail so that every facet of the project is understood before work begins. Regardless of the project's size, most designs have common elements, so let's discuss a few of those here. Please note that this is by no means a complete tutorial on game design... when I finish these tutorials and make future edits, I'll add some links to websites that offer advice and whatnot on the subject.

So what does your design need? Your future teammates will most likely require a good understanding of the following:

• Story & Setting: What is the player-character doing, why are they doing it, and where is this action taking place?
• Characters: Who is/ are the lead protagonist(s) and antagonist(s)? Are there other characters in the game who will play pivotal or even minor roles, and if so, who are they? Try to bring these characters to life in your game's design, so that artists know precisely what they should look like, and programmers know what sort of characteristics they should be implementing for them.
• Story Progression: It's always good to provide a summary of what is happening in each level, provided your game is story-driven. Where is the player starting, what will they do in the level, and where will they end up at the end of it? And what impact(s) will these actions have on the story and/ or the game's timeline?
• Statistics: Almost every game has some for of statistics. Health, energy, ammunition, etc. need to be clearly defined and explained. For instance, how many health bars would be depleted if the character is shot with a bullet? How much energy does a character expend when performing laborous actions such as running, jumping, swimming, etc.?
• Inventory: What weapons, vehicles, and items can the player use, and what are the properties of these items? If designing a pistol, you don't want to simply say "9mm Pistol." You'll want to provide artists and programmers with a vivid description of precisely what you expect of the item. How many rounds of ammunition can it hold? What is the weapon's range? How accurate is the weapon? What does it look like? And if the game has a great deal of content, it might be easier on everyone involved if you store this numerical information in databases (such as Excel or MS Works Database) for quick reference.

There's obviously quite a bit more to a game's design, and it is strongly recommended that you take some time to learn more on this vital subject before diving head-first into a new project. But for now, understand that you shouldn't start a new project without something on paper, regardless of how small or simple that project might be. This will keep your team on the right track in terms of what they'll be developing and how they'll go about implementing features. It should never be assumed that any member of your team is on the exact same wavelength as yourself... well, unless of course you've mastered the art of human cloning.

Planting the seed through base development work

As stated earlier in this tutorial, it's absolutely crucial that you have something worth showing to potential team members. You might be a terrible programmer or the world's worst artist, but people looking to join your team will want to know that you'll be contributing just as much as they will be. Getting some base development completed serves multiple ends... it establishes the project as a serious one, it shows potential staff that they're coming onto a project with some groundwork laid out, and it gives your developers a groundwork to build on.

You might be thinking, "well, I'm a horrible artist!" Well, that's what MS Paint is for. You don't have to be Pablo Picasso or Vincent Van Gogh to establish some visuals in the game. Even if you illustrate action with stick figures in a 2D game or low-quality freeware models you pulled off of the internet for a 3D game, you'll be giving your future team valuable information and a strong base that they'll need for development.

This of course leaves us with a valid question: how much work is "enough?" This depends on a number of factors: the size and scale of the project, the amount of creative input you're expecting from team members, and the very design elements the game projects, amongst others. There's no magical number that I could say here to explain how much needs to be finished. But you need to have enough actual gameplay laid out (in at least semi-working order) that potential team members can gain benefits from exploring what you've finished. Don't whip up a frontend and expect people to join the team... have something of the gameplay itself completed. Say, a level or two in an FPS game, or the introductory play area of an RPG. Remember the key here: it doesn't have to be stunning or beautiful, it just needs to be functional.

Straight from the tap: Establishing the grounds for building the team

When you have a good design document to outline the full project, and some groundwork laid out that establishes the project to some degree, we can finally start prepping for finding new team members. In chapter five we're going to start discussing the actual act of finding people, but for now, let's pave a road so that we can actually find those people.

First, let's discuss the website. You're going to need a web address where potential teammates can view the project, learn about what will be required of them, and get to know you a little so they know who they'll be working with. You don't need an epic website just yet... just a page or two will be needed at this point. You should show screenshots and perhaps some video clips of the game, particularly the gameplay itself. You should explain a bit about yourself, and don't be afraid to mention your realistic goals and ambitions, too... people looking at joining your team will want to know what you're "going for" with building this team, and where you're hoping the team ends up.

It should also be mentioned that the quality of your website is pretty important. You'll most likely be using this website after you've finished your game, for promotional and community purposes, so it might be best to consider establishing at least the ground work for a proper website now. Free-hosted websites offer very little bandwidth and storage, have characteristically long URLs (web addresses), and are usually filled with advertisements that may or may not relate to game development, or even games in general. You should look into paying for proper hosting as opposed to using a free host and their (often limited) web design tools. If you're anything like me and you don't know a single thing about web design, you can look into a free and open-source drag-and-drop web editor called Nvu. It works much in the same fashion as Microsoft Word (only slightly more complicated), and it was used to make MINet 1.x prior to Adam and Rami building Minet 2.0. As for hosts, there are a number of low-cost webhosts out there in internet land to choose from. I recommend you take a look at A Plus and 1&1 Hosting, both are very great services with low-cost, affordable hosting solutions and fantastic customer support.

Next, let's talk about online communities. You'll find online communites such as The Game Creators and Gamedev.net to be vital in your future development endeavors. You might end up finding team members through websites like these, and you'll also have a treasure trove of valuable information, honest critical reception of concepts and game development work, and an online community of people who can help you with various problems you encounter down the line. In my own personal experience, I've found the latter of these communities to be, well, not so helpful. Perhaps that's my own bias from supporting TGC and using their projects for such a long time, but the Gamedev.net community isn't quite as open and welcoming as the TGC community. Again, that's just my own personal experience. At any rate, there are a number of communities such as this that you can join for free and become an active member of. They've proven indispensable to MISoft Studios over the years, particularly TGC, and in future chapters you'll find a growing need to be a part of these groups. So swing by, participate in a few discussions, and start getting involved in the online indie game dev community, you'll find this to be a wise move as we get into the next chapter.

Bringing things to "light"

We should at this point have a decent game design hammered out, some groundwork completed on the game itself, a website to showcase what we're doing, and a membership in at least one or two game development communities online. To return to that terribly overused analog from before, we now have soil in our pot, a seed in the soil, and water on the whole thing. In the next chapter, we'll give this plant its final ingredient, some metaphorical sunlight, and watch the flower start to grow and blossom into a functional game development team... "well rooted" with a thoroughly-planned and started game title. And with any luck, the next chapter will contain fewer bad puns than this one did as well!

WOW! What a poorly designed game!

I'm currently battling a tsunami of sick, probably the worst flu I've had in years. But in the spirit of staying productive, I've decided to write a sort of postmortem review of one of the world's most famous and widely played online games. But rather than commenting on its strong points and basting the already-acclaimed title in praise, I'm going to do something that 90% of my friends in the game industry would love to do... I'm going to tell you precisely why the game is an icon of poor game design.

The game in question is the self-proclaimed "most popular MMO ever," World of Warcraft. The title has recieved glowing, rave reviews across the board, all of these lending to the 9+ million players that Blizzard Entertainment, a division of Vivendi and the primary namesake in the Vivendi/ Activision merger now known as Activision Blizzard, boasts about on a regular basis. And for what it's worth, the game certainly does have its qualities, all of which make it addictive and quite fun. But to me, a gamer of 20+ years and a game designer since I first toyed with BASICA as a child, the problems certainly outweigh the positives in this ever popular MMORPG. Because I'm sick with the flu, and because listing every single issue with the game would possibly cause bandwidth issues when loading this page, I'm going to keep this article relatively short and sweet, with a concise list of my biggest problems with the game. Why post this article? It may seem I'm trying to drive customers away from Blizzard, but that's simply not the case. Really, my hope is that somehow, probably through the power of Google, a member of Blizzard's design staff might stumble across this article, read it, and say "ohh, THAT'S why we've been losing customers!"

Policies for Players = Profits!

Let's say we're playing Battlefield 2. The server's rules clearly state that vehicle stealing is illegal, but someone takes my Humvee anyway. I can report that player to the server's host or administrator, and the player will be kicked, banned, or otherwise punished. And on some servers with the same rule and same event, I can shoot that player in the face and take my vehicle back. Either way, that player has learned the valuable lesson that they should obey the rules at all times. The ability to TK others has, over the years, resulted in an unspoken code amongst gamers. There are laws that exist, not on paper or in an EULA, but in the mindset of players around the world. Some choose to violate this code of conduct, but they're almost always met with swift and strict penalty from both players and administrators. Such rules protect players from a variety of ill behavior... team killing, friendly fire, vehicle/ friendly injuring, theft, etc. If you're familiar with this code of gamer chivalry, then I have a word of advice for you: Don't play World of Warcraft!

Blizzard's policies, as well as the game's design, revolve entirely around two things and two things only: making the game addictive, and maximizing the company's profits. That's it. When it comes to interaction between players, there are very few policies that protect players from the behavior of their peers. As a matter of fact, harassment is apparently the only issue that Blizzard's "Game Masters" seem to be willing to help you with. Players can steal, "ninja-loot," or anything else that they want to do, so long as it isn't considered harassment. For instance, say someone offers to pay you for a service. They want to be escorted through one of the game's dungeons, and they offer you in-game money to do this for them. You go out of your way to escort the player through the dungeon, but when it's all over, they decide not to pay you. If you report this issue to Blizzard, they won't do anything about it. Let's look at a different scenario: you own or are a member of a guild. A guild member joins, and seems pretty cool. He does everything he needs to do in order to earn a promotion, so you give him one. But then, he liquidates the guild's bank, stealing all of the items, quitting the guild, and selling them all off. Blizzard's stance? Tough break, kid! These are examples of things that have happened either to me or one of my friends in the past while playing World of Warcraft, and in all of these cases, Blizzard's Game Masters have refused to assist the victims.

The bottom line: Blizzard has the worst customer service I've ever seen from a game company, and worse still, every single one of their policies exists to benefit the company itself rather than the game's players. As soon as people realize how severely twisted Blizzard's policies are, they usually cancel their subscriptions and quit playing the game. That, or they're so addicted to the game that they choose to simply "deal with it." I'm proud to be a part of a game studio that doesn't treat it's customers like that... maybe the folks at Blizzard should re-consider their policies and do more to protect players from other players, beyond their simple harassment rules.

Grinding Formula

There must be a toxic waste facility in Azeroth somewhere, as there seems to be some tragic genetic mutations occuring in this game. Eight out of every ten monsters I kill are missing vital organs or extremities that are needed for a player to complete quests! And yes, I've actually calculated that mathematically, based on performing the same exact quest with three different characters. Simply put, World of Warcraft is designed in such a way that the player is forced into grinding whether they perform quests or not.

Grinding, for those of you who are unfamiliar with MMORPG titles, is a process wherein the player kills large numbers of monsters/ enemies to earn experience points. Some people rather enjoy the act of grinding, and so these quests suit them just fine. But some people, myself included, cannot stand the boredom and monotony of repeatedly slaughtering the same creatures over and over again. And heaven help you if someone else is performing that same quest in your area... monsters are of course limited, so if all of the monsters of that type are killed, you'll find yourself waiting around for them to respawn. There are some quests that don't require you to grind, but sooner or later you are forced into doing this in order to level, and whenever an RPG forces you to grind, it's a show of laziness on the part of the game's designers, plain and simple.

Why am I killing these Wolves Again?

It's no big secret that my favorite quality of a game's design is story, and the delivery of said story. Being lead developer of a trilogy of text adventures is probably a testament to that. And if you're willing to look for it, World of Warcraft does certainly have a story. But in an experiement, I asked thirty players to explain the overall objective of the game to me. Every single person shared an almost identical response: Get awesome gear. Now go out and ask Eternal Equinox fans what their objective is, and they'll tell you about the Hoto and how you need to find it, "or else." Ask a fan of the game Fallout what the objective is, and they'll tell you about Vault 13 and how it's your mission to save your people by finding the sacred water chip.

In World of Warcraft, there is absolutely no emphasis on knowing or understanding the story. I haven't researched this yet, but I'll bet just about anything that 95 out of 100 players can't tell you specifically why the Horde and the Alliance are at war. There are trace amounts of story, with lesser hints of continuity throughout, but it's far too easy to entirely skip the story and not care why you're gathering 5 goretusk livers for such-n-such, or how that effects the world at large.

Persistently non-persistent

Like most MMO games, World of Warcraft is allegedly a "persistent world." Persistent worlds are, in theory anyway, worlds that gradually change over time based on the effects of player-inspired events. In others words, if John Doe's farm burns to the ground, it will remain burned to the ground until/ unless it's rebuilt. But in World of Warcraft, they didn't even attempt to be clever at making the world feel persistent... they toss that phrase around, but it doesn't actually apply to World of Warcraft in any way.

Let's say, for instance, the Horde orchestrates a massive raid on the city of Ironforge. Let's say they kill the King and all of the guards during their raid. Shouldn't the city of Ironforge then fall under Horde control, and the Alliance be forced to move elsewhere? Well, it doesn't... the King dies, then he re-spawns, and that's the end of that. If Blizzard wishes to continue boasting about how cool the game's persistent world is, shouldn't something about that world be persistent? From what I can tell, nothing, and I do quite literally mean nothing, is.

A Horse! A Horse! My Kingdom for fighting from a horse!

It seems to be a common trend on MMORPG games: You get an often over-priced horse ("Mount") to ride, but then soon learn that you can't actually fight enemies while mounted. Why don't MMO makers at least try to break the mold here... allow fighting from a mounted position, with statistical advantages of course, and allow players to outfit their steeds with armor and stat-improving gear. And why can't someone hop in my saddle and hitch a ride with me? Why can't I tow a wagon, or ride in a chariot, or get a stage coach and fill it with friends and loot? I still don't understand why us indie developers need to come up with all of the good ideas...

Another thing... I shouldn't have to be level 40 to ride a horse. When I was four years old... yes, four years old, a young child with a bedtime... my Aunt Nancy took me to ride a pony. Was I a level 40 child? HECK NO! I was still afraid of the monsters under my bed and was still convinced the tooth fairy was dropping cash under my pillow every time I fell off the trampoline and lost a tooth... hardly capable of slaying dragons or saving princesses. So someone PLEASE explain to me why you have to be a certain level to ride a horse... I mean really, with the right training can't anyone ride a horse? And another thing still, it shouldn't cost so much to learn how to ride a horse, either. It costs about the real-world equivilent of the price of a brand new Sports Car just to be trained how to ride a horse in World of Warcraft, and the faster horse costs three or four times that amount. Which brings me to my next point...

Cash-Rules-Everything-Around-Me... the Cream of WOW's Economy

Hand's down and without contest, World of Warcraft has by far the worst in-game economy I've ever seen. I mean literally, of every game I've ever played in my entire life, this game's economy is the most tragically, painfully flawed. There is absolutely no sensible, intellectually-enforced methodology deployed to balance the game's economy and keep things fair.

If you have an account for the game, here's a practical experiment for you to try. Go into the auction house and look up the price of 20x copper bar, 20x medium leather, and 1x goldthorn. Write down the lowest and highest prices of each of these items. Check again the next day, and the next day, and so on for a full week. Did the prices of these items stay reasonably close to each other? Or were they radically different every single day? I'm sure some servers have stronger economies than others... the server I play on, Antonidas, however, has an absolutely autrocious economy.

Some practical ways to level out the economy... ditch the "BOP" gear (Binds On Pickup). Allow players to auction or trade all of the gear they get or make. Did you know that blacksmiths in World of Warcraft can't trade or auction off gear they make, gear learned from weaponsmith or blacksmith trainers? And a number of items can't be used by players unless they acquire certain professions. Limiting item use in these ways dramtically hurts the game's economy. And another thing, why is gambling against the rules? I can strip off all my clothes and dance on a water fountain, and I can slaughter hundreds of thousands of people, and I can get drunk in the game, with blurred vision and slurred speech... but I can't place bets on people fighting in the Gurubashi Arena or the races out at the salt flats? It isn't enough to let players make money, you need to monitor carefully how they spend that money as well, else the economy won't have a chance to stabilize itself.

In Conclusion...

I could go on and on about the problems in World of Warcraft, but my sneezing and sniffling is now interupting my train of thought. I did however touch on most of the primary problems I have with the game, issues that Blizzard would be wise to address. Because I've spoken with no less than three people who have agreed with each and every one of these issues, and included them in this article because at the end of the day, these are some of the issues I most commonly hear people complaining about. I can't say whether or not MISoft Studios will ever make an MMO title... but I can assure you that if we do, we'll put more thought and energy into solving problems like this long before we ever release the game!

MINet 2.0

Well, I don't see that anyone else here posted this yet, but MISoft Studios just last weekend officially announced the release of their new website! It has a much more professional appearance and plenty of room to expand. The forum now matches the actual site and we have plans to eventually merge it into the actual website.

Check out the new MINet 2.0 here!


You probably noticed the new mascot on the top left of the screen. Well, that little puppy doesn't have a name. That's our fans' job! We are holding a contest at our forums. Post in the contest thread by March 1st to be eligible.

PRIZES:

Runners-up will receive the choice of 1 of 3 games - Eternal Equinox, Real Estate Magnate, or Capital Punishment. The one who suggests the best name and wins the grand prize will receive a FREE copy of EVERY game we release in 2008! How cool is that? Well it gets better. Have you ever wanted to be in a video game? Come on, of course you have! Well, you may get that chance. The grand prize winners will also get to be a secret character in our upcoming game Capital Punishment!

Click here to go to the contest thread.


Well, that's all for now, hope you all like the new site and hope to see your name suggestions posted at the forum!

- Adam & the MISoft Studios team

Chapter III - Structuring the Team (Building an indie dev team)

Chapter I - Getting Started Chapter II - Sizing Up

Chapter III Preamble
The third chapter in this series of tutorials on building and independent game development team will focus on the structure of your new team, and the various titles you'll need to assign. We'll define the roles of your team members in depth, and discuss why each member is vital to the success of the team or company.

It's in the Name
Before we go about filling the rosters of our team, let's figure out what positions we're going to need. By now, you have a good idea of how many people you're going to need for the game's development... but what titles do we assign each new team member when they come into the group? To some, this is the easiest step and can be pounded out in a few minutes. But to others, this is a rather confusing aspect of team development, especially with redundant or meaningless job titles seeming obviously needed but not immediately practical. We'll break down each job title here by the group or classification of the job itself. It's a pretty short list, but you won't need one or more people to fill all of these roles.

Some teams only need a few positions, and some need positions not named here. But if it isn't named here, how are you to know that your team definitely needs someone to fill the role? Remember the golden rule of practicality: if the person won't be working at least half as much as the rest of your team, then their job is just as easily done by you or another member of the team. For instance, MISoft Studios only recently developed a marketing team, consisting of experienced people who know their trade. We could have easily assigned positions to our friends, calling them "Marketing Agents," asking them to write our press releases and handle our other public relations affairs, but would they have been good at it? Probably not... instead, we have an experienced team lead by a Marketing Director who knows what she's doing and why she's doing it, with years of experience and education to back her plays. And before that, we didn't hand out titles to marketing people because we were doing all of the PR ourselves.

Also, remember: until you're legally registered in your city, state, and/ or country as a tax-paying business, you're just a group of friends making games. MISoft Studios, as of the time this was written, has not yet legally registered as a company. Technically, we're an organization, but regardless of how professional we are, we can't call ourselves a proper company just yet. We do plan to become a company this year, and as such we've started re-structuring our team, formatting our operations, etc. But prior to this planned move, the company was very different and most of our managerial positions were more loosely defined. My entire point here is this: don't name a finance manager until you have finances to manage. Don't call up your friends declaring them as marketing representatives or sales people until you have a product to advertise and sell. Don't tell your significant other that you plan on them being your secretary or security chief. For now, you should focus all of your energy on game development positions, and save those other positions for the future.

So now, without further adieu, let's start naming job titles and what these people will be responsible for creating. I've broken everyone up into distinct departments for simpler navigation of the list, but you won't necessarily need departments just yet, not until you have multiple people in each category.

Executive
Executive Producer: This position isn't really necessary beyond the credits of your game, and even then, you don't really need it. An executive producer is someone who funded the specific project... if they paid for development tools or bought you equipment, and you want to return the favor by crediting them in your game, this is a nice gesture of goodwill, and it spruces up the credits of your game with a more professional appearance. But keep in mind that this is a completely unneeded position on your team, and you rightly can't count an executive producer as an official team member. The Executive Producers job is, quite frankly, to give you money. They're the project's investor(s) and nothing more. A quick note... if the project doesn't absolutely need money to operate, don't try looking for it. And if this is your first project, expect to fund the entire game yourself!

Producer: Again, this title isn't as important as it sounds... not on an indie development team, anyway. A producer is someone who helps organize people, funds, and equipment. This is another title that adds some class to the final credits of your game, but did the person you're naming really do anything? For instance, say you have a friend who has taken a serious interest in your team. They got you in contact with a friend of theirs whose willing to help fund the project(s), they've networked to find you development team members, and helped you sort the legal paperwork, like contracts and whatnot. This person could be defined as a producer... else, ignore this title as the person filling the role isn't genuinely helping the games get finished any faster. The Producer's job is to fulfill the needs of the development team with resources and manpower, and help secure finances if they're needed.

Director: This is the only executive position you'll likely need at this point, if this is your first game especially. The director is the individual who oversees, or directs, the team, and ensures that their work complies with the vision of the project's design and conceptual planning. You're more than likely going to assume the role of director if the project is yours intellectually, but if someone other than you designed the game, you need to declare them as the director, as they most definitely understand the concept of the game more than you do. It sounds like a flashy title, and you might want to horde it for yourself, but remember that the game's concept is inside the head of the director, not you, and regardless of how familiar you are with the story, you don't know it as well as the game's designer. The director's duties include managing the creative direction of the project, supervising the team in their development, and ensuring the project is completed as quickly and efficiently as quality permits. The director should fully understand the game's conceptual vision and intellectual design, and should have some degree of management experience. They should also understand at least the basics of development in each artistic category named below.

Creative
Lead Designer (or simply "Designer"): The Lead Designer is absolutely crucial to any project. After all, without a game design, what are you going to make? If your project has been designed by more than one person, then the person who came up with the original concept, and/ or the person who contributed the most to the project's design, should be named the Lead Designer. If only person came up with the concept and designed the game, just declare them as the Designer. The Lead Designer's job is to design the project from the ground up, including the story, setting, characters, and lists of weapons, vehicles, and other items. They need to have management experience and have to be extremely creative, preferably with an understanding of at least basic psychology, mathematics, and creative writing. They need a firm comprehension of various development aspects as well... the game they design needs to be technologically possible in terms of developing it, with the resources currently available to the team.

Designer: If the project is large, you might need more than one designer. Designers assume the same creative responsibilities, under the supervision of the lead designer. They might be tasked with designing weapons, vehicles, and other objects. Perhaps their job is to write the voice acting script, or design the plans for animations. In a nutshell, a designer assumes some of the lead designer's responsibilities on the creative end to help make the game's design more fluid and consistent, adding depth and personal flare.

Programming
Lead Programmer: The lead programmer's job is to manage the other programmers in their work, ensuring that the game is being developed as smoothly and efficiently as possible. They often design the game's engine themselves, and assign the programmers to specific functions and/ or subroutines inside that engine. They also play a fundamental role in the creation of development tools and other source-driven assets.

Programmer: Programmers, well, program. They write the source code that powers the game, usually under the direction of the lead programmer. Often programmers are assigned specific tasks in the game's development... for instance, you might have one programmer writing all of the source code for the 3D pipeline, another doing interface and input commands, another doing the frontend and multiplayer programming, etc. Make sure the programmers you find can work with the lanaguage and tools that the lead programmer wants to use, and that the entire team is knows exactly what their source code needs to achieve.

Tools Programmer/ Tools Developer: Sometimes, the creation of certain software tools can help speed production along. Tools are special applications that perform very specific tasks. If you're working in DarkBASIC Professional, you might need a tools programmer to develop a special multiplayer DLL, or maybe you need a special conversion tool that turns one file type into another.

Art
Art Director: The art director's role is to manage the 2D and 3D artists, often developing the visual design of the project themselves. Your game needs to maintain solid, consistent visual themes from beginning to end. You don't want photorealistic vehicles roaming around a cell-shaded world, with a Victorian home popping up in a Gothic Deco cityscape, right? Well, your art director's job is to make sure nothing like that happens. They'll also work closely with your programmers to make sure the various elements of visual systems are implemented properly, and that the 2D or 3D pipeline is as efficient as possible.

2D Artist: If you're making a 2D game, like a classic Nintendo title or a casual Flash or Shockwave game like Bejeweled or Diner Dash, you'll need 2D artists to create sprites and levels. You'll need to research the development tools you're using, especially the file formats supported by the programming language and environment, to ensure the artist is capable of working in the right formats.

3D Modeler: If you're making a 3D game, you'll need 3D modelers to create the models that fill your virtual world. A model is basically a "wireframe," or "mesh," of the character or object. You'll need to research the development tools you're using, especially the file formats supported by the programming language and environment, to ensure the artist is capable of working in the right formats. You'll also want to make sure the artist can work with as few polygons as possible, to maximize the playability of the game and reduce load times. If you aren't sure what polygons are or why having as few as possible is necessary, talk to a 3D artist with game development experience, or a programmer with 3D programming experience. Try to find 3D modelers with experience in UV mapping... again, consult a 3D artist for details.

Texture Artist: If you're making a 3D game, you'll need texture artists to make the 2D "skins" that are placed on top of (and maybe inside of) 3D models. You'll find that most 3D modelers can't do this themselves... if you can find a modeler who can also texture, you should consider them an extremely talented and valuable member of your team!

Level Designer: It sounds like this title should be associated with the creative department, and in some ways it should be, but I'm classifying the level designer with artists because in indie game development, the level designer equally belongs to both departments. The level designer lays out the actual levels, or maps, that the game consists of. They work in specialized 3D modeling tools, often called environment editors or landscaping tools, designed exclusively for level design. Such level modeling tools include Cartography Shop, 3D World Studio, and Bryce. Certain game engines, like FPS Creator, have map editors built into their work environments for easier and more efficient game development.

Gaffer: A gaffer's job is to fill the game's levels with light. Usually the level designer performs this job themselves, but if they confess that lighting isn't their strong suit, you might want to find someone who can make sure the lighting in the game is laid out well.

Audio
Audio Director: The audio director is responsible for managing everyone on the team working in aural media. Like the art director, the audio director needs to ensure that the music, sound effects, voice acting, and other aspects of audio are developed efficiently, remain true to the creative conceptual vision of the designers, and share similar traits in style.

Musical Score Composer: A fancy title for musician, the musical score composer's job is to write the music that the player hears while venturing through the game world. From the title theme of the opening credits, to the action-packed suspense music during intense fire-fights, to the calming music played during the end credits, the musical score needs to help the player achieve suspension of disbelief by immersing them deeper into the game than mere visuals can provide. You might need more than one composer to create the number of songs you hope to use.

Foley Artist: Foley artists create sound effects for games. From ambient noise of water trickling from a drainage pipe in an alleyway, to the loud bright blast of semi-automatic gunfire, the foley artist is tasked with creating a 3D world filled with sound. The foley artist needs to work very closely with the level designer to ensure that every floor board creaks properly, and that every rat in every corner squeaks when they should. They should also work closely with 2D artists or 3D modelers to help develop sound effects related to weapons and items.

Audio Engineer: Sometimes you'll need tracks containing a mix of multiple audio tracks. Say you're making an FMV (full-motion video)... a "mini-movie" in your game that shows the hero doing something that the player can't exclusively control. The audio engineer will mix together sound effects, music, and voice acting tracks to create a single audio track for use in that video. The audio engineer is also tasked with taking the audio tracks created by the rest of the audio team and mixing them down so that their volumes match and sound as professional and crisp as possible. If you're working with voice actors, the audio engineer can oversee the recording of their vocal tracks. You might consider making your audio director the engineer to save time, money, and resources.

Moving Forward
Your project might need more people, but you won't need them just yet. Everyone you could possibly need for game development is listed above. Later in the tutorial, we'll discuss finding testers, voice actors, and more. For now though, we should come away from this chapter with a strong understanding of the various roles that your team members are going to fill on the development side. In the next chapter, we're going to close out the "odds and ends" of developing your team, so we can move on to finding people for your "staff." We'll talk about making a website, preparing design documents, and more. You should go over the lessons we learned in Chapter II and assign each member of the team with a title now, before we start looking for people to actually fill these positions.

NYS Game Dev Coalition

I was recently talking with a friend who lives in Rochester, NY. He owns another indie development studio, and we briefly discussed the notion of forming a coalition of game dev studios in New York State, including both indie and mainstream companies. The idea had been tossed around with a few of my other friends in the past, and this recent conversation revitalized the concept.

It's certainly something worth discussing, or so I think anyway. New York State has been a battleground in the game industry for a pretty long time. Senators Joe Leiberman and Hillary Clinton, both representing New York State, have made stands against the game industry, particularly violent games like Grand Theft Auto. There's a number of legislative actions that such a coalition would benefit from knowing more about. There are other political, social, and economic issues that could be discussed as well, such as taxes in our state, employment rates, etc.

The benefits of such an organization could be pretty substantial. We could keep developers at every level informed about things happening in our state that might effect us. We could petition certain legislation that might have negative or even detrimental effects on our industry. And we could show senators like Clinton and Lieberman that the game industry isn't as evil as they make us out to be. We might even be able to share resources... say, a job area on a website where potential employees can find companies worth working for. Maybe we could group up to convince local businesses to carry indie games made locally in New York State, increasing everyone's profitability across the board. And the concept could be (and should be) rooted in the belief that New York State doesn't start and/ or end with New York City... there's a whole state filled with game development studios that could benefit from this organization.

The only problem with this organization is that I don't have enough free time to start it. But if such an organization were to exist or get formed, I'd most certainly take part in it to the fullest extent of my ability, as would MISoft Studios. On paper, this is a brilliant concept, and it might just kick off similar organizations in other states, too. It doesn't have to be a New York-centric idea. The only question that remains: would mainstream studios get involved, or do they think they're so bulletproof that they don't need an organization like this on their side?

Chapter II - Sizing Up (Building an indie dev team)

Chapter I - Getting Started

Chapter II Preamble
This chapter will discuss figuring out the size of the team you're about to start building. We'll also figure out a "chain of command" at this earliest stage of organizing the team, so we can simplify team management in the future.

Does size matter?
Real quick, let's step away from the computer and break out a game's box or case. Open it up and take out the manual. Chances are there's a section inside the booklet that lists a number of people involved in the game's development, and more often than not it also lists executive positions and post-production staff as well. You're probably looking at this list and thinking "yeesh, this is far more involved than I thought!" Well, if you're thinking that, you're partly right, and partly wrong.

As independent game developers, we work at a different pace and with entirely different development tools than the mainstream game industry. They use Max, we use Anim8or or Blender. They have marketing teams, whereas we rely on online communities for publicity. We're talking about a budgeting difference of millions or even tens of millions of dollars. As indie developers, it's our job to make the best games possible, for as little money as possible, and with the fewest personnel as possible. Sounds daunting, right? Well, it's going to be. But daunting doesn't translate to impossible. Size doesn't matter for indie dev teams. You'll quickly learn that, due to our limitations financially, we often find ourselves making a lot with a little. Some members of your team will end up performing multiple roles, and those who are defined with managerial positions will perform about 150% more work than the rest of your team. And the bad news is, you'll end up doing about 300% more yourself. A lot of this work is administrative... it takes a lot of effort to keep a team together, and a considerable amount of effort will go into keeping everyone productive and enthusiastic.

The size of the boat vs. the motion of the ocean
Now it's time to start answering the fundamental question presented this chapter: how large will the team need to be, and how much work will each team member need to do? This depends on a number of factors...

• The Assets: The word "Assets" is used quite commonly in game development, from indie studios to mainstream corporations. It refers to all of the various parts of a game which, when assembled, create the game itself. This includes media (music, sound effects, 2D and 3D art, etc.), source code, even certain development tools, like engines and custom made, purpose-driven tools. You'll need to make a list of every conceivable asset the game will need. Every 3D model, every texture, every image used in the HUD, every sound effect and song. We'll get into assets a little later in this chapter.
• The Deadline: When are you hoping to have the game released by? You'll need to have at least a loose concept of when the game should be finished; a date that your entire team can drive at. This needs to be realistic. You can't expect even a massive team to finish a game in one or two months. Knowing when the game should be finished can help define how many people you'll need to find.
• The Development Tools: What tools are you planning on using to create the game? How long does it take to develop assets using these tools? If you're a programmer, you probably won't understand the differences between Maya, Max, and Blender. Likewise, a 3D artist more than likely couldn't tell you the pros and cons of developing in DarkBASIC Professional versus XNA or a C++ environment. You'll want to take your list of assets to someone who knows about these aspects of development... visit one of the numerous online game development communities, like The Game Creators or Gamedev, contact a member of the community who has experience and knows what they're talking about, and ask them for some advice on how long it might take a typical developer to complete the goals of the project. Also, remember that most developers have their own preferred development tools... if you want to use specific tools, you'll need to contact people who have experience in said tools.

With these three basics sorted, we'll start to form a general idea of the size of our team. We know the volume of assets we'll need to make, we have at least a basic understanding of how long those assets will take to make using the development tools we'll be using, and we have a rough idea as to when we're hoping to finish the game.

All about the Assets

Before we start discussing job titles, we'll need to talk about assets in a bit more depth. More specifically, we need to discuss how much work is too much. You don't want to have your development team straining and pushing to stay alive because you piled on too many responsibilities. At the same time, you don't want to bring in ten people to do jobs that three or four people could do. Finding this balance is crucial to the creation of your team.

You should always observe what I call the "bellhop rule." Imagine a rich lady walking into a hotel lobby. She's only on vacation for a week, but she's packed enough luggage to virtually move into the hotel permantently, as rich ladies often seem to do. Then a businessman shows up, and all he has is a lightweight carry-on bag and a briefcase, which he'll carry himself. The bellhop has a choice: whose luggage should he take? The businessman has less to carry, but from the bellhop's experience, businessmen don't tip very well. Meanwhile, the rich lady is going to tip better, but there's a staggering amount of work for the bellhop to do in order to earn that tip. But the hotel can level the playing field, providing the bellhop with an elevator, luggage carts, etc. If the hotel offers such ammenities, the bellhop is going to take the rich lady's luggage, because it isn't as much work as it could be otherwise.

Let's relate this to game development. The bellhop turns into a 3D modeler, the rich lady turns into a list of twenty unique character models you'll need created, and the businessman becomes a shorter list of only five different weapon models. The development tools they're using is the elevator and luggage cart... with the right tools for the job, the 3D modeler can finish more work in a shorter period of time. But without decent tools, your modeler might find it difficult to create all tenty character models by themselves. You might want to only assign ten of those models to this modeler, find another modeler for the other ten character models, and find a third modeler for the weapons. You might get lucky and find a modeler whose so talented, they can handle all of the game's models by themselves... but you shouldn't plan on finding someone like this. Try to sort out your assets evenly across as few people as you can imagine needing, and down the road you'll find yourself optimizing the team's size as you find more people.

Be Realistic

Simply put, you won't find eight programmers, twelve 3D modelers, nine texture artists, etc. You need to focus great deal of energy and effort on keeping your team as small and lightweight as is efficiently possible. And remember the golden rule that just because you need something or want something doesn't necessarily mean you'll get it. Proponents of the "Law of Attraction," made famous in the movie The Secret, will beg to differ. But in game development, always remember that it isn't the size of the boat, it's the motion of the ocean... talent, good development tools, and dedication to the vision will always beat out the idea of throwing as many people as you can at an issue. Quality beats quantity every single time.

Plan on Managing your Team

Last but not least, we need to discuss a chain of command for your team. If you're working on a small project, say, a casual game with only four team members, you can skip ahead to Chapter III. But if you're planning on needing six or more team members, it's good to start planning supervisoral positions before you start finding people. We'll get into more depth on this subject in a later chapter.

For now, let's departmentalize everyone. You might think it's pretty silly to break everyone up into groups when you're only using three modelers, one musician, one foley artist (making sound effects), and two programmers... but trust me, you'll want to do this now, and you'll thank me for suggesting it later! Plan on assigning one person from each asset category as a "director" of that "department," even if there's only two people in that particular group. A lead programmer, for instance, can layout the engine, and help the other programmer(s) figure out what jobs they need to perform. Then, you'll have one person coming to you to discuss progress in each field, as opposed to your entire team telling you about what they're doing and leaving you to manage everyone on your own. It's always better to get news from one person than ten, and you'll learn this hands-on as your team takes form and gets to work making a new game.

Now Hiring

Now that we have a general idea of how large our dev team is going to be, we can discuss the various positions most development teams need, and what these people will need to do. Chapter III of this tutorial will tell us what job title's we'll need to assign, and we'll come back to the team's size later on in the tutorial as well. For now, it's important to come away with at least a basic understanding of how many people you're going to need.