General > General Discussion

Goblins Of The Game Industry

(1/13) > >>

FaeryShivers:
"Goblins of the Game Industry"



  Most of us on the internet have thought at one point "I want to make a game"
or "I could make a  game so much better." If you actually do so and succeed, good for you;
 you're one of the few. The purpose of this article is to neither discourage nor stop people from
 developing games; only to make you more aware of some of these nasty little things that can occur
 from alpha to beta, and even into the "gold" version of a game. If you are not careful, you will be
consumed by the goblins of the game industry. (Cue thunder and lightning)


 The first little goblin is one I like to call "we don't need a contract." This is the first
and most fatal mistake for most development teams.It doesn't matter if you're on a team
 full of people who have known eachother since the first grade, you need a contract.
 You need to establish what happens if someone decides to leave. Do not leave any legal holes
 for the project to be destroyed if someone loses their temper. This happens time and time again
 with small projects. Get rid of the "we don't need a contract" goblin immediately and burn this phrase
into your head: "verbal agreements rarely hold up in court."  Yes, you did read  that correctly, it doesn't
 matter what was said out loud. You need to have the game protected on paper. If everyone on the team
 truly cares about completing the project and not just about their own interests, they will see that a
contract is the best way to go. The signature of every person working on the project needs to be on a
contract and the company owner should have them safely stowed away in a fire protected safe or box
 (many department stores sell them.) Do not go past the "concept" stage until this is complete.

Here are some things you may want to include in the contract:

-The "company"  or "group" owns all pieces of work made for the game, no exceptions.
-If someone dissappears for weeks on end without any attempt to contact the project leader
and/or company owner they give up their position and all rights to their work for the game automatically

If someone on your team refuses to sign a contract, get rid of them immediately.
Thats a hint right there that something could go wrong further down the road. You may
even see these little guys pop up in a heated argument:

"Its mine because I made it!"
" I never signed anything!"
"You can't tell me what to do, nobody owns it!"

Game design is very stressful and you're going to see a side of people that
you may not have seen before. This makes contracts all the more important.
If a person is not willing to agree to a reasonable contract when they are calm, what do you
think they are capable of when angry? Deleting or leaking the source? Putting something offensive
 on your group/company's web page? You bet. The more power someone has, the more papers need
 to be signed to prevent them from abusing that power.


The next nasty little goblin often comes out of the programming department and goes
something like this "We don't need source control, there are only x number of us." Big mistake.
This one will get you into trouble especially if one programmer leaves abruptly and you need to
 replace them or you only had one programmer to begin with.  Have your programming team
setup a system where you can revert to any version of the game at any time simply by recompiling
 that version. Get the programmers in the habit of documenting everything. It is very important that
 you do so.

From the depths of good intent rises our next little bundle of  green joy, "We're all friends here,
 we don't need a leader." Chances are on your team there is a person who wrote the majority of
the design documents (which of course you better make sure you have) and/or wrote the original
 concept of the game. This person is key to keeping the "dream" of the game intact. They should
 probably be the project leader. Gather your team members together and elect the person you all
think is most likely to not try to change the game for their own reasons. In many cases  this person
 will be the one who gathered up the team to begin with (and in the case of a company, the company
 founder if it is the first project.) The company owner may however want to elect someone else.
 If you don't agree with the choice, voice your opinion early. You don't need to get nasty, you
