Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I posted a similar question on the Programmers SE site. Please read it. I want to know what specific things I can do to help me create games faster.

Already, in addition to whatever I wrote there, I am:

  • Creating reusable libraries on top of existing engines that I'm using
  • Creating reusable assets (graphics, sounds, icons)
  • Finding sites where I can find assets quickly (graphics, sounds, icons)
  • Using game engines instead of writing code from scratch
  • Using agile so my game is customer-focused and gets results
  • Biting off small games (like a vanilla rogue-like)

I feel it's not enough; I'm taking far too long to make games. A simple chemistry puzzle game, for example, took nearly 40 hours -- and that's with only half-decent graphics.

What are your recommendations? How can I get better and faster?

share|improve this question

closed as too broad by Byte56 Nov 6 '13 at 14:35

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Please tag. Thanks. –  ashes999 Apr 6 '11 at 19:34
1  
I haven't created any games yet, but i'd love to hear from more people about the 40 hours thing, it's less than a week of work, how is that not super-fast for developing an application... –  Zaky German Apr 6 '11 at 20:33
    
@Zaky German I was coding around 2.5-5 hours per week; at 40 hours with FlatRedBall, I made a decent 2D Silverlight puzzle game. I did all the graphics and stuff too (which was harder than the programming!) –  ashes999 Apr 6 '11 at 22:47
1  
I think it means if you want it still to be good, but faster, it'll cost more. For example your game represents a 2D point on a graph like this, you need to decide where to move the point to get the results you want. (Moving closer to fast, while keeping the same "good", moves you farther from cheap). –  Byte56 Nov 6 '13 at 14:39
1  
@Byte56 Precisely. If you want your game to come together good and fast, you need to spend a little dough. Buy assets and or contract an artist and have them custom made. Don't work by yourself -- work with others that have skillsets that complement your own (this means splitting revenue). Further ahead, you could license an industrial game engine (which itself will have some ramp-up learning time, but it should make generating the final product much faster). Sometimes "the good" software is very expensive and you're left mucking around in open source clones.. avoid that. –  bobobobo Nov 6 '13 at 16:16

1 Answer 1

up vote 2 down vote accepted

The answers in your other question mention typing faster. Something else to consider is, are you spending most of your time actually coding, or thinking about a problem you need to solve? If it's the latter, then one suggestion would be to practice problem solving. If it's the former, then maybe you should look at your typing speed and see if you can improve anything there.

One thing to point out is that it might be worth getting more practice. Participate in a gamedev competition like Ludum Dare or the 7day roguelike event. The more practice you have in making games, the easier it'll be to make the next one.

Finally, games still take a lot of time, and good quality games take even longer. Practice helps, but sometimes it just takes 40 hours to make a game.

share|improve this answer
    
+1 I didn't consider competitions as a good way to improve. I don't get a lot of big blocks of time to code, but pressure will still help accelerate me forward. –  ashes999 Apr 6 '11 at 20:26
    
+1 for Ludum Dare, the next one is in just a few weeks; give it a try! –  Ricket Apr 7 '11 at 13:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.