This my first post here actually.

Just a short background about me, I'm a programmer and project manager with absolutely no game development experience. I've been wanting to build a game for a long time now yet never had the time for a hobby project. Recently, my schedule cleared up a bit and I'm looking to finally get into it.

My question is, from a big picture standpoint, what are the specific, actionable steps that go into building a game, start to finish? The reason I'm asking is that I would like to have some kind of frame or "road-map" that I can go by in a linear fashion, perhaps some guidelines to keep me on track. I'd imagine the steps would be something like:

1. Come up with concept.

2. Write game design document.

3. Build POC

etc...

I'd love to hear an answer from someone more experienced! Thanks :)

what are the specific, actionable steps that go into building a game, start to finish

The only constant specific step is "make the game" - every team I've worked on, and every project, has done it differently.

What I will say is the following:

• for pro studios, the development team rarely come up with the base concept
• I've never seen a game design document finished before code work began (although sometimes a simple 'pitch' doc exists, which is the baseline for further docs, and for code work)
• a proof of concept is sometimes a prototype (bare-bones demonstration of mechanics) and sometimes a 'vertical slice' (essentially the full game but lacking 90% of the content), and sometimes you make one, sometimes you make the other, sometimes you make neither
• almost all gamedev teams operate some sort of agile development process, whether they think they are or not, whether they want to or not, which means the roadmap does not survive contact with the journey

Yeah, I've managed software projects before, that sounds similar to building a project without having a clear spec first, or rather building the project and spec simultaneously.

More often than not, the work overhead is enormous and results are disastrous :)

from a big picture standpoint, what are the specific, actionable steps that go into building a game, start to finish? The reason I'm asking is that I would like to have some kind of frame or "road-map" that I can go by in a linear fashion, perhaps some guidelines to keep me on track. I'd imagine the steps would be something like: 1. Come up with concept. 2. Write game design document. 3. Build POC etc... I'd love to hear an answer from someone more experienced!

Read this: http://www.sloperama.com/advice/lesson10.htm

Sweet! I know the website, yet never read this specific chapter.

Yeah, I've managed software projects before, that sounds similar to building a project without having a clear spec first, or rather building the project and spec simultaneously.

More often than not, the work overhead is enormous and results are disastrous :)

Unfortunately the alternative is not practical either. Imagine you spend ages drawing up a detailed spec (all while your programmers sit around being paid to do nothing), implement it, and then it turns out to not be very fun? Spec gets thrown out, programmers go back to sitting around, new spec gets drawn up. Repeat until studio runs out of cash. Or perhaps the designers design an amazing game, plan it all out, but then the programmers work out that some key features the designers wanted are impossible to deliver, and that the designers couldn't easily know that without knowing all the technology and the capability of the team?

Or, what if the game as planned and produced does turn out to be fun, but you discover half-way that someone else was working on a similar product with all the same features and is going to release it 2 months before you do? Do you stick to the spec, ship the game to minimal sales, and close the studio due to lack of cash? Or do you try and adapt? Similarly, what if player expectations change for some other reason during your development?

With the high probability of big changes happening mid-project, and the fact that some things are intrinsically hard to specify anyway, it doesn't make sense to have a big and rigid up-front design.

This isn't an excuse for poor planning; but games are complex entertainment products where there is no fixed formula for success, using complex software that developers rarely fully understand at the outset. By comparison, most business software has some clear goals which can be ticked off, and if all are met within the budgeted time, the project is successful and the developer likely to get continued work.