don't need to get mean, just make sure you speak to the person who appointed them and say
 why you don't think its a good idea. A "board" of people can also work but it may often end
 up in stalemates and/or disagreements among members especially if personal ideals get in the
 way of the original concept of the game.

  Most people will probably ignore this one out of all of the goblins. This may be because they do not see
 the value in having a leader. I can't even count the amount of stalemates I was in during the course of
 Illutia because of the way the "power" was setup. Stalemates slow progress, they slow it to a point where
 compromises  are going to be made that hurt the game rather than help it.  In my experience, more gets
 done and the game is more likely to stay on track if one person is in charge of making sure the dream of the
 game is kept intact. Co-leadership or having a "board" of leaders only works if everyone's interest is in the game
 concept that was created, not their own.  If you're working over the internet the chances of everyone being on
 the same page at all times are very slim (especially  if you ignore another little goblin that I'll describe later on.)
I'd honestly suggest having every staff member work out their own game idea (on their own time) so that once you
r initial project is done you can work on someone else's idea and have them be the project leader for their own idea.
 This gives everyone the hope of being able to be project leader if they finish  the current project and should encourage
them to listen to others when its their "turn" to be project leader. I know this sounds like a very elementary school
solution but you don't always know the maturity of the people you're dealing with, and most people have the dream
of being in control of their own game in this industry.


 Now we arrive at the gruesome twosome. These need to be avoided at all costs even if it means getting
 rid of someone."Keep x artist happy at least until they finish" and "keep x programmer happy until they finish."
 No one team member should be valued over everyone else based on their "talents." You may be equipped
with the best artist and  the best programmer in the world but if they have an attitude problem and keep
 pushing for control of more and more, they just aren't worth it. If the programmer or artist refuses to follow
 the plans that everyone else has to follow, and the rest of the team is keeping them happy in hopes they'll listen,
 your team is in trouble. They know you're going to appease them no matter what, they're never  going to listen.
 If you're the project leader, put your foot down early. Here are some warning situations that might arise over time:

Project leader: "We need to get x feature done."
Programmer: "I don't want to work on that, I want to work on this system."
Project leader: "We don't need that system yet, we need this feature."
Programmer: "If you push me, its not going to make me work any harder."

(If any team member is "threatening" you so they can do what they want, get rid of them immediately.
 Never give someone power enough to be able to stay and do as they wish
especially with something as important as the programming of the game.)


Project leader:" I need a "wild beast" as soon as possible."
Artist: "I'm working on goblins right now..I'll get to it when I can."
Project leader: "Please work on the wild beast for now. Its needed more."
Artist: "You can't make me drop a project in the middle to work on something else
You asked for my help and I'm giving it to you, but some things need to be done my way."

(Make sure you're being assertive with your team members, if they can't give a valid reason why
  they can't work on something else then they should not argue. Beware of people who have a
"card" they play from their hand often.)


 Please Do not get me wrong here, sometimes there are very good reasons to assert that something
 else needs to be done first to your project leader. The leader of the project should not be able to do
whatever  they please, or treat anyone however they please,  just because they are the leader (unless
of course they own the company too, in which case you're screwed.) If you can't assert yourself in a
reasonable way without being punished then its probably best you leave the project and/or find another
 one. Hold meetings regularly and make sure everyone voices their opinions as early as possible. Holding in
 your feelings about a particular way the project is going is only going to build resentment. 


 The final goblin I wish to cover at this time is " I'm very busy, I don't have time to keep myself up to date."
WARNING: This person is probably lazy.  If they expect another team member to be their "secretary" all
 the time because they do not feel like reading through the documentation, posting on the team forums
 and/or going to meetings, this person could cause problems later down the road. If they care fully about seeing this
 game through to the end, they will be very interested in joining with other team members to discuss the project
. It is very rare that someone is going to post fifty pages of documentation and updates every day for other
members to read, they can take time out of their day and keep themselves up to date as it will increase everyones
 productivity for them to do so. If they believe that keeping themselves informed is a waste of time,
 they are a waste of time.I know people who work their butts off day in and day out and still
come home and read the newspaper or turn on the news, why? They want to know what is going on in the
 world around them. Even though they have a lot to do they know its important to keep up to speed with their
 community and the rest of the world.

Every team member has something important to say, sometimes goblins will appear when they do,
everyone needs to be right there to squash it when it happens. Pay attention and address issues
when they come up. If you are all good friends working on a project together, remember this phrase
 if nothing else; " True friends wouldn't want you to suffer for their actions, even if you weren't friends anymore."


For everyones sake, slay the goblins.


-Faeryshivers


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Stoven will be adding his thoughts to this as soon as he gets time.
I hope this article will be of help to some of you looking to get into the game industry,
I know it would have saved me a lot of headaches had I had this information 2 1/2 years ago
when we started Illutia/Aspereta.

Also as a final note here, please know your rights before starting a project.
I strongly suggest reading the DMCA (Digital Media Copyright Act.) If someone on
your project randomly deletes something out of anger, there is a strong chance with the new
laws that they have committed a crime, even if there are no papers signed (though contracts decrease the
likelyhood of loopholes). It is so important to know your rights when working on a project of this nature.








Darion:
Which is why one should just learn to make music,art and program him/herself.

MadMonkey:
wow. i didnt read it all, but you've got a point there. or two. or 50. anyways great post, i can somewhat relate to this, in a way.

 ;)

FaeryShivers:

--- Quote from: Darion on October 06, 2005, 02:49:37 am ---Which is why one should just learn to make music,art and program him/herself.

--- End quote ---

Unfortunately, most people aren't -that- multi-talented and the project would
take even longer to accomplish. Working on a team can be fun but there are some things
you have to look out for or they could destroy the entire project. You can't let a "jerk" ruin the whole thing
even if they are  a talented jerk.

st0ven:
I think that was a very good rundown of some awesome points... and forgive me for not being able to join in on this conversation/thread sooner. It turns out that ive been through a good bit of turmoil in just a short amount of time so ive gotten a good chance to see some of the dirtier sides of the industry. So in addition to all of FS's great points, i would like to take this opportunity to add some of my own awares.

Know what you're getting yourself into(First Job in the industry): Silly little suggestion, but it is of awful importance. Let us say that you are a pixel artist and you've found a very promising job posting either through a friend/colleague, or a post via gaming site (gamasutra.com, et all). Youve read their 'sell' on the job description, and you couldnt be more thrilled with how good things sound! This job description is the furthest thing away from a summary of 'just how well off' a company is doing.... also you could be given the complete wrong idea by what kindof work is involved. For instance, you read a job description summary and it sounds something like:
" Come work at our luxurious offices in sunny [enter state here] and get a chance to put all your creative talents towards some great AAA titles we have in development, we offer great competitive salaries and benefits..." and such and so forth. 
My first point is this. Know what you want to be doing(work wise). its very possible that this AAA title is something youre not even initially signed onto if you get the job, and after youre hired you find out its of a genre that you dont enjoy working on or something like that. The interview process for a job is a great opportunity to find out exactly whats going on behind the scenes, behind the facade of the great company thats doing great things. Ask what projects specifically are going on, past present and future. Get a well rounded idea of what kindof business model the company works under (Are they an external solution of some other publisher/developer? or do they make their own licenses/ip?) as well as the type of games and clients they work on/with. Its really easy for the first time working in the industry to come in with the attitude that 'youll work on anything', but after you work on 3 barbie titles in a row (no offense DMax if youre reading, hehe), you might get really bored with it and lose the joy in working. If you like working on RPG's and platformers, make sure the projects they want to put you on arent educational games or puzzle games. Learning a company's past and future game projects/prospects is a great glimpse into what kindof work you're going to be getting yourself into. Some random other considerations you might want to take in... does this luxurious office reside in a luxurious city where cost of living is very high? if so, and this is not reflected in your salary, youre putting yourself at a big disadvantage already. What are the hours?  What compensation do you have for any extra time put in? (if youre new to the industry, you may be surprised ... in this industry, youre expected to put in long hours and dont usually get a thing extra for putting in a 60 hour week instead of a 40 hour week.)

Know the company you're working for:  Sounds similar to the previous point, and I admit it does tie in, but this is important with any job really... LEARN THE COMPANY HISTORY. How is it doing financially? Who are the board of directors and the CEO? do they have any outstanding reputations? (good or bad)... if you can find out their names which are often published somewhere on the company site, it isnt hard to do a quick background check on them thanks to google. One thing about companies in the game industry is that there are new aspiring teams popping up every day. Many developers are springing up thanks to new diverse hardware, and are therefore relatively new, young companies. The chances that youll be joining a startup company (especially in wireless/handheld sectors) is quite high. KNOW THE RISKS, and this goes hand in hand with FS's point to NEVER WORK WITHOUT A CONTRACT. Ive seen this happen very recently... teams of guys all work on something where they hope that some big investor will pull through to help them out, but it never happens, and because they have no CONTRACT or terms of employment, they're technically unemployed workers volunteering their time towards a common effort (even though its possible these guys might THINk that they are being 'employed'.) Also, make sure the company you wish to join is in good financial standing. Do a background check on their projects... did they have any big flops/failures recently? did they waste a bunch of much needed cash on development for a product that never made it to shelves? These kinds of risks hit hard when they fail, and its not as uncommon for a younger company to undergo such practices. Make sure the company you work for is a financially sound institution that has enough cashflow to pay bankroll each month. Otherwise its quite possible that your jumping aboard a sinking ship, so to speak (and yes, this has also happened to myself within the past year).

Know the Industry: "We're in business to make money...":  Yep, just like any other company in any other industry in existence, companies in the entertainment industry exist to MAKE MONEY. what does this mean? It means that larger companies became large or are staying large because they are in business to make money, NOT because they want to make games. Understand that making games is a means to an end to make money, and therefore MANY decisions regarding a game's development , despite its effect on a game, are made with the interest/intentions of MAKING (or in some cases, saving) MONEY. Why is this such a big deal? Because it is in stark contrast to why the developers are working in the industry. These people want to make the games, they want to put their heart and soul and creativity into a product no matter what the cost, and are most likely not in this industry for the money (because anyone will tell you youre in the wrong industry if youre looking to get rich, heheh).
Lets say youre working on a game and its been in development for some time, but as always, production is taking longer than scheduled (and this is a very common case), and certain 'sacrifices' have to be made that might affect what youre working on. Naturally youre pissed because you know that its really going to hurt the game's overall experience and youre emphatically opposed to cutting it out. Heres the bottom line. It doesnt matter. If the game doesnt make it on the shelf because youre trying to add some fancy effects, then all is lost. No company in the industry can afford to miss ship dates, and most (unless the game has a lot of hype behind it) will ship despite the game's flaws. If this were not the case, then every game ever made would probably get a very good rating in magazines... but thats not the case because that is not how BUSINESS works.
If i could give any advice to anyone caught in this situation is the following: dont hold it against the industry. Too many developers out there are completely 'jaded' because theyve seen things fall to shit so many times they wonder how an industry exists at all. There are a lot of problems and misunderstandings that happen throughout development in any team/company. A lot of them are crippling to a game. Just remember youre being paid to do your job as best as you can, and if there is a huge serious problem where a decision is made which is impeding you from doing your job as best as you can, bring it up in a politically appropriate way. If you bring it up the wrong way, and make enemies, it could very well haunt you for a long time.

I could probably think of a few more, this should be fine for now though, ill amend this if i can think of anything to add at a later date. other than that, thanks for reading and i hope these additional points can help point out some potential pitfalls so the impact of them can at least be softened by forewarning.

Navigation

[0] Message Index

[#] Next page

Go to full version