Heya,

Just thought I would make a post here about the reality of gamedev.

As hopeful and upcoming programmers and game developers we all strive for that time when we can actually get a sponsor and get paid for our skills.

Usually when you get to this point, you have proven yourself capable and deserve to be there. At this time, you will feel great power and excitement. I have finally made it!

If you make it to this point, you are actually correct, you have made it.

After you start actually getting paid for work though, you will become familar with new terms, such as Deadlines and Milestones.

Yeah, Deadlines and Milestones, you think to yourself, I can get anything done only to realize that they require not only you to get your job done, but everyone else in team to meet these commitments also.

You will also find that some Deadlines and Milestones just can't be obtained, either because the manager or investors don't understand the complicity of what you are doing or because of the situation of the game, which is usually a weak team issue.

This all being said, do the best that you can do under the circumstances. If you do quality work, more offers will come. Always keep learning how to improve what you do and you will succeed eventually.

Everyone who has the desire to succeed will eventually succeed, but it takes time (years) and constant dedication.

Loco

When milestones are set each month, then its okay. I made the experience, though, that as long as the development proceeds, the milestones get lighter each time they are closed. Especially the bug to feature ratio grows from 0 at the beginning very fast during development.

In fact, sometimes you have to cut down the whole feature-lineup to the half to be ready for the final deadline because you have such a big list of bugs and final improvements you have to made. Its not the pressure behind me that makes me worse but stupid publishers which say "ok lets pull the deadline 1 or 2 months so that we can get our money a bit earlier"... man! I hate that, because my personal degree of perfectionism and quality cannot be fulfilled, but this is a very common way most publishers go, so I don't worry at all. I tell myself "hey, I could have done it better, but they didnt let me"

ahh and by the way: Game development is only 10% fun. Seriously. So, .. ... we hate fun.

Regards
Christian

Milestones are important, to focus on the progress od the development, so that it
is not getting off course by implementing more and more faetures that dont work properly.
Also managers/producers need it to estimate how the development is progressing
(regarding aquiering new funds, raising budget or also cancelling a bad project
early enough)
Also to keep motivation in the team, by evaluating the progress.

But milestones have a drawback:

the developers could try to make the game/target-status work for the upcoming milestone,
by unproperly hardcoding parts or making superficial work-arounds.
This could in the end extend the complete development, as large parts have to be reworked.

So a producer must! know technical details of the development,
to know how the milestone should be set correctly,
to keep the project in pace, but not requiering a status that could only be reached
with unclean workarounds for the next milestone.

This is very important for the coding, and less important for
sound/grafix (as they are not so affected by workarounds)

Wrong setting of milestones could as easy cancel a project, as the lack of milestones.


(This is all not a specific game-dev topic, but applies to all technical development)

(to high demands / to short frequency in a milestone :
frustrates team. Developers might cancel important gameplayparts
that destroy the unique-selling point of the game, and implement
unclean workarounds

To little milestones:
Developers might tangle up in senseless features,
or rework already working parts for the sake of it,
members might shirk/fraud on others,
members get frustrated, as they dont see the progress/feedback without
the eveluation by the milestone)

One thing that could help is prototyping an application. For example, Halo was originally going to be an RTS, but it looked so good they turned it into a shooter instead.

I would always have a playable prototype as the first part of development.
All papers, essays, concepts are crap, if the team can not
make a first running version.
Developing story, levels, grafix should come after! a prototype.

If the prototype is no fun to play, it might be better to cancel or restructure the
project, before spending much efforts in a complete campaign and custom grafix.


Aslo very bad: if the prototype (with much less content than the finished game)
runs slow already.
Games get slower, not faster in the later stages.

Well, most everythings been nicely covered here. And this -

Quote:

---

Games get slower, not fast in the later stages.

---

is very true. I hope everyone keeps this in mind. When you start your game, it's usually just one player, mabye some shoddy a.i. When you finish you game, it's a player, weapons, a.i, graphics, physics, menus, ect. So always plan ahead by giving the player options for both graphics and code. I'd also reccomend, if you going alone, to do your code first, then do levels and sound last. Simple because art becomes outdated much much quicker than code does, and code is more unpredictable. Makes scheduling things easier.

The prototype of the game should
include as many object, Levelcomplexity and paralel running skripts to simulate
the planned game.
This could be done using primitive dummy-objects with the skinsize and polys
as the finished objects are planned.
The same for the level (just some random garbage of blocks and models)
and some loops in the skript that calculate dummycalculations.

This prototype should note the restrictions for the later game then.
(Like:
I get 30FPS on my avarage testmachine, using
up to 200 Objects with each 3 looping skriptfunctions, and a Level with
1000 blocks and 30MB of Texture.
)
The prototype is still an estimate, but it is better to see it running than some
paper-estimations.

So the developmentteam knows the restriction of how many objects
the levels can contain, how complex they can be before developing them,
without guessing all the time...


There also needs to be a strict analysis of the targetmachine.
-who is my targetgroup (ranging from "Shooter Freaks", to "Granddad wants to play A casual Pokergame with his pentium 2")
-what is the low-end machine of the targetgroup at the time of release
-what is the high-end machine of the targetgroup (not of some few freaks)
-does the game run on the at least 90% of the machines on my planned target group.
(not reuqiering certain shader extensions to run the game , if the new casual Tetris game will
require a hig-end computer)