Hi all,

I've got some general questions for everybody.

Do you find yourself constantly switching from project to project? Do you start new projects before finishing your last (and then rarely return to the old projects)?

If so, why do you think you do that? Do you get stuck? bored? Did you not plan well enough? Are you limited by your tools/resources? Please elaborate.

If this does NOT describe you, or it DID, but doesn't anymore, please, share with the rest of us how you stay focused and disciplined enough to finish your projects! We want to be like you.

:p

Please tell me your secrets, I can't stick with anything!!!

I have amazing ideas, and the tools to make them reality, but I just randomly quit, even if I'm enjoying it! :(

Hello,

I used to diverge from project to project because I find my old project lame and at the same time want to pursue on a new one because some new idea struck me. Yet, when I go about the new idea, I find it old and another newer idea pops in the back of my mind.

It goes in a circle with no real end...

So, for me, I kick myself in the a$$ and tell myself to start a project and stick with it until it is at a level I am satisfied with. Also made a list of things I need to do to help keep me in track.

I'm pretty new to this whole game development thing myself... but i'll tell you a little of my story.

I've wanted to be a game developer since before I hit puberty, it was the controlling force in my life, the reason I went to college, the reason I picked the degree I did, the reason I associated with who I did, it was a big part of my life.

Naturally when I wasn't doing homework I was working on some game project or another, typically the cycle would go like this.

"Hmm It would be sweet to make an isometric shooter game, I’m going to make an isometric level editor and scrolling engine" *hack*hack*hack*hack* "hmmm that didn't work" *hack*hack*hack*hack* "oh hey, its working! now to add players.. uh, I didn't even thing about collision detection, this whole project needs to be re-written and I don’t have the heart"

…and on to the next project I would go. As I worked my way through college I became more mature in how I coded, I learned to plan first, use good programming methodologies, and good object oriented design.

I had never attempted anything the scale of Katsu's Journey when I started, but I planned first, commented well, and took the extra effort to code things right the first time. This made it SOO much easier when I came to a point where I realized I had made a bad design decision and had to back up and make some changes. Because the code was well abstracted, I could go make those changes in a short amount of time. This helped me keep my interest, If I was constantly working through spaghetti code I would loose my motivation quickly.

From the outset of the project I determined that I would finish this project no matter what. Failure, exit conditions, end game, none of these ideas was even on my radar. The only option I allowed myself was the option to keep moving forward and finish. It takes a lot of stubborn and i mean STUBBORN determination to finish a game.

I started Katsu's Journey almost a year ago today (and posted a thread on gamedev.net about it, it's an amusing read.. How do you plan to make it as an Indie developer? (http://www.gamedev.net/community/forums/topic.asp?topic_id=82869) ) I've suffered setbacks and learn a lot of things the hard way, fortunately I’ve always come out ahead in the end. For instance I lost 3 months of coding on the editor when the harddrives in both my computers died. I will never work on another project without an automated backup system :)

Two bits of advice I could offer. Avoid burnout like the plague, pace yourself. When you start feeling tired during the day because of your coding habits, your pushing too hard. Take a day or two off and get some rest.

To maximize the time you do have coding, when you get done for the night, write down what your working on and what you would work on next if you weren’t going to bed. That way when you start the next day you would spend the first 1/2 hr. trying to remember what you were working on ;)

There's so much more I could add but then your eyes would start bleeding or something, so I'll leave it there.

I think finishing a game is one of the harder things to do, and often it determines the difference between a pro and someone who'll never make a living at it. Fact is, game development, like everything else has a work threshold. I find new game projects fun and interesting, but after being on the same game for 6 months and having to add some dialog to do with player tracking... well... It's just work. My main motivation, in the harder times when the game has become more work less fun, is simply that if I don't finish the game I can't sell it and ergo I can't eat or pay rent. I also try to look for that other exciting period when the new game is released and I can see the first sales coming in.

Ironically my main problem is the other way around. I'm best off when I can concentrate on a game and finish it, but I'm forced to do many other tasks. Being a fairly small indie company, I have to do various business tasks, like marketing, signing contracts, preparing new installs for affiliates, some artwork, web design, and so on... and what happens is that I get pulled out of "the zone" where I'm really into the project I'm working on. Once I'm out it's much harder to get back in. Somehow or other I've managed to find some balance though. Like anything you get accustomed. I'm now pretty good at jumping from thing to thing and still completing what needs to be done.

Anyway... I'll say this. Starting a new game idea is easy - finishing a polished product is a lot of work. Drop Target was up and playable within 2-3 days. That was 6 months ago and I'm not done yet. I haven't been working full time on it, but all the little details that turn a proof of concept into a marketable game take a lot of time and serious effort.

Well, I started programming when I was around 13 I guess, with QBASIC. Then I got into Visual Basic later, and when I was around 17 I finally got into C++ (I think if it wasn't for Windows Game Programming for Dummies I wouldn't be posting this now). Oh and in case you're cracking your head over how old I am right now, I'm 21. :) WGPFD pretty much "launched" my game development "career". :) Even though I don't even use DirectX right now (using SDL), WGPFD helped me finish my first game -- a Pong clone. That was in 1999 (I also started college at the time).

After that, I decided I was really cool and that I can make a much bigger game. The idea was for a topdown view tank shooter. I wrote the 50 or so page design doc (I read that you need to have one to be successful), and started working on the engine. At the time I was only starting to get into the good habits of architecture design for my code, which I can't live without anymore.

