I'm working by myself. I'm a programmer. The great thing is I've already bought all the graphic assets for my game, so I've practically taken care of the artwork side.

But I'm wondering, is there a limit to what a single person can do programming a game? Obviously it might take more time, but are there things that require multiple people to do?

I know I have to take care of the sound/music. But as far as programming goes, are there any roadblocks that might require more than one person on a team to accomplish properly? I often make the mistake of getting in over my head, and I want to do what is within my means of accomplishing by myself.

Here's a more concrete question. My game will be similar to pokemon, except you collect spaceships. Do you think one programmer could create a Pokemon game if they already have all the sounds and graphics they needed?

Braid was one person. Minecraft started as one person, and grew after its popularity exploded. Fez was one person. Rollercoaster Tycoon was by one person - and in assembly, no less. The majority of indie games are probably by a single programmer, in general.

Hi Patliteon, my two cents about working alone on a game, how much you can or can't accomplish, and generally good practices for completing your projects:

I've struggled for years with completing my projects. I only have two finished and released games so far, even tough I've been doing game development as a rather serious hobby (more than a work-day every week) for around five years now, and they are pretty small (links in my sig.). So for close to four years I did not complete anything, regardless of working regularly. I'm telling this because to complete a lengthy project, and to measure how much of it can be realized by one person a lot of "good practices" has to be embraced first, and a lot of "bad habit/practice" has to be let go!

These are the reasons, which lead me to never completing a lot of projects, and the conclusions or "good practice" I do since to avoid these pit-falls:

1. Not really knowing what I really wanted to create. Sounds funny, but "I would like to do a game like Diablo but with a different leveling system" is extremely vague, and even tough I usually had a better idea than this sentence, but not as far as sophisticated as the ideas/plans I've created for my last two projects.
   This lead to a lot of ad-hoc work sessions, and programming stuff without clear goals, like: okay, I'm going to work on an item system for my Diablo like game, but I just zealously engineered and coded systems, that could support a myriad of games, because I had no clear vision/idea/plans!!!
   ->
   To avoid this problem, I wrote a thorough GDD for my last two games. The detail can vary of course, allowing you to be flexible with design changes later on, but to actually be able to work on every part of the game, and be able to tell when it is done, you at least have to come up with a sentence or so for every aspect of the game beforehand, otherwise what it is exactly you are working on?! This may sound like a huge amount of work, but trust me only spending a day on writing down a more clear idea of the game makes a huge difference, and one day compared to months of work is nothing...
   
2. Too ambitious. "I would like to do a game like Diablo but with a different leveling system" is nice and all, but as an example Diablo 2 (postmortem) had 40 full-time developers working on the game for 3 years. If we cut out some or all of the content (graphics, music, sound, design, writing etc...), we still need around 10 full-time programmers and 3 years to complete the game. If you have, as in my case, a day every week, you are only capable to do fourth or fifth of a full-time programmer. This means Diablo 2 would take you probably 10 to 15 years :blink:. Good luck :unsure:.
   Off-the self engines, tools, samples and other technology can help here, but still only cuts the task in half maximum, tough it is important to work in an environment which makes you (feel) productive.
   ->
   To avoid this problem, accept the fact, that you are but one person, and do not foolishly underestimate the task ahead or the work/skill of others! There are two ways once you have done that:
   
   - Reduce the scope of your game to a size, that you deem acceptable and are able to complete. This is tricky, and hard to do right, but a GDD can help a lot :wink: :P, since you will have a much clearer view on what tasks you have to complete, to create your game. It is enough if you "guesstimate" the time it requires to complete the tasks at first, since the time magnitude (if it takes 3 or 6 moths or more than a year etc...) of the whole project will be somewhat correct, and than you can cut features from your design/idea/GDD if it is an endeavor you would not like to take. This also helps you identify the core/important aspects of your game idea, and maybe it can help you focus on the important parts of the game.
   
   - Team up with others if you do not want to reduce the scope of your game.
   
