Eating an Elephant - How to Work on Big Projects?

Salutations, fellow game designers. I have a bit of a problem.
It has occurred to me that I don't really know much about game design in terms of processes.

My Questions.

• How long does any game of significant scale take in terms of man-hours?
• Is it normal to restart the project more than three times?
• Should I start with the center or from outside? In other words, should I start with mechanics, or with UI?
  • What's a good mental model you would recommend when approaching something ambitious?
• Are there any guides or books you'd recommend on practical game design?
• What does a professionally organized project look like?

While I have a solid grasp of Unity's principles and capabilities, and have several years worth programming to back it up, the issue is that I don't know how to actually tackle this project, nor do I really know anything about practical game design for that matter. I expect that this project is too big for me - and you're right - but even if I were to downgrade to something more appropriate, my concerns still stand: I don't know what I'm doing.

Just to clarify, I'm not looking for anyone to collaborate with or hold my hand; it would be good if I got this experience on my own. Someone like yourself, with a few finished projects under their belt, would know best on what the formal process of game design looks like. I'm really tired and embarrassed of the vast graveyard of abandoned game projects sitting in my Unity Hub's directory, and would like to break that curse.

I'll be watching this thread, so I can respond as soon as possible.

Thank you so much for any help you can provide. I've always wanted to make games for others to enjoy, but I keep getting in my own way.

 

Hi,

In many ways, game development is more challenging than business application development because game development is so much more multi-disciplinary.

It's completely normal to restart projects, especially when you're first starting out. Eventually you're going to want to buckle down and get it done. But, while getting to that point, you'll probably come to the realization that a much smaller, but non-trivial, project would be a better stepping stone. Not something as small as Flappy Bird, but nothing as big as an RPG.

There are many advantages to completing a few modestly-sized projects first:

• You can refine your toolchain and processes, so you can apply them later to larger projects. If you're not familiar with devops, Seth Coster did an introductory talk at GDC: Stress-Free Game Development
• You're not tempted to overengineer a solution to make it "future proof". Trust me; an overengineered solution isn't going to be future proof. It's just going to make it more complicated to write, maintain, and use now; and it's going to be more of a headache to use in future projects.
• You can build up small, independent (and independently-testable!) modules to reuse in larger games in the future.
• You can refine your game design vision to really know what you want and don't want in your games.
• You can build up a portfolio to show potential future teammates.

Even with a modestly-sized project, get all of your primary mechanics working in separate "island prototype" projects first. Once you get your mechanics working in separate projects, you can start pulling them together into relatively-independent modules in a primary project.

If you first get your toolchain, workflow, and core modules working with medium-sized projects, you don't have to worry about them as much with a larger project, which frees up your time and brainspace to focus on the unique challenges of the larger project instead.

Also, don't be afraid to consider using Asset Store assets to speed up your development. (But also be realistic about the quality of each asset and what it can do for you.) For example, if you're planning to make point-and-click adventures, a well-written and reliable asset like Adventure Creator can be a huge boost.

 

Tony's advice is spot-on (as usual).

I would add just a couple more tidbits that work for me:

• Keep a project log for every project you do. This is just a text file (or whatever you prefer) that you use like a diary: whenever you work on the project, or even have significant thoughts about the project, you add a dated entry with your notes. These should include design musings as well as technical notes about challenges you ran into, how you resolved them, or (if you haven't resolved them yet) how you're thinking about doing so. This serves several purposes: it helps you pick up the project where you left off after putting it down for a few days/weeks/months; it helps you clarify your thoughts as you have to write them down; it gives you a record of solutions for when you run into the same problem again; and — perhaps most important — it lets you unload stuff out of your head, without worrying that you will forget it.
• When you start a project, jot down a description of what you want the final project to look like. But then imagine what a 0.5 version would look like — what are the "nice to have" but not crucial features that won't be included in this half-done release? Then peel it back further. Define a 0.1 release that is playable, but only just. What's the minimal core of your game? Be ruthless in cutting anything that's not absolutely necessary from this 0.1 spec. Then focus all your energies on completing that; forget about v0.2 through 1.0 (your thoughts on those are already written down, so don't worry you'll forget them).

Getting to a 0.1 minimal playable build as quickly as possible, I find, is how to get a project off on the right foot. If it's a good idea, the 0.1 game will probably be fun enough to keep you motivated to do the 0.2 version, and then 0.3, etc. Conversely if you finish the 0.1 game and it's not as fun as you imagined, or by that point you have thought of an even better idea, then you can shelve this game, content in the knowledge that at least you got it to a playable state.

 

Everyone uses this minimum viable product image, but that's because it sums it up well:


Every game design is flawless in your head. That changes when it actually exists as something to playtest.

Also, define your game's pillars, usually 3-5 specific guiding elements. When you're evaluating whether a feature should be in the game, or whether a feature you've implemented hits the mark, the pillars will be your lodestars.

 

Both these devs are leagues ahead of me, and truthfully I’m still working on a release, but let me give some suggestions that you can take or leave.

1) Always start with prototyping. A common issue many stumble onto is doing all the groundwork just to figure out it’s not fun. You can’t fix that usually.

2) The project is always much bigger than you think. Always. The point where you have your assets made is likely about the 1/3rd mark. Making levels is about 2/3 mark. Polish is the last leg.

3) Finish what you start. Do not start a new game, unless you are culling your scope way back.

4) Write out everything you need to do on post-its. This will give you a visual of what needs to be done, and it gives you something tangible that you can grab, as well as watch the development progress.

5) Do 30 minutes a day no matter what. If you aren’t feeling it, take a break.

6) If you aren’t having fun, quit. Game development is not lucrative enough to bother with if you’re not having fun.

 

All great advice!

 

Wonderful advice from all of you! Thank you much for your time and help - your advice is really good! I can't wait to get back to work later this week with all these new perspectives.

 

I'm gonna add a clause to that:

Make bad game

Seriously, if the project does not go the way you want, wrap it up and released it, and get learn the lesson for next time.

 

It is a bit unclear if you mean to work on this exclusively by yourself, or if you are looking to hire people with yourseslf as lead designer/producer.

If you are by yourself then almost all projects "of significant scale" are out of scope. I mean I don't know exactly you mean by signifcant but I assume it has to be reasonable big or you wouldn't have used the word significant. Unless you have some driving passion to finish your opus, no matter the time no matter the pain, then a solo project should be really small (think casual mobile games, games where levels/content can be autogenerated, etc).

If you are a building a team then you probably still want to start small if you haven't managed a project before. Maybe even better to team up with a few friends first to get a feel for what the process is like. It might not go anywhere but at least you will better understand the challenge before you start dropping money on people. Big team-based projects are a completely different beast to solo projects, and require a different set of skills.

Also this: