next »

[Jacob_]

What do you work on most often--simple games or complex ones? Right now I'm trying to build a portfolio to establish myself as a game developer, but at the same time I like the personal enjoyment that comes from creating, testing, and releasing a multi-month undertaking.

[flavio]

We're working on a simple game. The general advice is to start with little projects (look for example here, #5). If you work on all parts of a game (including releasing, promoting, ...) surely you have a multi-month effort also for little projects.

[ஒழுக்கின்மை (Paul Eres)]

i think it depends on a person's personality or style -- some people are better at short games, some people are better at long games. try both to see which you are better at

[Alistair Aitcheson]

In the past I've tended to have one big project on the go while I work on a bundle of small ones for competitions and things.

These days I seem to be working mostly on smaller projects, as I want to explore a little bit more. I've also found that polishing smaller projects can take quite a while, and they can become quite big in the process!

I agree with Paul Eres, you should try both and see which you prefer. Working on small projects can give you good scope for experimenting, but there are lessons that can only be learned from large, ambitious projects. Perhaps you could work on a few small projects, pick your favourite and develop it into something much larger.

[baconman]

IMHO, most really good "big projects" are just small projects that are taken to a huge scope over time; or a number of small projects all successfully meshed together.

[Alistair Aitcheson]

IMHO, most really good "big projects" are just small projects that are taken to a huge scope over time; or a number of small projects all successfully meshed together.

That's a very good point. World of Goo, for example, was originally a 7-day project that expanded into a much bigger project after an excellent response from players. If they hadn't spent the time trying out a variety of short experimental projects then it wouldn't even have been started, let alone be as fresh and original as it is.

[Snakeyukin]

For a while I've been trying to do large/complex projects, but recently that's been changing.  I always have issues with getting and/or keeping people on the team.  After a while, people seem to get complacent or bored with the game and just leave or never want to respond.

Smaller projects allow me to often just work on stuff myself or just with one or two extra people.  Though it is often hard for me to keep stuff short.

[Richard Kain]

It really depends on your personal preferences. If you want to populate a portfolio quickly, obviously a lot of smaller projects is the fastest way to do that. At the same time, larger, longer projects make for better, more impressive portfolio pieces.

I think a good balance to strike would be to have one big project that you go back to regularly, and several small projects that you work on to take a break from the big project. Big projects can burn you out if you work on nothing but them. Having some fun small projects on the side provides a worthwhile distraction, without requiring too much of a time comitment.

Right now I'm working on a fairly large engine port. It is a pretty big project that is taking me months to complete. But I have several fun side projects that I use to "rest" from the big project. One of them is writing a guide and taking screenshots from one of my favorite point-and-click adventure games. (for Giant Bomb) Both these projects can be used in the future as examples of my work.

[Taiko]

I've heard the biggest problem with new game devs is that they don't finish what they start.  So I think a small game is usually best, at least for the first few projects.  Once you get the hang of it then start going crazy.

But even when you make a big game, always do a prototype early on.  Otherwise you might find that your big concept isn't that fun in reality.

[InfiniteStateMachine]

yeah finishing is the most important thing.

I did one game that was large in scope, ended up taking 4 years with a team of around 10 active at any one time.

Since then I've been doing flash/XNA games with very small scope, really refreshing.

Finally getting into another larger scope game, but even then I only plan about 6 months to a year for one coder and one coder/artist, not including the engine.

[supershigi]

Well, at present I've been working on a fairly lengthy rpg for the past few years.  I'm hoping to finish it by the end of 2010, and I have to say that it was not the best first project, haha ^_^;  I guess on the upside it helped me learn a lot, and it's definitely teaching me more about discipline and the importance of setting self-imposed deadlines.  And I'll definitely be happy when people can play the entire game.  But for sure it's a lot easier to bring yourself to finish a game that doesn't have such a long development cycle, and I think finishing is often times the most important thing.  Once I'm done with my game, I'll probably indulge in a bunch of shorter projects.

[Alec S.]

I started quite small (prototypes and such) and really just built myself up in size.  But I feel I naturally lean towards larger projects.  Not necessarily year long projects, but games that are fairly level-design/content focused.  When I switched from small SHMUPs to platformers and action-adventure games, it felt a lot more natural for me.  But, of course, I occasionally bit off a bit more than I can chew and tried to make a game too large and realized part way through that the foundation of the game wasn't very strong, and content creation was becoming a less and less smooth process.  So, I guess I'm still building myself up, but with larger, content focused games rather than quick arcade-style games.

[iffi]

Big projects, with small ones when ideas come up to prevent becoming bored of the big project.

[JJames19119]

Small, simple projects aren't fulfilling enough for me but I can see the appeal behind them; a community I used to go to would have an occasional competition to see who could make the best minigame, and the results were compiled into this Mario Party/Warioware-like final game. It was good fun.

[InfiniteStateMachine]

Big projects, with small ones when ideas come up to prevent becoming bored of the big project.

that's a good way of putting it

[Rob Lach]

i'm working on 1 big with a team and 1 small alone. I jump between the two depending on how i'm feeling

[ink.inc]

Petri Purho's Crayon Physics is a perfect example of a small game turning into a big project.

[mirosurabu]

I have a lot of ideas. It's hard for me to stick to one for a long time. So small suits me better.

[Davioware]

Small ones, until you find a small one that's really good and worth turning into a bigger project. Only then do you go big.

[VomitOnLino]

Small projects.

Not everyone has the time to dedicate vast amount of hours to their project. Also in the end I'd rather have a small but polished project, than a big one with lots of dead ends and half-baked solutions.

Or to put it another way, small projects allow you to be much more flexible. For example if I get lots of criticism over a feature/mechanic, with a small game, it's quite easy to toss it out. For the big project you'd probably have to do tons of restructuring - and in the end you'd not even be sure if it's the GOOD thing to do. Eugh!