3. Not tracking progress, and slowly loosing interest...
   Working on a "shaky" idea for months, not knowing for how long will it take (at least approximately) + having no clear idea what parts are finished is really nerve-racking. I usually lost interest after a while in case most of my failed projects. My biggest project, which failed, was one of the most heart-breaking, since I kind-of followed my #1 and #2 advice, but I never tracked the completion of the project, and after working on it for close to a year! I lost interest due to not actually knowing how much more it would take to make it really shine. It was progressing well, but it did not yet feel like a complete game after a year of work, and even tough I estimated an approximate 1 or 1.5 years of work before jumping in to the project, after a year I still couldn't really tell if it is going well or if I'm going to have to spend another year to complete it. This doubt slowly killed my interest :(.
   ->
   To avoid this problem kill doubt regarding project- time/life-cycle! Even a txt file with a list of high-level tasks, with estimated approximate time it takes to complete them and a * character as an indicator of completion helps a tremendous amount to keep you motivated, and to remind you of how much you are actually progressing!!! You can go extra sophisticated with an excel sheet or google docs (or a tool like Trello custom built for task-tracking), which gives you color coding, and fancy functions to have some statements about your progress, and the tasks left TODO. This also allows you to easily "re-plan" if you realize something is much more complicated than expected. With a couple of calculations you immediately see, how much more it would take to get to the end of your projects by increasing a couple of counters, and if you dislike the idea of broadening your scope/project-time, you can cut some of these features.
   Again, this takes almost zero effort (a few minutes every week/month and upfront to setup), but it gives useful intel and a huge moral boost!

This is my "three most important practices for completing your projects" wisdom, I learned and put together in the last few years. Yes, it actually took years of practice to learn these, because you can read a lot of similar best practices from other developer, and say: "this is a cool idea, I think I'm going to try this...", but you never really try them (happened to me at least), or you never tailor them to your needs and never make a habit (a practice) out of them in your own work-flow, only after a few failed projects <_<, :lol:.
So my advice is to be smart about this, work smart :wink:!

+
Short list of cool indie games from the last couple of years, made by one or two people (lot more exists, but these came to mind):
Towerfall
Spelunky
Dust: An Elysian Tail
Fez
Super Meat Boy
Braid
Papers please
Aquaria
Nidhogg
To the moon
Of course, some were made by long time professionals, or over the course of many years, but still, if nothing else, this surely proves the possibility...

Br. & sorry for the long post ^_^.

One programmer as the core of the team can do amazing things. It isn't an easy road to go alone, but if you take care with your code design*, and keep things nice and modular and reasonably reusable, then it is possible to keep building on things over years and putting out really neat things that customers enjoy.

* And comment the hell out of your code, and clearly state what the code was SUPPOSED to do. "Self-commenting code" is a great theory, right up until the point that you discover a bug and think you trace it back to code you wrote five years ago...

But another key thing to remember: Just because the core of the team is small doesn't mean you can't have a LOT of people working on the project or otherwise involved in it. I picked up a copy of The Banner Saga awhile ago (Core team is 3-4 former BioWare employees I think) and was surprised at the length of the credits for the game. Sure, most of them are the random Kickstarter backers, but between the programmer, designer, artist, and composer is a very long list of musicians, testers, friends and family, and key supporters.

The Banner Saga is another example of "Previous experience in a company", but I feel the point which many miss about that aspect of it isn't the programming and development experience you gain from working in a company. You can gain loads of coding experience while working on your own and posting to the forums here or getting involved in StackOverflow or something. What you Don't gain nearly as much of from that is the networking.

Working all alone makes it hard to build that key skill of "I know a guy..."

Need a massive orchestra for all the music in your game? Well, do you know anyone involved in an orchestra?

Need impressive vocals and high end audio work? Well, do you know anyone in that field?

Possibly my best advice when it comes to small team/no team work: Get outside input on your project early, and get input often. Be prepared to accept harsh criticism. and be willing to accept that your first few runs at it are failures. If you really want to go at it all alone, then be prepared to accept that you had VERY stupid ideas, and be ready to drop them as soon as you can. If you are the one wearing all the hats and solving all the problems, then you are most likely going to take longer to finish everything and put all the development fires out. While you might be able to do more in two years than what two programmers could in just one year, it is still going to take a 'very long time' to complete a project that a team of 40 spent 3 years on, and it is better to accept that your game sucked after 3 months than finally admitting it 5 years later when no one wants to buy it.