What is the longest you've spent on a game development project? Do you prefer to make smaller games or do you spend most of your time pursuing a giant "dream" project? Personally I'm doing the latter for now just because the challenge is so alluring(as long as I'm enjoying it, I'm fine), but with that said, creating any full game, no matter how big, can be a challenge. I just like the idea of having a project that can be completed but still have lots of room for improvement. After I'm done with this project I'll probably try to make smaller games though(perhaps mobile ones). I was just wondering about your guys' experiences with small and big projects, how you have managed your time with your projects, whether you have finished what you consider to be a "huge" project, or if you plan on tackling one in the future.

The question sounds like it was more directed towards indie game devs, but feel free to share your experiences with all kinds of game development.

When i was a newbie i always aimed for higher projects and wanted everything to be cool. I was learning SDL and i never completed the basics and i just jumped into making a Top down shooter game / Shoot em up, It all started well but for 1 month i was stuck with the same project and eventually had to drop it, I felt so bad and learned a lesson that i would never aim for higher projects, unless i have learned everything.

Always make it small, make it interesting

I spent a year and a half with my first game and first ""big"" project. It was a Scorched Earth clone with many features. It was nothing fancy looking, but it had cool features like AI, GUI many weapons, themes etc. It was pretty much finished, fortunately I was always able to set realistic goals. It took 1.5 year because there were many long pauses, and it was only a hobby project.

The next finished game took about 3 months in a slow pace.

My longest-running project was a Half-Life 1 total conversion, which took about 4 years, part-time while studying. The biggest problems were:
* Finding other people who want to work on a project for years with no compensation and no guarantee it will even be finished. We probably had a team of about 6 people at any one point in time, but all up, the team would've been maybe two dozen over the life of the project.
* Scope-creep -- it's too tempting to always add that new cool feature, instead of fixing the bugs in your existing features. We kept pushing back the v1.0 release date for months/years, as new features+bugs were added.
* Large scale spaghetti code issues -- as a newbie, I wasn't yet talented in the craft of large-scale software engineering, and hence I laid the groundwork of the project with dangerous, badly written code, which could easily manifest as a new bug at any time. The result is that the code-base becomes less and less flexible over time, until it reaches the point where developing new features, or fixing critical bugs becomes simply too time consuming. Learning these mistakes on smaller projects would've been more productive ;)

The longest project I worked on was Quackoo, a long but forgotten project. It was a game where a bird and a tie fighter would battle. The game took me about a year to complete because I was new to programming. I used Borland C++ Builder 3 and boy did it suck! Not really intended for games. I was also going to school at the time so I couldn't work on it as often as I wanted.

