My wife and I decided to make a video game as a hobby. I know Javascript programming and she's pretty good at drawing stuff so I figured that we would come up with the game idea, mechanics and general design together but that for the actual production I would take care of scripting and implementing the mechanics and she would take care of the art. I'm learning Unity as we speak and she's fooling around with Blender and Inkscape.

I have read alot about Scrum and Kanban and Scrumban and about game development workflow but everything I read was pretty high-level. I'm looking for a guide that's a bit more granular, a bit more detailed. If I'd compare what I've read to a recipe, it would go like this: take the raw food out of the fridge, cut the raw food, cook the food, eat the food. I'm looking for something more detailed, what ingredient should I prep first, what quantity, what tool should I be using, how big should I cut the pieces, in what bowl should I be putting it and in what order should I add the ingredients to the bowl, what temperature should I bring the oven to etc... because I'm wondering how we are going to make sure that we both have work to do at the same time and that we know what work depends on what once we are done with the original planing phase and we start iterating prototypes and then move on to full fledge production. Any help would be greatly appreciated.

The same patterns apply on tiny teams.

Start small and simplify. Then prioritize, noting dependencies. Break work down into tiny pieces, about what can be done in a single day. Prioritize again, noting dependencies so depended-on stuff goes first. Re-review the estimates remembering that work should be broken down to the point where you *KNOW* you can get it done in that time window. (If you don't know how long it will take than you have yet another bundle of work, figuring out what it is so you know.)

Again the key points are to sort by priority and make sure the tasks are broken down into things you KNOW how to do. If you don't actually know how to do it, or are thinking "I'll just look up how to implement a pathfinding algorithm, I've heard about A-Star, should only take an hour or two" then you're in for a shock.

Once you've got everything figured out exactly what tasks you need to do for your small and simplified project, look at the time and work you can do in that time. Make sure the work fits, normally a two week increment is good, often called a work sprint. If you want your first fun pieces to come out in two weeks, and you're able to put 10 hours per week into your hobby project, count out the top 20 hours worth of tasks. That's all you can do. Make sure you can really do it, then do it. Make sure it builds what you want, and review carefully for hidden dependencies or work you may have missed. If it doesn't work out then generate different tasks and re-prioritize until it does. Honest assessments of how long things take are really hard for many people. Most people underestimate the time it takes, and sadly many people underestimate over and over and over again. Work takes time, and game development work is hard. Get good values for the time you expect work to take and get it prioritized.

Then get to work and do it for two weeks.

At the end of two weeks figure out what you can improve on, and do it again.

A frequent recommendation for beginning is to do one month. At the end of one month you have learned a lot. Call that project done and start a new one. After about six months you get to a pace that you know what you are able to do and can create a game in a month, or not. Again, start small and simplify. You won't be making a massive AAA game since those take thousands of work-years. You won't even be making a shove-ware style title as those take work-decades to complete. Think tiny, and even that is probably too big.
Oh, as for specific tasks, you might have "Hook up a character controller", "Add input to character controller", "build a prototype white-box map", "Implement a simple 'attractor' behavior", "Create a player character on the map", "Create an enemy on the map", "Make player move around map", "Make enemy use the attractor behavior to chase the player". And on and on and on.

Good luck on your project. It can be something fun to do as a family, but you absolutely need to keep it simple, especially as it is a hobby.

Agreed. Here are some more resources on agile & lean practices for video game development:

http://blog.agilegamedevelopment.com

https://www.amazon.com/gp/product/0321618521?ie=UTF8&tag=wwwagilegamed-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321618521

Full disclosure: I'm the author.

Agreed. Here are some more resources on agile & lean practices for video game development:

http://blog.agilegamedevelopment.com

https://www.amazon.com/gp/product/0321618521?ie=UTF8&tag=wwwagilegamed-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321618521

Full disclosure: I'm the author.

I've actually just finished your book. Very interesting read. Learned alot. I think what I need to do is try to get a better grasp of all the different kinds of work that goes into making a video game and how it all fits together. If I was to distill my view of video game development it would be: some people make pretty computer graphic objects and some other people program the behavior of said objects. But I'm guessing that there is alot more complexity into how both of these are done and how they fit together.

Maybe you could give me some general answers to the following question although I am sure there is many suitable answers.

Let's say I'm developing a Sim City game, I'm in charge of programming and my partner is in charge of art. We have designed on paper most of the game mechanics and my partner has made sketches of the different buildings and various game objects. We are now ready to build our first prototype. What would be, in order, and in detail, the first 5 things that we should be working on. I'm especially interested in understanding, during early prototypes, what the artist can be doing while the programmer does it's thing. If I'm not mistaken, early prototypes are mainly to test game mechanics and use placeholder art or even square boxes. What does the artist do during that time?

Neo, your artist won't work as hard as you will. Programming is the majority of the work. Break your project
down into small chunks. Choose one small representative "level" to build first. Hopefully, your artist will
deliver art as you need it. So you have to figure out what you'll need, and when - as well as what you can
do to make placeholder art yourself if necessary.

Neo, Tom's correct that there will be an imbalance.

One thing to make clear: agile is a framework for having developers figure out how to deal with this rather than relying on a defined process to handle it for them, so there is no "best practices answer" to your issue.

Since this issue comes up a lot, I'll share what some folks have done:

- Less strict specialization: The artists tests and tunes what is available if no art work is needed.

- The programmer iterates more frequently. E.g. instead of building an entire camera management system and a set of cameras, they apply the YAGNI principle and just provide a simple polar, follow or 1st person camera to begin with and some tuning interface. Again, with the artist doing some tuning work, it can allow more iteration on the game, which is good.

- I have even seen times when the artist picks up a little scripting work (depends on the artist).

- Take advantage of the extra art time. When we were building a mechanic and a city to use it in, we had the artist build a grey-box full-sized city as well as representative city blocks with higher fidelity. That allowed us to approach the mechanic's gameplay from both sides of the fidelity as well as giving the programmer a range of assets to test with.

- Have the artist detail your car in their spare time (just kidding, but this was suggested once ;)

Iterative development not only applies to what you're making, but how you're making it as well. Experiment & have fun!