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.

Nothing I'm aware of in game development requires multiple people to do. It's not like moving furniture where a single person can't hold up both ends at the same time. There are no hard constraints like this in game development (other than your lifespan).

You require the full skill set that your game requires, but that's manageable.

It's surprising how much time is consumed by coordinating the activities of a team. I've seen large, 'professional' teams where I work self-destruct under the weight of their own coordination overhead. The best thing about working alone is you eliminate all of the overhead of waiting for other people. You either know what you're doing or you don't, there's nobody dragging you down, and you're not dragging anyone else down either.

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.

Be careful with those.

Braid's John Blow had been building games since childhood and was a professional dev for a decade and had a column in Game Developer Magazine. It took him 4 years, all his cash reserves and debt, he spent over $200K and was deeply in debt. If the game failed he would have been bankrupt.

Minecraft's "Notch" Persson had been programming since childhood, had worked on several major titles as a professional developer and startups. He founded a small company with startup money and debt and long hours himself over three years, took on extra people by a "soft launch" of building a product while selling it in an incomplete state.

Roller Coaster Tycoon's Chris Sawyer had been doing contract game publishing since 1983, and in 1994 decided to build an engine in assembly, releasing the game in 1999.

Fez's "Phil Fish" got an art degree focusing on digital arts, worked at Ubisoft and other companies, and had some significant experience. He spent five years building the game, again investing nearly everything he had while being very public about development and getting funding early from indie awards and private funding.

Many of the early console games through the 1970s and 1980s were developed by single individuals over the course of a few weeks, but those people were intimately familiar with the hardware and its use. They were experts in a tiny field and spent their days figuring out microsecond timings of the CPU instructions they had memorized.

So while a single individual can do many things, note that these individuals were already experienced industry professionals rather than beginners, and many of their initial projects were small, still required many years, and often consumed their finances in the process. Most of these projects leveraged shows and events and aimed for early awards to get some funding and arranging publishers through the years of development.

Sorry, getting back to the subject, it does not matter so much what others can do in that time frame. You need to figure out what you can do.

It seems the easiest way to do that is to set a one month time frame. Do what you can during that month, and at the end of the month, stop. Take stock of what you did, set it aside. Then the following month, do a new project that you think you can accomplish within a month. In just a few month's you'll learn what your approximate pace is.

Professionally, many software businesses run in two week or three week "sprints". Done well, everyone will review what they have accomplished and quickly learn what they can accomplish in that time frame. Better developers use it to learn how to better plan. Better managers use it to estimate what the team can do over the length of the project. Sadly, many people see the process as a waste of time, or otherwise miss the opportunity to better themselves as developers.

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 ^_^.

Yep. Above guys are right, especially about the coordination. I'm doing art and programming. I have a modest budget which I planned on using to hire extra help with art, but alot of the time as I'm working I think about the style and technical notes I will need to make for the assets that I'm planning on having someone else do and I realize that it will take more time to explain than to do it myself so I end up just doing the asset myself.

One example: I'm working with sprites. Low resolution, but lots of different animations. Animations have in-betweens, use color palletes to swap colors.

I need to specifiy that the artist can only use specific colors (due to palette swaps), i have to make notes for each animation which frame it will follow when the animation starts and ends. I have to make notes about how offsets work (for when the total animation's vertical height is actually taller than the sprite sheet, IE: climbing a cliff, etc - where the character would actually "climb" out of the frame.) And I need to specify that the animation needs to be X-to-Y frames long. (since the code is already done with placeholders as art. I can remove frames, but not add them ) Whether or not frames from other animations can be recycled, and whether or not the animation plays forward->stop or forward->backward->stop, whether it loops. etc etc.

And that doesnt include the style sheets.

All of that for each animation needs to be specified. Some animations are only 4 frames long. Often it's faster to do it myself than to even bother documenting it, finding an artist, negotiating, payment, corrections, contracts, etc..

Yes, if you already have the music and art assets you are good to go. Just make sure you keep it small and it will get finished.

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.

Mobile game development, or mobile-style game development (bigger market on mobile).

Even then, it takes a lot of time, effort, and money, especially for single person.

The biggest drain in time (and therefore money) is assets. If you can somehow make a good fun game with very few assets, or at least a prototype (E.g. Geometry Wars).

Tetris, angry birds would be that kind of game I would aim at.

Something that's basically doable as a quick game design competition entry (game jams), and can then be expanded on to a fully fledged marketable game if the concept has staying power.

Even game jams can be a pretty tall order, and sometimes require a small team (couple of guys, artist and programmer).