"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.