Anyway, an online friend of mine whom I know for around 6-7 years now but never met in person got interested in the game, and offered to help with the programming. We also got another programmer onboard for a brief period of time. I think I worked on the engine for about a year and a half (part time of course, because I was in school). I learned a HUGE amount from this, and with my friend we created a very powerful engine (including graphics, sound, input, tile engine, animation, particle engine, etc.) that I'm using for my current game. But, unfortunately the game proved to be too big for me at the time, and I was forced to drop it. I think if I started it right now I'd be able to finish it.

After scrapping the game, I continued to work on the engine for a while. That's when I made the particle engine. It got kind of boring just working on components though. So I decided to take a step back, and make a Breakout game, to prove to myself that I can finish a project. Of course since I'm pretty skilled now I decided to make it a breakout game similar to DX-Ball. :) That's where I am right now. I wrote a lot of the game already, but this is my last semester and it's pretty frantic so I put the game on hold. I plan to get back to it as soon as I have time again.

So as you can see, I've only attempted 3 games so far, 1 of which i finished, 1 of which I had to scrap, and 1 of which I'm working on right now. :) I think one of the most important things involved in finishing a game as Dan MacDonald mentioned is putting A LOT of thought into code structure BEFORE you start coding. Every one of my components had a 1 to 3 page architecture design document, which I followed about 70-80% of when writing the component (the other 20-30% were problems that came up which I didn't take into consideration in my design).

Writing architecture design lets you think about and solve in your head up to 80% of the problems (80% max is the rule I got from Game Architecture and Design) you will encounter when coding it BEFORE you even begin. This means you write better code, take less time to write it, and thus have a much greater probability of success. I've personally tested both ways of programming. Without a plan, you will end up rewriting code many more times than if you had thought about it in advance. Sometimes you'll end up having to rewrite so much that you won't even want to do it and quit instead.

Huh, now that we have answers to "How/Where do you get your ideas," it's a perfect time to get answers on "How do I get rid of them?" :)

Here's what works for me.

1. Have many unfinished ideas/projects

Writing games from age of 9 left me with dozens of incomplete projects. I think it's a kind of tribute to the trade. All those unfinished engines and playable demos are now great only to recall the old good days, or to show them to a new friend of mine. But, nowadays, it's hard to explain people that playing 4-channel .MOD to PC-speaker, or getting smooth hardware scrolling on EGA adapters were damn hard to implement. And I say nothing about cool software 3D engines for VGA Mode-X modes :)

All those things were great to increase my skills, but nothing of real value to give others. Now that I have them, it's much easier to hold on jumping to new ideas, really.

2. Have a clear goal

Steve has a great article about this. Set a clear goal to achieve and work on it. It will certainly help, unless your goal is to have a plenty of unfinished projects :)

3. Have at least one completed product

Since I have a real shareware product and am a rather skilled and experienced programmer (sure, who isn't :)) it's much easier to pass on new ideas. That is because there is a clear understanding of the fact, that even completing the project isn't the end by itself. You have to tweak and improve the product, if you want to get the result. Having experience with projects of different sizes - games or business applications - helps a lot. When I have a new idea I usually can roughly estimate the effort required to complete it. Then I can easily compare it to the amount of effort required to complete the current project. Unless the idea is very simple, it's rather easy to pass on it.

4. "Burn the ships"

This helps too. If you decided to left your day job, then playing with new ideas is very dangerous. Once you understand it, your attitude changes and you treat new ideas carefully.

5. Play with them and throw out quickly

The beauty of being independent is that you have full command of your time. Usually, I write down a detailed description of every new idea that comes to my mind, should I find it interesting enough. Later, if I become bored working on my current project and loose development speed, I can afford myself a one-two day's break. I then look through my list of ideas and pick the easiest one or, perhaps, the most fun. Playing with it for a day or two really restores my powers. Furthermore, the time spent isn't lost, because I often learn something new (e.g. good architectural/design solution). After that it's much easier to get back to your project. Think of it this way, you had a strong desire to left your current project unfinished, but you transferred it to another little temporary project. This way your desire was satisfied and you can keep working further :)

'Burning the ships' helped me a lot too.
Back when I only developed little games for fun, I never finished projects. But that was OK, it was fun afterall. I learned a lot back then anyway.

Since I started to rely on an income from game-development, my attitude totally changed.
Now I know it is 'work', even if most of it is really fun and a great positive challenge.
When I get to the 'less fun' parts, I just tell myself what a great job this is, and that it is much better than anything else, even if it has some hard moments.

I think Dan has a good point with 'Burnout' too.
If you work too hard, your 'normal' life will suffer and in the long run your motivation will suffer badly too, because you won't be really happy with the life you are living.

I don't know how credible my information is since my game still isn't completed but I did just overcome an incredibly strong urge to scrap and I'm pleased with myself for doing so. Here's some pointers that have helped me:

1) Rapidly prototype your ideas

There's nothing wrong with having ideas and scrapping them if it's done early. When you have an idea for a game create a prototype first to see if it will be any fun. Only give yourself 48 hours to produce this early version and use recycled chunks of code and artwork to do it. You're the only one who's going to see it, so it doesn't matter if the game looks like crap.

Now you have enough information to proceed or cancel this game. Is it fun? Is it the kind of fun you would pay money for? This is only for you to decide - don't let anyone else see your game yet! You don't need criticism and you can't afford to be discouraged this early. As long as you can honestly say that YOU would pay money for it then it's a safe bet that you will find an audience.

