0
\$\begingroup\$

While starting out, I made clones of some arcade games (Tic tac toe, Pong, Snake, Tankwars, Breakout, Tetris, etc). Most of these games had just had the gameplay, I didn't code any of the starting screens, there were no features like high scores, etc. My question is, should I focus on polishing these games up or just start with more comlicated games?

\$\endgroup\$
2
  • \$\begingroup\$ Possible duplicate: gamedev.stackexchange.com/questions/17142/… \$\endgroup\$
    – House
    Mar 19, 2013 at 13:08
  • \$\begingroup\$ i hate seeing people reaping rep from questions that are off topic. they only get votes because the concepts are soo simple \$\endgroup\$
    – GameDev-er
    Mar 19, 2013 at 23:26

3 Answers 3

12
\$\begingroup\$

It depends what exactly you want to learn and what your goals are. I would tend to say it'll be more valuable for you to finish the games completely, rather than leave a trail of half finished demos, but there is something to be said for moving on to more complex topics (eg. 3D graphics) and leaving the simple stuff behind.

On the one hand, finishing your games fully will build up a crucial skill/attribute I refer to as "finishing ability." In other words, the grit and doggedness to actually see the project through to the end. It is one thing to just hack together the interesting part of a project, but it is pretty rare to find someone who can stick through to the end and not peter out when the project gets less interesting. For example, I knew a guy who was a graphics programmer on a AAA game engine (ie. this guy was a top notch programmer) who couldn't build an entire game when I first met him and found the process of building up his finishing ability a revelation.

That said, my little anecdote does point out that you don't necessarily need finishing ability in order to be, say, a graphics programmer on a AAA engine. Managing other people and/or a large project does require the doggedness to keep going through to the bitter end, but you don't necessarily need finishing ability when you're first starting out and being managed by a superior. A bigger company might care more about specific advanced technical skills the team needs, whereas a smaller team needs people who self-manage development.

(aside: I've never really pinpointed this before, but now that I'm thinking about it, I think finishing ability is the main thing I see separating experienced developers from novices)

\$\endgroup\$
3
  • \$\begingroup\$ Surely you must have realized this was a duplicate? gamedev.stackexchange.com/a/17145/7191 \$\endgroup\$
    – House
    Mar 19, 2013 at 17:37
  • \$\begingroup\$ Notice how I voted to close this question? Also my name isn't Shirley. \$\endgroup\$
    – jhocking
    Mar 19, 2013 at 18:33
  • \$\begingroup\$ Actually I'm thinking I might edit in some of the new stuff I wrote here, about learning to manage a project and self-management. \$\endgroup\$
    – jhocking
    Mar 19, 2013 at 18:48
2
\$\begingroup\$

Biased answer, based on my personal preference and experience since the question is of the same nature.

Finishing is beneficial in terms of learning to architect a clean code structure and program flow, initial prototyping i tend to leave in quite a few hacks, they are "correct" in terms of language use but when writing them i have a better method in mind that would require more time, and its more satisfactory to just get things to "work" as soon as possible, example would be brute force collision checks versus spatial partitioning, it works on the demo level but will be insufficient in later levels.

When actually finishing a game, i tend to run into these boundaries and have to solve them, which can be interesting and a nice learning experience.

And when it comes to "classic" games, you can always reiterate on the game play, how to make it more interesting rather than just cloning the game mechanics.

So to summarize, my advice would be yes completion is better.

\$\endgroup\$
0
\$\begingroup\$

I used to play around the whole time. Implement just some features, optimise etc. While this is all fun and inspiring you can't really put that in your portfolio which I quite regret. That's just one thing, next one is you won't experience certain problems when doing the small stuff.

If I may suggest - try to accomplish 1 big project a year, but don't forget to experiment. I'd do that if I was smarter in the past :)

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .