15
\$\begingroup\$

I started programming many years ago. Now I'm trying to make games. I have read many recommendations to start cloning some well known games like galaga, tetris, arkanoid, etc. I have also read that I should go for the whole game (including menus, sound, score, etc.).

Yesterday I finished the first complete version of my arkanoid clone. But it is far from over. I can still work on it for months (I program as a hobby in my free time) implementing a screen resolution switcher, remap of the control keys, power-ups falling from broken bricks, and a huge etc.

But I do not want to be forever learning how to clone ONE game. I have the urge to get to the next clone in order to apply some design ideas I have come upon while developing this arkanoid clone (at the same time I am reading the GoF book and much source code from Ludum Dare 21 game contest).

So the question is: Should I keep improving the arkanoid clone until it has all the features the original game had? or should I move to the next clone (there are almost infinite games to clone) and start mending the things I did wrong with the previous clone?

This can be a very subjective question, so please restrain the answers to the most effective way to learn how to make my own games (not cloning someone ideas). Thank you!


CLARIFICATION

In order to clarify what I have implemented I make this list:

Features implemented:

  • Bouncing capabilities (the ball bounces on walls, on bricks, and on the bar).
  • Sounds when bouncing on bricks and the bar, and when the player wins or loses.
  • Basic title menu (new game and exit only). Also in-game menu and win/lose menus.
  • Only three levels, but the map system is so easy I do not think it will teach me much (am I wrong?).

Features not-implemented:

  • Power-ups when breaking the bricks.
  • Complex bricks (with more than one "hit point" and invincible).
  • Better graphics (I am not really good at it).
  • Programming polishing (use more intensively the design patterns).

Here's a link to its (minimal) webpage: http://blog.acamara.es/piperine/ I kind of feel ashamed to show it, so please do not hit me too hard :-)

My question was related to the not-implemented features. I wondered what was the fastest (optimal) path to learn. 1) implement the not-implemented features in this project which is getting big, or 2) make a new game which probably will teach me those lessons and new ones.


ANSWER

I choose @ashes999 answer because, in my case, I think I should polish more and try to "ship" the game. I think all the other answers are also important to bear in mind, so if you came here having the same question, before taking a rush decision read all the discussion.

Thank you all!

\$\endgroup\$
12
  • \$\begingroup\$ Sorry, but saying it's an objective question, doesn't make it objective. It would depend on the person, their abilities, goals, and motivation, whether they should change projects - all of which, makes it a subjective question. There simply is no single "right" answer to this question. \$\endgroup\$
    – Cyclops
    Sep 11, 2011 at 17:52
  • \$\begingroup\$ You're right, I thought of "subjective" but wrote "objective" (it also happens to me with left and right...). I changed it. \$\endgroup\$ Sep 11, 2011 at 18:21
  • \$\begingroup\$ Wups, sorry to hear that. However, I hate to say this, but it's still not really a good question for this site. The purpose of the StackExchange sites, is to build up questions/answers that are useful to many people, not questions that only apply to one (or a few) people. Also, there should (ideally) be a single correct answer - but for people in the future who find this post, some might find one answer best, and some the other, conflicting answer better. \$\endgroup\$
    – Cyclops
    Sep 11, 2011 at 18:39
  • 1
    \$\begingroup\$ I felt it was not a good question too. But the reason I wrote it anyway is because maybe someone is stuck with the same dilema. Even if there is no "good" answer, the discussion could enlight other people take their "right" answer. \$\endgroup\$ Sep 11, 2011 at 19:16
  • 1
    \$\begingroup\$ Personally I think the scope of a learning project should include all game features (so do implement the power-ups) but after that call the project done and move on; don't bother polishing graphics. \$\endgroup\$
    – jhocking
    Sep 12, 2011 at 14:48

6 Answers 6

32
\$\begingroup\$

I disagree with Patrick's answer completely. If you want to succeed as a game developer, the number one skill you need to learn is how to take an idea and ship a complete, polished game.

What you will realize over time (which is what I realized after several years) is that programming is only a small part of your game. It's easy, because it's fun. But to stick to only programming will leave you with a trail of incomplete proof-of-concepts and demos.

Instead, I would suggest very strongly you put up a website and blog (Wordpress is great for this kind of stuff), finish your games (starting with Arkanoid), and release them into the wild.

Also, it's key to realize that if you do this, you control when the game is done. If you want 1000 levels with 10 major features, fine. If you want 10 levels with 3 major features, fine. (In fact, I recommend smaller projects more frequently, because you learn more and focus a lot on polishing that way).