Once you are past this stage you can proceed in full confidence that you have a winning idea and that you DO NOT have permission to give up on it.

2) Start small!

Everyone hears this advice but almost no one in the wannabe dev community heeds it! Everywhere you look there's first person shooters and MMORPGs in development even though the "developer" has no experience. They will *never* get finished!

Your first game should be no more complicated than tic-tac-toe or a child's board game. I know it sounds like no fun at all but it's the only way to learn how to *finish* something. Until you develop the habit of finishing projects there will always be this self-destructive urge in you to quit and move on to something more "interesting" or easier. Perseverance like any other skill must be developed over time.

3) It's not one big program but dozens of little ones

When you look at your goal as a whole it can seem impossible to achieve but the more you break it down into smaller steps, the less intimidating it becomes. The same thing applies to coding your game.

I'm a sucky programmer but I do know that the more modular your code is the better. So realize that you're not writing "a game". You're writing a file loader, a display setup, a player input, an AI, etc. Break your code into the smallest conceivable chunks and you soon realize "I can do this!"

Plus if you get stuck on one part of the game you can take time off and work on another part. The ability to change focus to another part of the *same* game helps fight the urge to scrap the whole project and start something else.

4) Honestly, are you afraid of success?

This sounds really stupid but I think I may have a touch of this. I've noticed that I have some negative associations (oh god, I sound so Tony Robbins) to completing my game and having it published. While I'm endlessly positive about earning money, entertaining people and being my own boss I'm also nervous about what all of that could mean.

No matter how good a game is there will always be people who don't like it and put down the developer that made it. I don't know if I can handle personal attacks over something I've poured so much time and effort into. There will always be a computer that just won't run your software and no tech support you can give will help. That would make me feel like a failure, even if it was only one person who had a problem. If the game sells well there will be pressure to do an even more successful followup.

It almost seems easier to just keep making "half games" and not have to worry about any of it. It sounds stupid but those thoughts can really plague on you when you're having moments of doubt.


I hope this helps some.

Sorry for taking up so much space...

I thought I'd also share a couple of personal beliefs that have helped me along the way:

1) THERE'S NO SUCH THING AS DISCIPLINE

Discipline is one of those words that gets tossed around so much and more often than not it comes with a negative association. I learned this while trying to get in shape and the best people could say was "You gotta be disciplined!" What the heck is discipline anyways? Discipline in and of itself is absolutely nothing!

The art of discipline is simply performing an action consistently until the job is done. People who can focus on the task at hand - and *only* the task at hand - are magically given the label of "disciplined". Yet they really are no different than anyone else.

Discipline isn't a personality trait - it's an action. It's sticking to what you're doing UNTIL IT'S DONE!

2) YOU'VE ALREADY FINISHED YOUR GAME...AND IT'S A BEST SELLER!

This one's a little out there so bear with me :)

I was watching a program about the "big bang" and something mentioned struck me as really profound. They said that all matter in the universe was created in the big bang and that there is no new matter being added to it. So everything in existence is made from particles born in that one explosion of creation.

Therefore everything that ever was or ever will be already exists in a matter state.

If your game is to be completed then, as far as the universe is concerned, it's already done. The molecules that make up your CD master already exist. The bytes of data that make up your game are already allocated on your first customer's hard drive. Your artwork is already done and you've coded brilliantly. Your game is already a success and, somewhere in time, your distributor just printed off your first royalty cheque and all your bills are about to get paid!

If it's going to be - then it already is. Your job is to navigate from here to there. I guess that's the definition of faith.

I flit around doing all manner of things before I lock onto projects to complete.