The longest project I worked on was a 2D ORPG, where I spent 4 1/2 years on and off working on it with other people (I wasn't the programmer or the project lead).

Problems encountered: Lack of motivation when nobody else is working but you. Chokepoints in development, where nothing gets done in a certain area because only one person can possibly implement that, and he's not available and wont be for ages. Lack of overall plan and direction for the game. It was supposed to be a zombie game (humans vs zombies) but we all just added magic, and it ended up being a fantasy game with magic, where everyone is zombies for no discernable reason. Towards the end of the project, we knew we had to refresh everything, so we deleted the world and started afresh to make it truly be a Zombies vs Mutant vs Humans online RPG. By the time we had actually organized (3 1/2 years late) and got ready to go, we were all burned out on the project.

Lessons learned: Plan out your game world before making in-game maps.
(Also learned a little about how to get along with teams, and how to delegate tasks down the command chain, and how to interact with the players (all 11 of them! Our game was playable and enjoyable with plenty of content (before we deleted the world))

---------------------------

The longest solo project I've ever worked on is my current project. (21 months so far)
First six months: Playing with code, writing a 2D map editor, unsure what I was making.
Next six months: Rewriting the code I earlier wrote since now I knew I was making a 2D tile-based RPG. Also busy writing the game code itself.
Next seven months: Busy with life in general, and caught up for an unexpectedly long time working on side-tools.
Past two months: Back on the project directly, and making progress, but regretting the large chunks of wasted time scattered throughout the previous 17 months.

Problems encountered: Lack of clear direction (eventually I came to a direction, but still being resolved), lack of overall architecture design (Again, eventually I grew a clean and stable architecture, though additional areas are yet to be coded)

Lesson I'm hoping I'll learn: Plan out a project before starting. Plan out the software architecture before coding.


---------------------------

The longest solo project I've ever completed: A 2D space TBS game called Celestial Conflict.
Problems: Spaghetti code. Everything a mess. The more the code-base grew, the less work I got done and the more I had to fight it.
Finished it in 6 months. (I happened to know what I wanted when I started making it, so it didn't drag on for too long, but it seemed like a long time having to fight the code to get anything done).

Lesson learned: Program clean and maintainable code. Refactor messy code as soon as convenient.

...

Why not engage in smaller, more manageable projects?

[quote name='Servant of the Lord' timestamp='1331003767' post='4919664']...

Why not engage in smaller, more manageable projects?
[/quote]
The game I'm currently making, I'm hoping to sell commercially.
Since I'm now working on it full-time, instead of part time (as previously), I'm hoping development will go faster.

However, I'm expecting my next two or three projects to be greatly reduced in development speed because I will re-use the same codebase from my current project for their development. My current codebase, if used for the same genre of game (2D turn-based RPG), wouldn't need to be modified much for the next projects and the code is clean enough (compared to my previous projects) that it wouldn't be much of a hassle.

Eventually, I want to move on to another genre of games that will require a new codebase. I tend to think that this is how my development cycles will end up going:

• Longer development time to create a new game (1.5 - 2 years)
  
• Short dev time to create a similar genre game (0.5 - 1.0 years)
  
• Slightly shorter dev time to create a similar genre game (0.5 - 0.75 years)
  
  
  
  • Long dev time to create a game of a different genre (1.0 - 1.5 years - Hopefully I'll get faster at developing)
    
  • Short dev time to create a similar genre game (0.5 - 1.0 years)
    
  • etc...
    
    
    The games I want to make can't be made in a month or two. On the other hand, they should take much less time then it currently takes me, if:
    
    
    1. I plan them out in advance
       
    2. I work on them full-time (like I am now currently doing) instead of part-time
       
    
    ...and because as I do it more, I naturally expect to get somewhat faster.
    
    One idea I'd like to try sometime, is working on a medium-sized project, and giving myself these goals:
    
    
    • 1-week to design
      
    • 1-week to plan code architecture
      
    • 4 weeks to code
      
    • 4 weeks to create content
      
    • <---Heavily playtest--->
      
    • 2 weeks to add new features
      
    • 2 weeks to add new content
      
    • <---Heavily playtest--->
      
      ...And repeat as many times as needed to polish, expand and bring to market.
      But I've never tried that method yet. Giving myself short-term deadlines, and moving in cycles would be an interesting experiment for me.

Oh god, don't remind me...there's a 3D racer project I've been working on-off for about 3 years I think:

Restarted about 3-4 times, recruited a team to help me at some point, dismandled the team because there was no solid direction(mainly my fault), kept working on my own, gave up, restarted, gave up again...mainly I'm frustrated because I can't get it to work exactly like I want to. Right now it's again in 'abandoned' state, and I don't have much inteest in it anymore to enable me to work again.

I win the game (so far)! I've had an adventure game in development off and on since around 2005. Basically a side-project I put more work into whenever I have the time to spare, which isn't too often. It doesn't really bother me that it's taking this long; there's no urgency to complete it, and I'd rather it be the best game I can possibly make it rather than set my sights lower in order to get it out sooner. Progress is reasonably steady and there's an end in sight, but I'm not going to stress myself over it when I've got more lucrative projects in the pipeline.