Edit: In response to the people who disagree, I feel I need to clarify. If you created a game just for one purpose/experiment (which I do all the time), by all means, cut scope and ship it. Nobody said Arkanoid needs 1000 levels to be a polished game; just make enough levels for it to be, in your opinion, fun, and move on.

It IS possible to spend years on a game and never ship. But I feel it's far easier to fall into the other hole of only making technical demos and prototypes forever. It took me 10+ years to stop doing this myself.

\$\endgroup\$
16
  • 3
    \$\begingroup\$ +1 "shipping is a (required?) feature" though in this case you could also see the arkanoid clone as a prototype, and prototypes are meant to be thrown away when a concept is proven or disproved. \$\endgroup\$ Sep 11, 2011 at 17:35
  • 2
    \$\begingroup\$ @Oskar it's easier to make 1000 prototypes than to ship one game. Ultimately, shipping will make you successful, while prototypes just increase some coding skills. \$\endgroup\$
    – ashes999
    Sep 11, 2011 at 19:35
  • 2
    \$\begingroup\$ Why dismiss "just increase some coding skills"? He's specifically asking about the learning experience. \$\endgroup\$
    – jhocking
    Sep 11, 2011 at 19:45
  • \$\begingroup\$ @jhocking because of Patrick's answer. My answer is specifically to focus beyond just coding skills. \$\endgroup\$
    – ashes999
    Sep 11, 2011 at 21:51
  • 1
    \$\begingroup\$ @Yannbane If people play it and think "yes it's a complete game," even if it's a short game, that's complete. Incomplete is usually broken games or games with, like, one level. Once you ship it out the door, you're done. \$\endgroup\$
    – ashes999
    Mar 20, 2013 at 13:28
8
\$\begingroup\$

I would suggest a synthesis of the previous two answers. Basically, I agree that it is enormously important to learn how to take an idea and ship a complete, polished game. The internet is littered with half-completed projects that someone started and then got bored of. The ability to stick with a project from beginning to end, what I call "finishing ability", is rare and precious, and gained by forcing yourself to practice it.

However you are not at that stage in your learning yet; I would not recommend doing this with your very first game, but rather make a few smaller games to learn with before working up to your first complete project.

(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)


ADDITION: I think a lot of the disagreements between answers just comes down to different assumptions about where he is in his process. For example, when he said "I finished the first complete version of my arkanoid clone" that could mean many different things. In my case, since he earlier said "I have also read that I should go for the whole game (including menus, sound, score" then I assume he actually implemented that stuff and is asking if he should keep going even further. In that case I would say no; call this project done and move on to the next project.

However that's just an assumption on my part; he didn't actually say he had done that stuff, just that he'd read it. If he hasn't done that stuff, then I would say don't move on until you've done that stuff.

\$\endgroup\$
8
  • 1
    \$\begingroup\$ +1 Beat me to it! Sounds like you are just getting started so it's more important to make as much stuff as possible and learn, learn learn. As you get better you can focus on polish. Otherwise you'll end up spending 2 years on your first game. \$\endgroup\$ Sep 11, 2011 at 17:26
  • 1
    \$\begingroup\$ Disagree. You can spend ten years coding and never ship a single game. Or you can ship a simple arkanoid clone in your first six months. I feel the latter makes you a stronger developer overall, while the former just helps your software dev skills (and not that much -- you never think about tools, life-cycle, etc. just coding). \$\endgroup\$
    – ashes999
    Sep 11, 2011 at 19:34
  • \$\begingroup\$ Well I didn't say 10 years now did I? Still, it's a question whether spending one year coding a bunch of practice exercises before the 6-month complete project is better than directly doing the 6-month complete project as your first project. This is a major question in the teaching I do; is it better for students to spend a semester doing a whole bunch of small projects or a single large project that takes the entire class? Personally I lean towards "lots of small projects for undergrads, a single big project in grad school". \$\endgroup\$
    – jhocking
    Sep 11, 2011 at 19:39
  • \$\begingroup\$ My stance is that, as important as the complete project is, for that project to be successful you first have to have already learned the basics on a bunch of previous projects. \$\endgroup\$
    – jhocking
    Sep 11, 2011 at 19:42
  • 1
    \$\begingroup\$ Which 2 previous answers? As of now, this is ranked #2, by votes \$\endgroup\$
    – ADB
    Sep 13, 2011 at 4:40
5
\$\begingroup\$

I think that you have the right idea that you should move onto the next project now. I think this because you've already learned from your first and want to apply what you've learned! Once you slow down learning the basics then that would be the time to clone deeper features that you can keep learning from.

Remember that you're working on programming skills, not game design, so you want to end up being able to program any game design when you're done learning.