On the whole I think of my self a a project starter and non finisher, but when I think about it I have finished 4 games (5 if you count Drippy which is completeish and awaiting Steve's review)

In between those projects I have done all manner of things. I have written a Text Editor in OpenGL, A turing machine emulator (with state diagram layout), Physics tests. MMX tricks, an explosion generator, plus several starts of games that didn't go anywhere. A lot of these programs had the basic functionality but not a complete finished product.

I'm a lot more focused than I was. The two things that got me really onto making games seriously were turning 30 and getting engaged. If I want to make a career out of making games I have to start making a reasonable income now because making a start is a lot harder when you have a family to support.

Since Fitznik I bounced around trying ideas here and there before picking what I was going to do next. I stuck with that until I realised that it might take too long to develop and making something smaller might be better. I essentially pushed that game onto the stack and started Drippy which took a lot less time (although several times longer then I intended (it's also much more polished than I originally planned)). Now that Drippy is Done, I'm doing a big project pop off the stack and switching back to my 2d platform game masterpiece.

In the middle of all of that I also pop into and out of Fitznik mode doing bits for Updates and Fitznik 2.

Originally posted by svero
Starting a new game idea is easy - finishing a polished product is a lot of work. Drop Target was up and playable within 2-3 days. That was 6 months ago and I'm not done yet. I haven't been working full time on it, but all the little details that turn a proof of concept into a marketable game take a lot of time and serious effort.

This is the nub of it right there: it's easy and fun to come up with a game idea, and much more difficult to finish it. I read a Winston Churchill quote recently about writing a book that applies equally well to making games. He said, "the book [that you want to write] is first a toy, then an amusement, then a mistress, then a master, then a tyrant, then a monster. And the only way to rid yourself of the monster is to turn it out onto the world."

With games (as with books) most people stop at around the 'toy' or 'mistress' stage. It's fun, it's gratifying, and you get to imagine how cool it would be to have it done without actually having to take those exhausting, terrifying steps to get it there.

As for being a project butterfly, yeah, I know what you're saying. A friend of mine has told me that I have the attention span of a cockroach... and another suggested I should have a Ritalin IV drip. ;) But you can finish a project. Really, you just have to want it badly enough to wade through the stuff you don't want to do to get to the end you do want.

Others have already offered some 'inspirational' ideas in this thread. One of my techniques I use when there's something I don't want to do is to ask myself, at the end of today (or this month or this year or my life) what do I want to have done. Not, "what do I want to do now?" That'll always get you answers like "goof off" or "go for a walk." But if I can focus on the fact that by the end of today I really do want to have x, y, and z done, then I'm much more likely to take a deep breath and do them. Do that hour by hour, day by day, and pretty soon you'll have an actual by-golly finished product on your hands.

(And on that note, if I can get what appear to be the last few issues with my web page and esellerate worked out, I may have my first selling product up today!)

Lastly, I'm pretty sure I've said this before in these forums, but it fits pretty well here. There's this train of thought that I tell people in order to help them understand the scope and skills inherent in any project:

An idea is not a design.
A design is not a demo.
A demo is not a program.
A program is not a product.
A product is not a business.
A business is not profits.
And profits are not happiness.

It's always tempting to jump -- project-butterfly in motion -- from the beginning to the end. And then when you find out that that leap didn't really make you happy, you go back to the top and start over with a new project. But the only way to get from the top to the bottom is by slogging through every difficult step in between.

This seems like a fairly obvious approach but it helps me and maybe others have not considered this. Before starting any project I make a checklist as part of the design doc. This checklist covers EVERYTHING the game needs to be complete (in many cases even listing every single enemy and every sound effect to be created.) Then when I work on my game I just keep doing what's on this list, checking stuff off as I go, until everything is checked off. This checklist has the simultaneous effect of breaking things down in to smaller tasks AND making sure I don't stop until the project is completely done (as opposed to just mostly done.)

For a start on such a checklist look here:
http://www.makegames.com/chapt5.html
With the possible exception of God Mode, every single game needs every single item on this list to be done. Then for your specific game elaborate each point to create your checklist and absolutely do not stop developing for any reason (eg. switching to another project) until every line on your list is checked off.

I've been a project butterfly my whole life.

I LOVE IT!!!

Don't get me wrong, it's a pain in the arse and it takes a massive amount of dedication. It's like round-robin DNS: sooner or later, you've got to come back round and point at the same server again. It's not even really about time management at this point. There's never going to be enough time for me to finish everything. As Mike points out, it's about happiness. You've got to work on what it is that interests you. Oh, and by the way, it'll get real darn interesting to you to complete your project when you need to start generating revenue. Otherwise it's just a hobby -- and that's okay.

To give you an example, I'll list all of my current projects off the top of my head, without consulting my precious to-do list or thinking too hard about it. The point is that you need to make sure that you keep all of your projects in your brain. If you sideline something and you completely forget about it, the chances of ever returning to it are super-slim...

Daniel's plate:

Finish building my drafting table
Start construction on daughter's loft bed
Repair the kid's play bench
Build a "Texas flag" patio table with 1" tiles
Pack for vacation (next week, woohooo!!!)
Refinish bedroom bookcases
Finish implementation of DockCam
Write PhotoClock design doc
Write Journal software for Mac design doc
Rank importance of the 21 other software projects in my idea bucket
Write a CGI mailing list for a client
Check on potential business names
Flesh out hedricksoftware.com site design
Take truck to Ford dealer and get all the broken crap fixed!


I've been like this my whole life. The more stuff I have on my plate, the better I am about accomplishing any given task. It goes back to grade school when I built models and was on the swim team and in a theater troupe and played in the orchestra and was in the science club and latin club and had a part time job. I kept missing apointments until finally one day, my mom bought me a pocket calendar and sat me down and explained the concept of planning. She's an accountant and about as anal-retentive as anyone I've ever known. I learned that if I wanted to do all those things, I would have to accept that I couldn't get them all done at once (wouldn't that be cool!?!).

Anyway, don't fret if you're a project butterfly. In my opinion, it's okay to hop from project to project. Just make a conscious decision when it's time to move to the next thing and always plan to return to what you've got going on. The best way to keep track of everything is to just keep track of everything. Write it all down, and as you write something down, break each task into smaller and smaller bits until it's where you feel most manageable.

There will certainly be times when you've got to finish something (like that blasted drafting table!!!). When this happens and you're finding it hard to return to something you know you've got to complete, make a bargain with yourself. Tell yourself that you can't go out to eat or you can't buy that cool new gadget or you can't go to bed until it's done -- and commit.

Good luck, and don't worry, you will finish it when you need to.

-daniel

One idea that may be helpful with finishing difficult and lengthy tasks is not to worry about finishing at all. Instead, shift your focus to repeatedly beginning the project. Eventually you'll be starting on the end of the project. If you're a good starter but a lousy finisher, then just keep starting.

Also, previously KNau mentioned the idea of reverse-chunking. If you see your project as one giant mountain of work, you'll encourage procrastination. Instead, just schedule a 15-minute period to work on one small piece of the project. When things get tough, give yourself an easy victory to rebuild your confidence and momentum. Maybe just create the artwork for one button. Focus on one present task -- don't worry about the future because you don't live there.

I've never heard a developer worry about finishing their game while they're actually working on it (in the present). It's only while we aren't working that we stop to think, and if our thoughts are negative, they can keep us from returning to productive work. No task is too hard when you're actually doing it. So work to replace the habit of "thinking about working" with "actually working."

The hardest area of game development for me is design. Programming is much easier by comparison, although about 10 years ago I thought it was the other way around. When you have a clearly defined problem that's achievable with technology, you're pretty much guaranteed a solution if you're an experienced programmer. The world of 1s and 0s is very comforting. But when your goal is to create something fun and unique, you aren't guaranteed a solution.

As a result, I take a very structured approach to programming (similar to what Dan MacDonald described), but I take an experimental approach to design. It takes me a long time to design a good game, with lots of throwaway prototyping, pen and paper experiments, and semi-playable physical versions (using pieces from various board games). I can't schedule the design work to be done in any particular time and guarantee a fun result. But once I have a solid design, I can crank out levels and code fairly predictably. Once I've nailed the design, I see the project as about 80% done. Dweep, for instance, took 4 months of solid design work and prototyping. But to do all the programming, artwork, music, sound, and level design took only 2 more months. This may be unique to logic puzzle games, however, where good design is what makes the game.

One last suggestion I have is to work on your game every single day, preferrably at the same time each day. When Richard Garriott was designing dungeons for some of the early Ultimas, he would do nothing else. He would let his beard keep growing until he was 100% done. Work on your game every single day in some way, even if only for 30 minutes. You can always work longer on some days, but if you establish this daily habit, you'll eventually finish your game. The trick is that once you've gotten past the first 15 minutes, you'll tend to keep working much longer because your focus has shifted from the difficulty of the task to actually doing the work.

No pain, no game!

Just my 2c

Keith

Originally posted by Dexterity
Work on your game every single day in some way, even if only for 30 minutes. You can always work longer on some days, but if you establish this daily habit, you'll eventually finish your game. The trick is that once you've gotten past the first 15 minutes, you'll tend to keep working much longer because your focus has shifted from the difficulty of the task to actually doing the work.

Yes. I agree with this. Basically that's what I meant by being in the zone. That is.. once you're on the project and into it it's easier to keep going. When you get pulled out or you stop working it's much harder to get back into it. (actually a lot of life is like that... say regular exercise) -- Anyway.. there's a point to this...

What I've found helps me get back into a game when I've stopped working on it (say I went on vacation) is to take the smallest and easiest tasks, the one's that don't seem daunting and attack those first. They act as work gateways drawing me into the rest of it. So for example, if I have to add a buy button to a screen, I may start with the easy task of drawing the button (that's easy and fun for me), and that helps me get into doing the code. Next thing I know 8 hrs has gone by and I'm right back into it.

It took me about 8 months to complete Goof Ball. The first three months or so were really fun - doing all the physics and 3D graphic programming. It didn't become difficult to stick with until the last three months, when all the programming was done; it was just churning out levels and tweaking game play. Parts were fun, but it was very tedious. That is also about the time when other game ideas started popping into my head and especially at that time, they seemed REALLY appealing.

I stuck to it by forcing myself to work on it one to two hours each night (I've got a full time job and do my shareware game development in my spare time). If I didn't force myself do that, there's no way I'd be done with it now. It certainly wasn't a lot of fun near the end. But, it's really worth doing and I'm sure I'll do it again.

Jeff
www.evertt.com

For me, envisioning the finished product is very motivating. I think about how cool it will be and how people will enjoy it. This keeps me motivated and locked on to the current tasks. Often before I start coding, I listen to my favorite music. It puts in a good mood and allows myself to slide into the "coding groove" more quickly.

Also, I never allow myself more than a passing thought about any other game besides the one I am working on. Why even tempt myself? This mindset has given me a perfect 7/7 for games started/finished! You just have to be a pitbull with a one track mind!

I have a dedicated office for Retro64 in my house. However, now that my wife is home with our new daughter, I have barely accomplished anything for Retro64. So I have begun to look for office space :( My current project is going slow, but not because other ideas are creeping in. (the temptation to go upstairs and see my wife and daughter is much greater than the temptation of a different project :D)

Jeff,

I just tried out GoofBall...
Great game..

heres what I noticed:

I enjoyed directly controlling the ball much more than controlling the playing field.

This is something Marble Blast (www.garagegames.com) did very well.

They sold several hundred copies in the opening few weeks.

If your sales are lacking, I think you should consider adding much more ball-specific interaction.
Seriously, this game has alot of great potential and I think for this much that you put into it, you should market it much more.

Sirrus
weaponstudios.com

I would have to agree as well. I've spent quite a long time writing the code for our online matchmaker server. At first, something of that scale is horrific to even think about and I'm sure I put it off more than once. But after spending about an hour per day on it, testing different methods and learning different things about the architectures I was debating, it's just about finished.

Tonight, we'll be testing it with around 5 people. Assuming things go well, we'll release it to the beta testers probably Monday or Tuesday after cleanup.

Steve's really got that problem pegged well though. A monumental project does lead to procrastination. Of course, my problem is that I have no less than 10 monumental projects going right now. :p Any solutions for that aside from that self cloning machine that I've always wanted?

Some excellent tips in this thread.

For me, it's generally a groove thing. It's hard to start, but it's fantastic when I get going. The problem with starting is usually because my task isn't clearly defined. When that happens, I'll fumble around with things that aren't important until I snap out of it and realize what I'm doing. I'm a major procrastinator, which doesn't help. I usually can stay focused on one project; prioritizing and rapid decision-making are my weak spots. When things go right, I can see where I'm going, know it's making a major dent in my to-do list, and chug along happily for hours. Cultivating that sensation and repeating it is a continual effort.

To avoid flopping between new projects, I always set me sights on much smaller projects.
I look for something that is feasible, will sell decently well, and that I know I will finish.

All of the titles I have worked on have all taken no more than 2 months from start to finish.

Most of the code/art is done in under a month.

Tokyo War - Made in under one month. Currently generated 44 sales ($220)

Teddy Trubble - Spread out over a year (was in hibernation) but would have only taken a solid month/2 to complete. Currently seeking retail publishing.

Goliath - Afew weeks and will be put on a game collection (100) by Activision Value

Dope Farmer - Finished in about a month. Afew weeks of adding little extras. Will be done in afew days.


So by staying focused on smaller projects, you have a tendancy not to want to switch so easily. Its hard for me to imagine spending 8+ months on one game, but Ill eventually get into that process.
For now, this is what works.
:)

Sirrus
weaponstudios.com

Wow, these are great tips and experiences so far. Thank you. It seems I've hit upon a fairly common "problem" with indie development.

One thing I've noticed people saying is that "butterflying" (or project hopping or whatever) is the same thing as procrastination -- even if the developer goes straight onto another project.

One might say "how can I be procrastinating if I'm constantly working?" Well, after applying Steve's analysis of procrastination, which is "procrastination is caused by associating some form of pain or unpleasantness to the task", it begins to make sense. Once the process gets difficult, or at least not as rewarding as it used to be in the beginning stages, it's human nature to try to go back to a more pleasurable state. In this case, that means starting another project. And you do this ad infinitum.

Well, I think you guys are right on to say that butterflying = procrastination. I did not realize this before. I thought it was just losing focus. And Steve's right on about overcoming procrastination. To do that, you have "to reduce the pain and increase the pleasure you associate with beginning a task, thus allowing you to overcome inertia." (See article "Overcoming Procrastination".)

It's all about focus, sticking to it, starting each day (even on little parts), and envisioning the completed product.

Thanks, all.

Visualizing the finished product is great, and having functional prototypes early is also excellent for motivation.

However, guard against thinking about all the features that must be implemented before you can bring the current state of the game to the finished state. (I think I’m re-iterating some thoughts that have been stated prior... but here goes)

If I start thinking about all the things I STILL need to do for Katsu’s Journey, I get overwhelmed and depressed very quickly. Thus I focus on the priorities at hand. This is where I like working with a team, one of our team member’s works as a producer/designer. So he works through the long-term goals for the game while I work on the critical features that need to be implemented. When I finish a feature we get together and think about what the next more important feature is to implement.

As long as you always biting off sizeable chunks the end always seems about one to two weeks away. Treat each feature as if it were a separate project, in that way you can harness your butterfly tendencies and use them to finish your game. ( I think this is what Steve was talking about with continually starting) I doubt I would have signed up for Katsu’s Journey if I had been thinking about all the time it would take to implement everything. But the simple approach of doing one thing at a time and taking pride in each smallish task has enabled me to work on it longer then any previous project. (and more consistently too I should add)

One of the reasons Katsu's Journey doesn't have animation yet is that it's really not that essential to the game. There are other game systems that are much more critical to the games success so I work on those first. Even though one of the most requested features from people who view our early prototypes is animation, I press on with other more critical features.

The tendency is to do all the fun/rewarding features up front, like animation, or particle system or stuff like that. I think it's better to string these fun little projects throughout the development cycle so you have little projects to reward yourself with when you get tired of implementing the big core/critical gameplay features.

There are so many little strategies for keeping yourself motivated and being efficient it’s hard to communicate them all. This thread hits on a lot of them. Like with most advice of this sort however, you really need to find the system that works for you. There is no ONE way to go about it, and there’s certainly not one way that’s guaranteed to work for everyone. This thread has some great starting off points, but your going to have find out what works best for you.

I think the very first step, before you try implementing any of the above techniques is cultivating a long term view about your project. Think about your goals and aspirations, cultivate a stubborn determination to reach them. When you set out with finishing being your top priority you wont be as tempted to take shortcuts. If you start out thinking, we’ll see how far I can take this project before I get stuck… your more likely to fall into poor design and coding habits. Quick hacks, no commenting, complex code will flow from your fingertips and before you know it you’ll have coded yourself into yet another corner and you’ll abandon the project. With a long term perspective you’ll be more willing to make the early sacrifices and do things right, knowing that they will enable you to finish down the road.

Mike Boeh, is there anyway you could supply sales figures for your games?
Im very interested as your site has all the key qualities. I am wondering if it would be possible to thrive with what you have.

Thanks alot.

Sirrus

Originally posted by KNau
[2) YOU'VE ALREADY FINISHED YOUR GAME...AND IT'S A BEST SELLER!
Therefore everything that ever was or ever will be already exists in a matter state.

If your game is to be completed then, as far as the universe is concerned, it's already done. The molecules that make up your CD master already exist. The bytes of data that make up your game are already allocated on your first customer's hard drive. Your artwork is already done and you've coded brilliantly. Your game is already a success and, somewhere in time, your distributor just printed off your first royalty cheque and all your bills are about to get paid!

If it's going to be - then it already is. Your job is to navigate from here to there. I guess that's the definition of faith. [/B]

Hehe, this reminds me of an old discussion I used to have with my brother, back in the days of 1K computers (yes, you've read that correctly) like the ZX81.... and yes, I'm that old. ;)

That idea was that if you simply started filling up that 1k with all possible combinations of numbers, eventually (and already, with 1k, it would take a loooooooong time) you'd have not only every game that everyone ever wrote, but also every possible game that everyone might ever write in the future, and all possible variations thereof. You could have exactly the same game, but in one variation a pixel would be different on one sprite, or the credits screen would read your name rather than someone else's name (or your name mispelled in every possible way) .

Not that even with 1K it would be practically possible (would take billions of years - and someone would have to test the 99.999999999% of programs that simply don't work) but the idea was fun to toy with.


Sorry... that probably added nothing of value to the discussion. :)

Mike Boeh, is there anyway you could supply sales figures for your games?
Im very interested as your site has all the key qualities. I am wondering if it would be possible to thrive with what you have.

Thanks alot.

Sirrus


While I can't give specifics, I can say that I make a nice living from Retro64.

But "making a nice living" is not my ultimate goal. I want to grow Retro64 much larger, while staying highly profitable.

Ive finished a few reasonably large commercial games. That was easy (relatively, you get paid, so you do the job, plus you know its going to get into people's hands).

Recently for my indie activities Ive been re-considering the plans I had.

I always targetted small-ish games, which are do-able by myself and a few helpers. Up until recently I hadnt thought of simply doing a game the essentially was small enough for me to do by myself.

My reasoning was that if I could complete a smaller game by myself, I'd have learnt a few things:

1) Some people might buy my games and in doing so, get to know me or my work. Essentially starting down the path to having a customer base.

2) I'll have some metric to judge the effort required to do indie games versus my day job.

3) It will actually mark the beginning of my transition from paid grunt to hoping-to-be-paid grunt.

And a few other things (can I design a simple small game that people would enjoy for 30 mins at a time etc).

So yes, Ive changed projects, I'm well aware that I flit around a bit, but each time I progress towards a goal, learning something along the way.

.Z.

I'm not that much of a butterfly. I take time off from game programming to think about what to do next, do freelance or my own art, or whatever it takes to refresh my mind and dive back into the game.

I have what I call a "pulse" that keeps me focused and concentrated on project. At the earliest moment when Space Station Manager was barely playable, but could be packed up as an installer, I started doing weekly releases. I counted that I have done about 30 releases since, only missing one or two weeks during the whole time. I find that this pulse, or heartbeat, gives me a few benefits:

1. Clousure. Each week the project is released, each week you get something completed and have to part with it. In the beginning it was a fearful idea to part with your creation, and all its shortcomings. But now I have started to love it. When having the endless list of things to do that most people face, this immediate clousure helps keeping focused on ruthlessly triaging.

2. Feedback. Nothing beats actual user feedback. I could never, ever, come up with a good design without having an open link to the people who are actually playing the game. Besides me being social in the first place, it makes one really humble to listen to how users treat your game. If clousure helps you concentrate, feedback gives you the actual priorities with your long list.

3. Completeness. During the week you go through all the phases related to game developement: Marketing, Sales, Support, Education, Research, Design, Art, Programming, Release. Each week contains everything that larger projects do. Your learning can also be much faster with this approach. You get one project more experiences each week.

4. Structure. Having structure to ones developement is something I value most of all. Having a definite heartbeat keeps me much less stressed, I work very productive <40h weeks. And in the rare cases you miss one heartbeat it is much easier to get the next one with a long history of them. And having structure gives you time to more important things (Congratulations again Mike!).

This is what works for me.

I used to be a pretty butterfly :)

I would say that most games I started, i took to about 90% (code wise) and then dropped. Why ? Because the last 10% are the most boring and tiring of them all.

I found a good formula tho.

a) (most important) use tools already available to you. DX wrappers, level editors, code snippets, etc. Most ppl think this is cheating, but this is one of the most important things to avoid dropping a project. Why? One of the most fun part of coding is putting the sprites moving on the screen, or the particles with a certain behaviour. Now, since you need a engine before doing the game, you will be doing all this fun before the game. Then you reach to the game and you have to implement menu systems, save game, and a million other boring things. This will make you lose interest.
It also saves time overall of course.

b) Start small. When you started programming, you probably went through a step of project (Pong, Break out, tetris, etc etc) to gain knowledge. This should be applied to now also. While I'm not saying you don't have the knowledge to do a big game, most of the times the interest is lost in big games. If you start with a small game and finish it, and then a slightly bigger game and finish it, you will be more motivated while working on a big big game. This because you have proof that you can do your games and you know the game isn't a lost cause but also because you learn how to be patient in the boring parts of the game.


Do note, that exceptions occur and for example, I made my own engine, but that was because I developed the engine for the sake of having a engine, not for the sake of having a engine for a game.


Currently doing a small simple game (part time since job is taking all of my time) which is in development for about 2 weeks and is almost finished. Its somehow original (not totally tho :)) and fun to play. It uses green squares for everything but is still fun :) I'm currently talking with an artist to see if I can get some gfx for it :)

About design versus code, I tend to be the other way around most ppl are. I code while desiging. I tend to have a working prototype of the game idea in 3-4 days to see if it works. If it does, then i rewrite it completly with design in mind. I have some success on this since it allows me to see my idea and evaluate if it is worth pursuing. If i have a small working demo with colored squares moving around shooting lines and isn't funt he least, then chances are, no matter how much art and things I put in it, the game won't be much fun at the end. I also tend to experiment with gameplay alot. I like to test new ideas or twists of old ideas to see if they work. This allows me to do this quickly.

Originally posted by Akura
I used to be a pretty butterfly :)

I would say that most games I started, i took to about 90% (code wise) and then dropped. Why ? Because the last 10% are the most boring and tiring of them all.

I think you would have found that, had you finished one of these games, that the remaining 10% was in fact greater than 50%. Each thing you have to do to make a final product isn't very hard but there are just so many of those little things that you have to do.

Some additional ramblings...

The reason most applications never complete is because they have no manager. Without a manager to tell you to finish the job, you don't really have the motivation to do all the tedious work.

Of course, the "manager" can be a paid manager, a friend or even yourself (if you have the ... discipline.)

I continue to butterfly because every time I do I learn something new and when I get back to a piece of code, I can write it better than I did the first time.

Also, the technology in this industry changes so fast that the only way you can learn is to "butterfly" around all the coll new pieces.

