next »

[PythonBlue]

I've been giving this question a bit of thought, lately. I've been busy with a few free projects, but the longer I'm involved with them, the more I doubt they will be finished. I've been involved with a total of ten projects that I can even mention without business risks, and only two of them have since made progress to the point that they finished.

Therefore, I must ask: should I withdraw from some of these other projects for the reason of building my portfolio quicker? Part of this urgency is the result of my hope to attend GDC this March, for which I'd need to have a portfolio of prior work accomplished if the people there want to consider paying me attention.

So, what are the signs of an unlikely-to-finish project?

[J-Snake]

It personally doesn't impress me when someone accumulates a lot of quantity work. May be it is a required quality for rapid flash-game development or something like that. But it doesn't proove one is capable of creating a competent game.

Better do few games but do them right. A developer of notice is mainly known for doing one or few things really well, not for quantity of things. As example John Carmack for Doom-like engines, Hideo Kojima for Metal Gear Solid and Notch for Minecraft.

It is just my line of thinking. Feel free to take it if you see personal value in it.

[Muz]

Eh, instinct works far better than a 'symptoms checklist'. If you don't feel it's going to be done, it probably won't.

Better to look for the signs of a likely-to-finish project: Constant updates, enthusiastic/obsessed leader.

[zalzane]

So, what are the signs of an unlikely-to-finish project?

When you're having more fun programming the project than finishing it.

When you think you'll have a playable prototype within the next 2 years.

writers block, someone else think of some more

[Mittens]

-project scope size is larger than 'small' (big and even medium sized games never get finished by indies )

-the game requires artists make lots of tedious assets (like rocks, sticks, trash cans, hundreds of character animations, lip syncing animations, etc.), this is often the case with any game trying to be realistic or attempting to be a film like production

-the game requires programmers to perform tedious coding tasks

-as the game is being developed it can't be seen 'growing' in stages, it continually asks that developers just keep on working until it all comes together at the end and makes it all worth it.

those are just a few quick examples off the top of my head of things that will grind down a dev teams motivation for work and life and then probably, eventually make the project fall in a heap.

Once I started working on a game project that I was part of designing, and while we were all collaboratively designing this game it seemed like there was nothing wrong with the idea

and then we started work...
and I realized that completion of this game required me to 3D model and textures heaps of assets which where things like rusted bolts and rocks... not the kind of stuff you are going to have in your next 3D modeling showreel

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

this would be my list of clues that a game is not going to get finished:

- there is no devlog, or the devlog is not active and hasn't been updated in months
- there is no design document or outline or plan, or not even a to-do list
- most or all of the work so far has gone into the "engine" rather than actual game content
- the game is still less than 10% complete even though it has been in production for a year or more
- it's being worked on by someone who has never finished a game before, particularly if that person is the team leader
- the team size is greater than 7 or only a single person (games with huge teams and single-guy games very rarely get finished; the sweet spot is 2-5 team members)

[feminazi]

when paul eres tel u ur not gona make it... ur not gona make it

[Ant]

am i guna mak it pauly?

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

just go through my list of clues. if half or more of them apply to your game, it's not going to make it. if only one or two apply, it might make it, or it might not. if none apply, it'll make it.

[PompiPompi]

It probably depends on the person as well.
You must be enjoying making the game. It doesn't matter how small the game is, if you are not excited about it, it will take you ages to complete.
That being said, it doesn't mean you need to take big projects, because those are very hard to complete as well.

I would say it has to be both something you are excited to work on, and realistically doable in scope.
There are also other factors that drive a person that change from person to person.

Sometimes when you are stressed about something like making money or being successful or making a show reel, you make the wrong choices when choosing what to work on. :/

Bottom line, you need to find your "true" drive to finish the game and to choose a game scope you can logically think you will be able to finish.

[Evan Balster]

Are the individuals whose contributions are critical to completion motivated to work?  How many critical individuals are there?  (Each adds risk.)  What about the features and content necessary for the game to be playable or complete?  (Each of these items adds risk.)  A game whose appeal stems from a wide variety of mechanics or a large volume of content is riskier than a game designed to do one thing very well.

