Do they just start typing code into the computer 8 hours straight, everyday, without lifting a hand away from the keyboard?

They have schedules like any other job would have. With deadlines, project managers, reviews, etc...

Don't set unrealistic release targets

In pro development it actually could be more than 8 hours straight. Working overnight at weekend could happen sometimes, as result of bad project management.

If you're talking about NA development, smart ones don't set release dates until they have it ready to ship out the door! There's too much shit that is just waiting to kick you in the .

Well for the games I worked on, it was mandatory overtime, and a lot of people working very hard all day. Having said that we also pushed our goals out very far, but even with that we were pushing it and wound up late. This is why developers say things like coming 4th quarter 2013 rather than coming Oct 2013. Games are later all the time, it feels more normal for them to be pushed back, and vary rarely do you ever see them comeout early.

The games are on time because they aren't actually finished. "It compiles, ship it!"

Which comes first, the graphics or the code? How many people typically do the programming work? How does the programming job get split up so everybody's code is compatible?

Yeah if you set a specific date too far out you're destined to miss it, too many factors that can come out of nowhere and throw you off. Set milestone dates internally and do your best to stick with them, but be willing to acknowledge if the quality of the product is starting to suffer due to the rush to meet deadlines, don't sacrifice quality just to get it out the door, but also don't spend forever polishing because you could easily spend a year tweaking and tweaking

Production quality graphics and game content in general usually takes more time to do than code. So first comes placeholder graphics, and eventually it gets replaced with production graphics, when it is ready.

How many people is really depends from a project. One to many. For a NES or SNES game 1-3, I'd say. More is typical for RPGs that have few quite independent parts: overworld, locations, battles. There should be some standarts set up to make pieces of the project code made by different people compatible.

In general, development management is a huge topic that can't be answered in a forum thread, especially for a not well defined, abstract situation.

I'd imagine quick and dirty placeholder graphics are made in conjunction with the code foundation. Later on, the final graphics would be implemented.

Development is also completely different depending on the platform. Are you talking about NES homebrew, iPhone level games, or big budget computer titles?

The big companies will usually just set a deadline and send out whatever is done by that date.

If you are talking about small developers, they don't set a deadline until they are ready.

Various companies will have various ways of splitting up large projects, they have tools to help with this and people's job it is to oversee the integration but typically you will be given specific interface requirements that you have to meet to ensure that code is compatible. With smaller projects, I find you will often just work closely with your coworkers all the time. If it's a 2 person project, you don't each go build your half and then try to ram them together

I must say, it sounds like it's a lot more fun working with a team, then doing everything alone in my bedroom.

Anyway, does this sound like a typical work load division:

-object AI programmer (physics, AI)
-object graphical interface programmer (metasprites, animation, oam building)
-scrolling engine programmer (bg scrolling, camera, bg map format, tile collision, level object spawning)
-graphical effects (parallax, waving, mode-7)
-audio programmer (music, sound effects)
-HUD programmer (programs HUD, title screen, gameover screen)

Basically what the "object AI programmer" would do is program a new enemy, but will use a random metasprite from another object, to test it out. Then the "object graphical interface programmer" will program an appropriate metasprite for it.

That would be way too many people. Parts shouldn't be artifically separated, the separation is natural. If things are independent, they could be separated. Like, audio part is practically independent from gameplay, so it could be done separately.

Although working with a team may seem more fun to you, in practice it could be a real headache. When you working alone, you don't need to do that much management and especially communication. Like, if you are a programmer, it may be much easier and faster to do something by yourself than to explain another guy what exactly you want and get exactly that. So, when you work in a team of few people, it takes a lot of effort to make team work like a team. Thus, if you want to have a team, it is a good idea to keep it small.

I don't even mention a hobbyist team projects where everyone has equal creative rights, it may take a lot of nerves to agree on some artistic desicions.

One word.

CRUNCH

If you are talking about SNES games, you will not find that many programmers total. Work division will be done by skills. The biggest homebrew team I would expect would be one of each of programmer, artist, musician, concept designer. Most likely the concept designer is the same as the programmer, or the programmer will lose interest.

Either way the team members probably won't be local so you will still be alone in your bedroom

I read somewhere that during the development of Aladdin for the Sega Genesis, they listened to "Shiny Happy People" non-stop.

"That would be way too many people."

Is that for a team of homebrewers, or for a major company?

Bunnyboy, send me some USB kits

I'd answer, but I have no idea myself and need the replies to this thread!

That may be OK for a major company working on a major project, like modern RTS or (MMO)RPG. Certainly too many for a 8-16 bit game. Actually, many games has staff rolls in the end, and they are posted online - you can search for games of the kind that you are considering, and see how many people it was.

That actually more like a list of tasks to be done, but many to all positions can be implemented by the same guy. It won't make much point to do them simultaneously or to take someone just for a single task.

I'm a computer science student -- while I haven't been on any real commercial projects yet, I've done some dinky little group projects in class that requires some job/time management. Usually it goes roughly like this:

1) Talk about the project and what stuff we'll need to do
2) Figure out how to do stuff and who should do it
3) Realize we missed something, revise (1)
4) Repeat 1-3 several times
5) Tweak some stuff and fix any bugs

I imagine homebrew games (if they're being done by a team) and commercial games (EA, Activision...) are done roughly the same way but on a larger scale (for commercial stuff)

And of course sometimes (usually by order from some business guy higher up) they'll cut out most of the debugging process

It's not a bug, it's a feature!

As for release dates, I think they're a little bit silly. Look what happened to Skyrim. They just had to hit that 11-11-11 date . Most of the time they're reasonable inside data to work on a schedule but to release it to the public years or months before the game can be finished is just asking for trouble.

You might want to check this out:

This. You may have two programmers if you had a seperate person working on the sound programming and perhaps tools for music composing. I don't think too many of these old games had huge development teams. But modern games (PC, Xbox 360, PS3) have an army of people making them.

^ Words of wisdom