By combining the management and the butterflying, you can build a great program. Without either, you'll either never finish or simply create something very simple and boring.

And when you're dealing with a larger project, you really have to look from two directions: what is my goal, and where am I now. i.e. the overview and the details.

The overview keeps you focused on the prize (satisfaction of completion, monetary rewards, praise from others, etc.) The details let you get the work done. Of course, the better your overview document, the better, but you don't necessarily need a formal one at first.

And, as a boss once told me: don't be afraid to create a prototype and throw it away...it will help you to create a better product the second time around.

All that said, break down the overview idea into manageable pieces and remember that assembling those pieces is one of the hardest tasks in programming. The .com failures found that out because they simply assumed that every cool component could be thrown onto a web page and out will come a winning website.

Programming is easy. Understanding project management is a lot tougher.

(Gee, I was hoping not to get as wordy as the other postings, but I guess there are simply too many things to consider.)

--
Rob

If i'm having too much fun with my projects, I know i'm on the wrong track. If i'm having a hard time finishing a project, then I know it's almost done and that's the time I need to work harder on it.

Screw the advice that says you have to start small. Start big, start WAY big, and even if you don't finish it, you will have done more than if you started small. But then when you come to the place you're just tired of your big project and you've bitten off more than you can chew... bite off a bigger piece, and continue. The only reasons I've completed a few small games (very small and very few) is because when i got to that point (which I invevitably come to in EVERY project I do), I kept going, especially when I didn't like it anymore.