\$\endgroup\$
2
  • 3
    \$\begingroup\$ While I agree with @ashes999 and you equally, I feel that in OP's stated context, he is experimenting with implementations, learning to write different types of games. In this case I think he should favour moving on to the next thing. \$\endgroup\$
    – Engineer
    Sep 11, 2011 at 18:03
  • \$\begingroup\$ Actually, he did imply that he wants to learn game design and not only game programming. In his last sentence he said "the most effective way to learn how to make my own games (not cloning someone ideas)". \$\endgroup\$
    – jhocking
    Sep 12, 2011 at 14:03
2
\$\begingroup\$

Why not make the clone "yours"? Add some new interesting twists that will keep you interested.

There is an upside to started "your own" project, you feel like it has never been done before. Reality is someone probably has something similar already. Unless you plan on inventing a new genre of gaming, I would suggest making these "clones" your own.

Example, my buddy in college created a pong "clone". He made it his own, added a whole new type of gameplay where a power-up allowed one to drive a sweet tank around for like 15 seconds and destroy as many bricks as possible!

The best way to learn game development (art, code, design) is to just do it. You may not do it well at first but the key is to just keep at it and write more code, draw more animations, and design more levels!! In my opinion, it doesn't matter if you are "cloning" something as long as you make it your own, keep doing it, make it interesting, and have fun!

\$\endgroup\$
2
\$\begingroup\$

To answer your question, yes, polishing your current project will be a better learning experience than starting a new one.

1) You need to get in the habit of finishing things. That in itself is a learning experience.

2) The tasks you are "too lazy to add" (for lack of a better term) may have a ton of game dev lessons embedded in them, that you're just totally skipping out on.

3) If you're bored of Arkanoid, you can always set it aside and work on something else for the time being. There is nothing wrong with that.

1) Too many unfinished things is bad. You can't really use your unfinished product to show off your skills effectively.

This is because having an array of unfinished things is like having a closet full of junk. Some of it looks useful, but in reality it is all very useless, and the reality of the game industry is, few will appreciate your "junk" (unfinished games).

Unfinished games are too common. People put them out there and are like, "duh, this game was sapposa be StreetFighter.. now you can move back and forth.." Unimpressive. Nobody can see in your head what the game was "sapposa" be. They only see it for what it is, unfinished.

An unfinished game is like a half-baked tart. Some people might be able to appreciate that, but it actually tastes disgusting, and 20 minutes more in the oven could make what you've already half done delicious to everybody.

2) The features you're avoiding working on may have some very valuable lessons in them.

The stuff you're balking at finishing:

Features not-implemented:

  • Power-ups when breaking the bricks.
  • Complex bricks (with more than one "hit point" and invincible).
  • Better graphics (I am not really good at it).
  • Programming polishing (use more intensively the design patterns).

Some of these things you can leave out. For example, "Use more intensively the design patterns". Refactoring like this is a waste of time for a pet project, to apply this you should just start a new project.

Some of these are easy. E.g. complex bricks. Some of these are actually a lot of work. Powerups aren't easy, they require you to feature build things like guns, bullets, would require addition of ray-intersection code.

I think what you're seeing is "putting the scaffolding in place was so easy.. and look it's almost done. Finishing would be so much work, may as well stop now." Yeah, erecting the wooden frame for a house is "easy" too, and it may be half the work. Drywalling, electricity, plumbing, are all "details". But by not finishing the house, nobody's gonna "buy" how great the house would-a been if only you would have finished it.

3) If you're bored of what you're working on, there's nothing wrong with starting something else.

This doesn't mean junk what you're working on, but there's no harm in spending a month or two thinking about other things or starting a new game. You may come back to Arkanoid with a fresh perspective.

Also a final point. Besides building out all expected features of Arkanoid, it's even more interesting to put your own twist on it. So instead of stopping short on your clone, you should take it a step further and innovate on the original game.

\$\endgroup\$
1
\$\begingroup\$

The right answer really depends on what you want to do next. If you move on to something new you may risk finding yourself solving the same old problems all over again and not really extending your skills, but you do get to move on to something new. If you continue to polish there are useful things to learn from the brief list you gave, and they will stand you good in the future, but you're still working on the same old codebase.

What I'd recommend, and this is a purely personal opinion, is to move on to something new and save the polish for that. At the same time try to stretch yourself with that something new. So if you're currently not using a 3D API, learn one and use it. If you are using one, learn the other and use it. Or move up to a more advanced level at the one you are using. Include a better sound, physics or input engine from the get-go. Whatever, what I see as the important thing is to move a little outside of your current comfort zone and build up more skills and knowledge, while having fun doing so.

\$\endgroup\$

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