I completely agree with blackley1, except I think you need even more time for polish.
I just wrapped up on a sixteen week project developing a mobile game for a children's museum. We were a team of six: a producer/designer, an artist, a tech artist/programmer, two more programmers specializing in database construction and a UI programmer. We spent 6 weeks designing and iterating until we had what we thought would be the final product, and then we spent 10 weeks polishing and tweaking. I should mention we were play testing designs starting on week 2. Trust me, this still did not feel like enough time.
If you really want a schedule like that, you need to structure your teams well, making sure each team has the skills it needs to make the game it is working on. I'd say bare minimum a designer, an artist, a programmer, and a sound designer (sound is so effing important!). If you can double up, get another artist or programmer. For this project, I'd argue for teams of six, with everyone able to wear multiple hats. On some level you will also need someone to handle production for these teams to streamline their process. Depending on the size of the game you want (and if you want a game a month, they WILL be small games) you need to work multiple teams simultaneously on a revolving cycle (check out how Telltale developed the "Walking Dead" games). You should have another small team for solely for play testing (you may think you know what's fun, but you never really find out until you put your game into a user's hands...). And you will need to continue streamlining your process as you go, finding out where the kinks are and straightening them out. And no matter what you plan, expect EVERYTHING to take 35% longer than you budgeted. In my experience this rule is recursive: if your plan takes a 35% buffer into account, the actual project will take 35% longer than that. At least.
Small teams mean small budgets, but they also mean BIG interpersonal issues. There's no place to hide on a team of 6 (as opposed to AAA teams that number in the triple digits), so if you don't pull your weight the whole project immediately suffers. Similarly, if your artist and your programmer can't get along, production will suffer. You need people who are committed, cooperative, positive, patient, but most of all self-motivated and honest with their team. With this tight schedule you don't have time to screw around... There's a lot more emphasis on initiative when you have a small team, and you will want to hire some veteran talent to lead this team.
And on top of that, you need to be doubly sure of your hires in a small team. If you have to loose a programmer in mid development on a big title, the sixty other programmers can pick up the slack over the next 16 months of production until you find a new hire. Loosing a member of a small team with no backups means production can be completely halted while you restaff...
I don't know your situation, but I think a better course of action for you is to plan for and develop one mobile game on a quick time table just to see if this is even possible for you.
Okay, I'm actually working myself into an anxious frenzy just thinking about your task at hand. If you really want to make this happen, do some more research, talk to some more people, and look at the schedules or post-mortems for games you've played to see exactly how big of a thing you are jumping into. Check out Gamasutra.com, they have a great post-mortem section, and some awesome articles about game development. And good luck!
CyriusLee3 karma
I completely agree with blackley1, except I think you need even more time for polish.
I just wrapped up on a sixteen week project developing a mobile game for a children's museum. We were a team of six: a producer/designer, an artist, a tech artist/programmer, two more programmers specializing in database construction and a UI programmer. We spent 6 weeks designing and iterating until we had what we thought would be the final product, and then we spent 10 weeks polishing and tweaking. I should mention we were play testing designs starting on week 2. Trust me, this still did not feel like enough time.
If you really want a schedule like that, you need to structure your teams well, making sure each team has the skills it needs to make the game it is working on. I'd say bare minimum a designer, an artist, a programmer, and a sound designer (sound is so effing important!). If you can double up, get another artist or programmer. For this project, I'd argue for teams of six, with everyone able to wear multiple hats. On some level you will also need someone to handle production for these teams to streamline their process. Depending on the size of the game you want (and if you want a game a month, they WILL be small games) you need to work multiple teams simultaneously on a revolving cycle (check out how Telltale developed the "Walking Dead" games). You should have another small team for solely for play testing (you may think you know what's fun, but you never really find out until you put your game into a user's hands...). And you will need to continue streamlining your process as you go, finding out where the kinks are and straightening them out. And no matter what you plan, expect EVERYTHING to take 35% longer than you budgeted. In my experience this rule is recursive: if your plan takes a 35% buffer into account, the actual project will take 35% longer than that. At least.
Small teams mean small budgets, but they also mean BIG interpersonal issues. There's no place to hide on a team of 6 (as opposed to AAA teams that number in the triple digits), so if you don't pull your weight the whole project immediately suffers. Similarly, if your artist and your programmer can't get along, production will suffer. You need people who are committed, cooperative, positive, patient, but most of all self-motivated and honest with their team. With this tight schedule you don't have time to screw around... There's a lot more emphasis on initiative when you have a small team, and you will want to hire some veteran talent to lead this team.
And on top of that, you need to be doubly sure of your hires in a small team. If you have to loose a programmer in mid development on a big title, the sixty other programmers can pick up the slack over the next 16 months of production until you find a new hire. Loosing a member of a small team with no backups means production can be completely halted while you restaff...
I don't know your situation, but I think a better course of action for you is to plan for and develop one mobile game on a quick time table just to see if this is even possible for you.
Okay, I'm actually working myself into an anxious frenzy just thinking about your task at hand. If you really want to make this happen, do some more research, talk to some more people, and look at the schedules or post-mortems for games you've played to see exactly how big of a thing you are jumping into. Check out Gamasutra.com, they have a great post-mortem section, and some awesome articles about game development. And good luck!
View HistoryShare Link