Work like a demon, make off like an angel

Originally posted by Uhfgood
Screw the advice that says you have to start small. Start big, start WAY big, and even if you don't finish it, you will have done more than if you started small.

Obviously no piece of advice applies to every person so maybe this is true for you. And words like "small" and "big" are relative so what you call "big" perhaps someone else thinks of as "small." Still, every person I've worked with and/or met, myself included, who started a big project (around the scale of commercial games like "Quake" and "Warcraft") for their first game never even came close to finishing it. Even with a smaller project (here I'm talking about a good "Breakout" clone for example) you need to break the project down into smaller tasks so that you won't be overwhelmed; with a larger project it is SO big that chances are you won't even begin.

Think of it as inertia. A large project has more inertia so it takes more energy to get it moving. If you already have several smaller titles under your belt it is much easier to muster up that energy.

I'm still working on my first REAL project, so I can't answer.

But I would wish that I had started on a smaller game. But not finishing will make me a pathetic loser :)

I must finish !


- Currently doing a 2D internet multiplayer action game.

It's all about challenging yourself... you try something big, you push yourself... I think that's better.

The only reason I would think it's alright to work small is when you want to get a lot of small games done, for making money. I'm still kind of doing that...

Although I am working on a 9-part adventure game series

Keith

It's all about challenging yourself... you try something big, you push yourself... I think that's better.

