Opinions on making Video Games

	Yes, that is an interesting topic. Mind you that these are my opinions and they are not exactly
what the situation in the industry is.

	When I got into the game development in around 2003 April, I asked myself, why would anyone NOT
take up gamedev as a career. I thought that game dev is cool. However I think I am wrong in that aspect.
For beginners, most of the companies out there think of ways to reduce the pay/salary. Game dev is for 
people who love games. That just is one of the reasons for companies to pay a fresher less. Generally 
freshers end up taking game development thinking that they would 'create'. Remember that no company 
exists for its employees to create something that would not earn them profits. In simple words the
corporate setup would ensure that the heirarchy dictates what an employee does.
Freshers also have this thought that they are out to create 'their' game. Stop dreaming. Once you get
into the game dev remember that you will be doing someone else's idea, someone else's game. I am not
against this, the company has its own business to feed. There's nothing like free lunch/beer.
Game dev (@least in India) happens to be in the nascent stages. Now that is a good thing and a bad thing.
Good thing is that it means we can form the rules of the game. After the ea_spouse episode, gamedev in 
the west kind of looks like a slavery project. Of course not all the studios are like that.
Bad thing is that it means we have no idea as to how game development is done. I have been seeing all of
the work going around me and frankly it is less than satisfactory. It is mainly because the people who
work at the higher levels do not have any idea what it means to make a game. Neither do I. I did not come
across anyone yet, who can say that with confidence. I am NOT talking about mobile gaming. I am only
talking about PC/console games. However, the fact remains that when we take up a project, someone is 
investing his/her hard earned money into it. Some of our mistakes could cost the entire project. While
mistakes definitely are a part of the whole gamble, blunders are not. When I joined my first company
I always thought - game dev is just like software dev. WRONG!! Software dev is relatively easy. Game dev
involves talking/interacting with artists. Now artists always think in abstract terms. Coders think in
logical terms. That is a conflict that every newbie in the industry faces.
If the coders and artists do not understand each other, the project is doomed from the beginning.

Well the one thing that will surely kill the game development is lack of communication. What is the
artist doing has to be visible to everyone and the same with the coder. Managers should open everything
to the team. Of course business, pay details
Coders - I have made this mistake early in my game dev career. I have seen too many people 
make this mistake time and again. First off remember that the what all the coders produce is just
an executable - atmost a few hundred MB. The artists create the major chunk. That means that every
single mistake that the coder makes has a huge impact on the artists' creations. Also remember that
no user will ever look @ the executable and try interpreting the binary code. The user is exposed to
the art - not the code. Code exists so that it is NOT visible. Always support the artist. Help them
out with their problems if they can be solved. When you make a feature, think of it in terms of how
an artist will produce the art for it (if required) and how will the end user see it.
Artists - do not assume that you can get the game done without coders. No. Even if you have a complete
engine, you will still require coders. Coders are the people who can make your work easy or difficult.
Imagine that you did not have Maya/3DS Max. Those were the packages that some coder somewhere wrote.
Also remember that game development is way tooo complex for normal artists. If some artists do not think
in terms of optimising the art (more later), then game dev is not for those artists. For games every
last byte is important. Talk to the coders. They will crib more about the bytes. Artists who can think
like programmers are a huge asset for the studio.
Managers - Dilbert would be a bible for all the managers. Oh, that might send the wrong signal. Take
the pointy haired boss and remember that he is what the manager should never become.
Deadlines mean that they have to be met. That implies that the deadlines should be carefully planned.
Commit to the deadlines with great care. For a new studio (India) if you make an estimate of x days,
double it. 2x is the number of days you will require to meet the deadline for that list of features.
Oh btw - 0900 hrs to 1800 hrs is what the company time is. Making assumptions that the employee has
no other option than to stay back and work his *** off is definitely something that I have seen.
It is to the managers' credit if the employees are not burnt and it is their blunder if they do.
Managers HAVE to take responsibility for everything that the studio produces. That is exactly what 
they are there for. Planning for unforseen hiccups is what experience tells a manager. Managers 
contribute their experience to the team.
Tools - God damn it. Why does EVERYONE ignore tools. When there is a slippage in the time, the first
thing that gets cut out is testing. Tools come in next. A good tool now will save the artists a lot
of donkey work. Imagine that the artists had to do all the 3D models without 3ds Max/Maya. They had
to hand code all the models, vertex by vertex, UV by UV. All of this because the coders were not 
allowed to create the modelling package due to 'timeline' constraints. All these modelling pacakges
and their exporters are just tools.
Ideally ('miserebles' you know this term) tools should be automated, without any human intervention
required. Those tools which require a human to interface have to have GOOD user interfaces. 
 I did a few tools and that is how I understood how important they are. They may take time to create
but will definitely save a lot of time later on. I think I have this habit more so because I come 
from a *NIX culture. I believe in automating anything that can be automated. A script for everything
that has to be done more than once.
 My belief is that when a particular feature is being designed, the tools for it have to be kept in
the context.

Optimising the art

	Optimisation is not just for coders. Artists have to think of the best way to make a piece of
art. The advantage that the artists have over coders is that they can create anything and it has to
be accepted. 

Art in the context of the whole game

	Suppose you decide to create a character in the game. Now imagine that you coloured it lemon 
yellow. Now imagine that the artist who creates the HUD ends up saying that lemon yellow is the best
colour for displaying an element. The first thing that should strike a decent artist/coder/manager is
WTF!!! Yellow on Yellow - trouble. It should not take the two of them to be put together in order to
find out that they dont fit. Similarly every piece of art should be seen in the context of the whole
game. If a crate is made, which level would it be used, will it be accessible, should it attract
the attention of the user or should it lie around doing nothing etc; are important. A majority of the
time I see artists narrowing down their work to the single character/mesh on their 3d modelling package.
This would possibly explain the problems that I come across in some games.
Prince of Persia - Warrior Within, has one quest where there is a demon chasing you and you have to
run away from it. Now if the demon is too close to you, then the screen is rendered in sepiatone form.
However there is one location where the camera goes away from the prince, the prince has to run across
a wall and jump onto a next platform. Now if the screen turns sepiatone, the wall and the floor look
the same. Half the time the prince does not run across the wall. Instead he sommersaults on the wall
because I did not orient him in the right manner.

Copyrights CyraX/Chaitanya
http://students.iiit.net/~cyrax