2

I have just finished a 2D game in Java that I've been working on for a while.

I found that on some computers it runs fine, and on others (which are not particularly slow in general), the game runs a little slower, and with minor interruptions every second or so. Not completely smooth.

Since I am a beginner to making games, and probably since I didn't plan everything about the game in advance, the code of the game is rather long, clumsy and probably inefficient.

I want to improve this in my next projects. So my question is - In general, what would be the main causes for a common 2D game to slow down on a computer?

What should I pay the most attention to, next time, in order to design an efficient game?

  • Making a small amount of classes? (Even if the classes are small ones?)
  • Avoiding repetition of code? (Even small sections of code, such as short if statements).
  • Avoiding too many threads running?
  • Anything else?

Obviously, all of the above are recommended for an efficient program.

But I'd like to know, what in a game's code, could be especially significant for making an efficient application, and what would be less important and will not save significant amounts of memory.

Any advice would be welcome - could be regarding game design, or regarding more specific coding issues.

I don't know if this matters, but please note that I'm talking mainly about real-time games, using a 'game-loop' that constantly updates the game and the dispaly.

Charles
  • 50,943
  • 13
  • 104
  • 142
user3150201
  • 1,901
  • 5
  • 26
  • 29
  • Not exactly the place for this, but it's such a cool question that I want to hear the responses. If/when this gets closed, make a similar post on a different StackExchange and link it here! – Stachu Jan 24 '14 at 15:08
  • 3
    It could be sooo many things. Use a performance tool to check heavy utilized code blocks. Check especially thight loops in your code – Frode Jan 24 '14 at 15:08
  • @Frode What's a 'performance tool'? – user3150201 Jan 24 '14 at 15:09
  • 1
    @user3150201 profilers – Jakub Kotowski Jan 24 '14 at 15:12
  • http://en.wikipedia.org/wiki/List_of_performance_analysis_tools#Java goto the Java list – Frode Jan 24 '14 at 15:13
  • Can we see your code? Again, SO is totally not the place to paste your GitHub repo and ask "What's wrong!?" I'd just like to look at this in more depth as a personal challenge. – Stachu Jan 24 '14 at 15:13
  • @statue My code stretches over I think eight classes, and it's pretty long. Could the main problem be that my game-loop runs in a thread? I tried using a swing timer, but then the game didn't run in constant speed. – user3150201 Jan 24 '14 at 15:17
  • What you describe sounds like a threading issue (otherwise it would probably behave the same way on all machines). Difficult to say much more without seeing the code. – assylias Jan 24 '14 at 18:16

1 Answers1

2

The important thing when trying to improve the performance of any program, not just a game, is - don't guess.

If I or anyone says "it's in your collection classes", or "it's in your rendering", or "it's in your memory management", or "it's in your compiler optimization", can you trust it? Short answer - No - because it's a guess. It could be true. It could be false. Nobody knows, in your case.

People who say instead of guessing "Use a profiler" are on the right track. In my opinion there's an even better method, spelled out here. If you need to know why, I'll explain it further, but the hard part for any programmer is to stop trying to think it out, and let the tool tell you what to look at.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • +1 although different behaviours across machines is often due to threading problems which can't be easily detected through profiling. – assylias Jan 24 '14 at 18:17
  • 1
    @assylias: If you've got a debugger that can pause all threads at the same time, like Visual Studio, then my method does work. Where it gets difficult is if there is so much cross-process communication that it's hard to tell what the whole thing is waiting for. – Mike Dunlavey Jan 24 '14 at 18:20