The only reason I would think it's alright to work small is when you want to get a lot of small games done, for making money. I'm still kind of doing that...

Although I am working on a 9-part adventure game series

Keith

Screw the advice that says you have to start small. Start big, start WAY big, and even if you don't finish it, you will have done more than if you started small.

Challenge is good, but sadly this doesn't work for all people.
Many people who start something big totally give up at a certain point when they realize it is not possible to finish what they started.

Instead of taking what they have learned and building upon it, they become frustrated and eventually totally give up on game development.

So imo, it is certainly good to start smaller when you are new to game development, just to get some positive experiences and build up some motivation first. After you have seen that you can complete a project (even if it was small) it is much easier to accept a project failure without too much frustration.

Ofcourse many of the people who give up probably started with wrong assumptions anyway and thought they can make the next Quake or Unreal in a few weeks at home... So it is probably own fault/uninformedness in many cases.

But there is also the little fact that some people need to make money with their games. In that case starting too big projects would be fatal.
Imo producing small games to earn money and saving up a part of it to eventually finance a bigger project in the future is better than doing the big fun projects right away but at the same time wasting 8-9 hours of your life every day for a job you don't really like.

I was reading a book the other day called The Inner Game of Work, and it points out the following:

Too much challenge = Stress
Too little challenge = Boredom

Productivity is best when challenge is at a reasonable level (and only you can decide what that is).

I've been working on one project for... hmmn, coming up on six years. I'm from the "don't start big, start freaking huge" school of game design. Because the project is so big, there is always something different that needs doing - art, music, code, design, sound effects, website, backstory, maintaining the forum, keeping the fans happy, adding features for the mod community, testing, writing the manual. That way, I'm never bored.

I'm creating the game that I want to play. I think about the game every waking moment. And I don't sleep. Just a little further and it will be done.

But what works for me probably wouldn't work for anybody else.