Better start that devlog soon. 

[J-Snake]

A devlog is the most unnecessary thing, personally. It is tempting to consider it just a fetish.

[sublinimal]

It personally doesn't impress me when someone accumulates a lot of quantity work. May be it is a required quality for rapid flash-game development or something like that. But it doesn't proove one is capable of creating a competent game.

A-ha, but the developers that manage to create a dream game always have tons of experience beforehand. Typically includes a boatload of finished & unfinished smaller games, many of them unimpressive in isolation. And when we're talking about portfolios, playable things are more valuable than an unfinished "next Minecraft".

Rather than wondering about the signs of a failed project (which Paul Eres answered well already), my biggest question is why PythonBlue would feel pressure to attend GDC if he doesn't have anything to show.

[Klaim]

Better start that devlog soon. 

About that, I don't totally agree with J-Snake but I have a hard time figuring out what to devlog about and in the end I don't, even if I'd like to. I feel like I would be talking about uninteresting stuffs, because the game is not finished yet.

How do you decide what to devlog?

[Gregg Williams]

How do you decide what to devlog?

We're experimenting with that. So far we are treating the devlog as pretty loose and including technical/design discussion as well given the tig audience.  While at the same time we do weekly blog status posts that cover all of our current projects, and we try an keep those less technical, and more gamer/consumer focused.

As far as signs of unfinished projects, I'd say lack of momentum and communication are probably the biggest.

[Evan Balster]

I think a devlog is both a means of creating accountability for one's progress and a very good way of potentially marketing a game prior to release.  The material needs to be interesting, though, and a good devlog is a ton of work.  The payback can be awesome, though, as companies like Wolfire have shown us.

Supertangent re: going to GDC, having things to show helps with starting conversations but little else.  It's perfectly justified to go without anything to your name, as long as you can engage with people.  Knowing someone who can introduce you to other people helps to get the ball rolling.  Failing that, be bold and introduce yourself to some other folks.  Find people with common interests.  Getting rolled up into groups of indies who walk around the town and conference together is also a great way to meet a ton of people fast.

[Uykered]

I like looking at devlogs but don't think I'd ever make one, I'm not fond of spoiling anything.

[Klaim]

I think a devlog is both a means of creating accountability for one's progress and a very good way of potentially marketing a game prior to release.  The material needs to be interesting, though, and a good devlog is a ton of work.  The payback can be awesome, though, as companies like Wolfire have shown us.

This is difficult to discuss because when you are talking about interesting progress, I don't know what it means. For example I achieve a lot of progress in the last months, but I can't show a screenshot because nothing I done was graphical, only game-specific code that need to exist before graphics. I am very tempted to talk about the technologies behind it, but in the same time I don't see anyone other than a programmer even understanding the posts.

So, to me it seems that you need to get to a first playable or something visual before starting the devlog routine, which can be early or not depending on the kind of game I guess (and if you have an artist working in parallel, which I don't).

[feminazi]

create an actual devblog liek paul eres's world famous livejournal http://rinku.livejournal.com/ . posting a devblog on tigf just feels liek ur competing with a bunch of dums for attention with pretty screenshots.

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

Better start that devlog soon.  

About that, I don't totally agree with J-Snake but I have a hard time figuring out what to devlog about and in the end I don't, even if I'd like to. I feel like I would be talking about uninteresting stuffs, because the game is not finished yet.

How do you decide what to devlog?

like eva said, check out mine. it doesn't have to be interesting to anyone; it's just a log. i think too many people see their devlog as an extension of their marketing or promotion. it's not. it's intended to be a useful record of what you did each day, not some type of advertising tool

the bolded/colored number that appears in my devlog is the number of tasks remaining on the to-do list. when it reaches 0 i'll put the game into beta testing.

if you don't like spoiling anything, don't spoil anything (just allude to it), or keep the devlog private for your team. there's nothing saying a devlog has to be public (i make mine public just for accountability though, to show i'm actually working on the game every day)