My biggest hurdle before starting a big project.

Started by
13 comments, last by tanzanite7 10 years, 1 month ago

Hi everyone. I have been reading tons of posts on this site for a while and I've been learning a lot from the site and people’s experiences. There are a lot of good do's and don'ts and I want to say thank you. So I figured I would like some feedback or tips on a problem I know I have.

The problem I have is…Always having the hardest time on where to start a big project; mainly when I try to tackle one of my video game projects. There are so many approaches and I over analyze each approach and it prevents me from starting or I just start all over. Once I get going though, there is no stopping me.

I do/did make flowcharts, lots of documentation, and a lot of other parts that are on paper. Now I just need to make it real. I feel though if I don’t start in the right spot the rest of project is junk.

What the best way to overcome this bad habit?

If needed I can explain what my game is but I’d figure that every project will have its own specific starting point somewhere.

Advertisement

I don't think it's a bad habit. Planning is good, and if you have the plans ready then you can get started with implementation now. Give your time a reasonable time limit, pretend this is a school assignment, and you can get it done. Don't worry if your plans are not perfect, you'll be revising your plan little by little as you implement it.

Of the game elements that you have planned, what work do you need to do first before anything else will function the way you want it to? If you worked on that element but decided to cancel the project, will you be able to make use of the work you've done in future projects? Is there something that you can work on that can gives you relatively quickly a bit of a proof of concept?

I find planning before I code works well for me. I draw flow charts and graphs to help work out program flow and logic.

I also write most of my code in my head and then type it up once I have it all worked out, I find this works best for me.

My approach probably sucks, but I just pick a feature I'm interested in making happen and then just hack away at it and anything required to make it happen. Eventually, I get in the mood to clean up the mess left behind by this process and spend time doing that. There is a lot of wasted time, but it seems like I get more done even with the wasted time. Maybe I'm just working longer hours because I'm working on stuff I want to implement, or maybe I'm just more productive with the hours I work. I'm not sure which it is, but it seems to work.

Note I do have to mix in the sucky stuff I never feel like doing. Usually it's not too complicated, so I can knock out a ton of the boring stuff in a single week. Often that will burn me out and I'll take a mini-vacation, but it still seems faster to work for a week and take half a week off than it does to constantly convince myself how the boring code must wait so I can play minesweeper or clean an already clean part of the house or whatever else I come up with to procrastinate.

Edit: by hacking away at something, I mean just making something work. Sort of like a proof of concept in a lot of ways. I'm not worried about bugs or code re-usability or scalability or performance or anything, just seeing a result. Fleshing out the details is included in what I called cleaning up the mess.

I think this is really a two part question:

1. I am ready to start the project. Where should I begin?

2. I don't know where to start.

Answer to question 1: You have done your homework, made prototypes, thought about gameplay, made some sketches, picked some sample music, wrote some back-story, whatever it is you do to prepare to make something new and awesome. No one can tell you which thing to pick first, because we are all wired different. I like to have problems to solve, so I would pick the thing that seems the hardest to figure out so I can chew on it in the back of my mind. Maybe you need to do something simple so you feel like your making progress. Get in there, pick something, and see how it feels. Depending on how long a project takes, this could even be different every time. Don't be afraid to pick the wrong thing, either. Relax. Games should be fun, right?

Answer to question 2: If you just sit there staring at the computer, wondering were you should start, you're not ready to start. When you are ready, you'll know. You will stop preparing, and begin working (it may even happen when you're not looking). Do your homework, make a prototype to throw away, crappy sketches, anything to get the juices flowing. Again, this is very personal, but because you haven't actually "started" anything yet, you'll find it easy to make mistakes, try new things, and create.

Just my thoughts. Having just finished writing a 650+ page programming book, I can tell you that (at least for me) every time I tried to sit down and write, if I wasn't ready, it didn't work.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

If that doesn't sound like me, what does! haha.

I have actually done some research on this issue, which considers all the phases to developing a game (or anything for that matter). I found it on youtube after a discussion I had somewhere on this site (I have had plenty of detailed discussions).

The article was on wikipedia, but I forget the keyword I typed in to get it (I will find it later and post it here when I get my iPad back).

But you have to consider all phases of the production. Planning is only part of it. You have legal stuff to think about and such (so that no one steals your idea perhaps and runs with it).

I wish I had my iPad so I can post the list here.

My question to you is, "Is it actually plausible?" Do you have all the skills it takes to handle all facets of the process? Art stuff and programming stuff? Going to be on a team? Solo?

I can say so much on this topic, but I have said enough (read my journals and topics) haha.

They call me the Tutorial Doctor.

Happens to me every time. When writing papers in college, I always spent about as much time staring at an empty document trying to write the first line as I spent writing the rest of the paper. Same with programming projects. The trick I eventually found for papers was that the first line doesn't have to be good. It can be a complete joke--it's entire purpose is to sit there and make the page look less empty and intimidating. Then you get started and hopefully remember to replace it before you turn the paper in. I've found it kind of works for code, too, though you'll want to replace the joke line/crappy tutorial copypasta/whatever ASAP.

Another problem is losing your momentum. I often make the mistake of searching online for an answer to a specific question and then becoming trapped for the rest of the weekend--or the next several weeks--reading every topic on the internet that even remotely relates to what I'm doing. I'm doing it right now, actually. It's really hard to stop...


The trick I eventually found for papers was that the first line doesn't have to be good. It can be a complete joke--it's entire purpose is to sit there and make the page look less empty and intimidating.

EUREKA!


Another problem is losing your momentum.

Double Eureka!

Great advice!

Thus my post "Good help is VERY hard to find."

They call me the Tutorial Doctor.

Thanks all. It's neat to see I"m not the only one with this problem and I like everyone's approaches to it. Thing I was a bit afraid though was to waste time on something specific to the project then let it go to waste, but it seems like a common thing in order to make progress. smile.png

This topic is closed to new replies.

Advertisement