Sticking with a Project

[baconhawka7x]

I have made quite a few games, but most of the time I can't stick to one project. I was wondering if anyone had any good tips for starting/sticking with/planning out a project. Lately I started writing out my game, and development plans on a whiteboard, and get them each a date that I needed to finish it. But even then sometimes I would get distracted or sidetracked.

Most of the time the problem is that I will get distracted(by something other than programming) and then, when I come back from that distraction and try to add something, or continue with the project. I will get overwelmed or confused by the code.


If you have any tips I'd really appreciate them(:

[kikito]

Don't try to do big stuff until you are able to finish smaller stuff.

If you got distracted or sidetracked with one project, try a smaller one next time. Rinse and repeat until you find the right size for you. Then increase their size only slightly over time.

Being engaged with someone else instead of working by yourself also helps a lot. Try to do things that you like, but others will also like (not only things for yourself).

I've also found that keeping code as clean as possible makes me want to return to it. Ugly and messy code tends to scare me off. So I try to make code as clean as possible. But this is just me.

[molul]

Well it's very easy: just focus on ONE project and finish it, then go to the next one, and so on. And before starting anything else, remember that you still have pending stuff!!!

In my experience, I'm pretty sure that if you're fond enough of your project, you won't think of starting anything else. My band and Spiral are my only two projects right now. They get all the free time I currently have, and I will only start another project when I leave or finish one of the current two.

I mean, it's actually very easy: if you didn't finish a project, perhaps you didn't like it enough. When that happens to me, I just delete the project and move on.

[trubblegum]

I have found that structuring your code is far more important than structuring your time.
Don't get caught up with "getting it working". It is better to have something you cannot see happening working properly, than to see something moving around on-screen, but know deep down that it's a hack.
And if you end up rushed, you will end up taking short-cuts which may cost you dearly in the future.

In coding, the structure is everything - structure for efficiency, structure for usability, and above all, structure for structure.
If you get through only one object in a week, but it is properly planned, you can come back to it later, and immediately know exactly what it does by its name and scope. It should be studied, refined, and ingrained before you go anywhere near a keyboard.
Once you have achieved this "harmony" with your program's structure, you can return to it any time, and become re-acquainted in a matter of moments.

You can always leave yourself comments where you know code needs to go, so that you know what has been done, and what needs work when you come back.
-- apply force dampening here
-- refine method to include dynamic file loading
-- needs a more elegant solution!!!
etc

Then document some more.

And don't leave ambiguities.
w.o[t].v.x might seem tidy, but is likely to give you a headache at some point, while you will leave yourself with no doubt using world.objects[target].velocity.x (you shouldn't have to do that, but if you do, you know you can)

Following love convention is a good idea.
As an example, all of my game objects have object.load(this) object.update(this, dt) and object.draw(this)
When the game loads up, it calls state:load() which iterates over this.states, and calls state:load()
Now all my states are loaded and ready for action.
state[state.current]:update(dt) calls the current state's update function, which in turn calls this.gui:update(dt), and in the case of the world state, also calls world:update(dt), which iterates over this:objects and calls object:update(dt).
One call to rule them all, and best of all, I don't need to have any of this in my head, so if I suddenly get called away to the moon for a month, no problems - all my objects are little mini-MCVs inside a structure which I know works.

You will thank yourself for taking these kinds of pains in the future, and it should give you great satisfaction to know that your code is well-formed, and very likely, re-usable for your next project. You will also have more invested in the project, so it will keep your attention better.

Many and wordy are the volumes which have been written about coding practice - in fact, you can glean a lot of good advice right here on the forums, but always take the time to fully assimilate, and consider usage cases.

I'll stop now, before I end up needing a publisher of my own, but in essence : think it through. Writing a small game is, generally speaking, a leisure activity, and you can afford to take your time and produce something which will give you lasting satisfaction. And if it's a business, you can even less afford to make costly mistakes.

Well, I know that's not exhaustive, but I hope I managed to impart something useful.
Many happy structure to you, and I hope this helps you get more satisfaction from your projects

[felix24]

In my experience, I'm pretty sure that if you're fond enough of your project, you won't think of starting anything else.

I second that. I've been working on my game Plazma Being since last September and I've barely thought about making any other games, cause I've constantly been excited about finishing this one.

If you want to trick yourself into finishing stuff, you could always brag to your friends about the awesome game you are making (and going to finish making), and thus finishing the game will become a matter of honor , giving you extra motivation to finish it.

[Jasoco]

Do you know how many different projects I've started, shown off, gotten bored of/ran into a wall and stopped, started on a new one of a different genre, came back to a previous one but started a new engine with different techniques because I'm so anal about having it perfect an I learn new techniques and am too lazy to just convert the old project to the new techniques so I start from scratch....?

A lot.

To date these are the kinds of projects I've never finished...

Zelda-style Adventure engine
Vector-based SHMUP
Numerous platformers (Without Box2d)
3D model viewer
3D Star Fox-style prototype
A certain go-kart-style racing game
Numerous 2D top-down engines with "free move"
Numerous 2D top-down engines with "tile-based movement"
Wolfenstyle 3D Raycasting engine
Arcade style racer
"Infinite" arcade top-down Spyhunter-style engine
Point-and-click Lucasarts-style adventure games

If you want to trick yourself into finishing stuff, you could always brag to your friends about the awesome game you are making (and going to finish making), and thus finishing the game will become a matter of honor , giving you extra motivation to finish it.

Doesn't work for me. Showing off something early actually makes me feel more self-conscious about it being perfect and I end up getting tired of it faster.

[The Burrito]

Regarding showing off / talking to friends about your project, on average this is actually a bad thing. Basically presenting your work / idea tricks you into feeling like you've actually done work on it. (There was a study looking specifically at this, sadly I can't find a link)

I feel more motivated when I refuse to talk about something until it's done. (like how I haven't announced any of the bosses for In The Dark because none of them are finished)

I started on ITD not that long after I joined the forum (I think Löve was on 0.5 back then ). I still have trouble sticking with it sometimes, but it's a big project, 10k+ lines, 100+ frames of animation right now. Sometimes I take a week or 2 off and work on something completely different.

Also clean code, comments, and a decent text editor make it much easier to come back to after a vacation.

[TechnoCat]

Basically presenting your work / idea tricks you into feeling like you've actually done work on it. (There was a study looking specifically at this, sadly I can't find a link)

It happens with New Year Eve Resolutions too. People that resolve to lose weight are more likely to not lose the weight than those whom don't make the resolution and try to lose weight.



Also: Symbolic self completion theory

[veethree]

From my experience i've found it's way easier to stick to smaller and simpler projects. That way instead of spending most of the time you spend on it on solving problems and shit you can spend more time just adding features and polishing things up. Then once you get better bigger projects will seem smaller and easier.