1

Hey guys i'm making my first 2D Java game and I am currently using Timers to control and update everything. I was wondering what method was best for a 2D Java game, Timers or Threads? currently I have a Timer in my gameCanvas class which renders/draws everything aswell as checking collision. I Then also have a Timer for my player, which is used for moving him.

The only reason I used timers is because I'm new to Java Programming and it seemed the easiest way at the time considering all I had to put was this:

Timer timer = new Timer(5,this);
timer.start();

What would you guys recommend?

Duncan Palmer
  • 2,865
  • 11
  • 63
  • 91

2 Answers2

4

What pst says about the pros and cons of the two approaches is absolutely correct.

However, I wouldn't recommend either. I would use a "designed for games" game engine such as Slick2D, and it will help you immensely with the update and logic in a game, the structure of the main game loop, as well at take care of a lot of the low-level issues you'll run into.

If you're considering using Swing for games, I would also stay far away from that, for the reasons outlined in my answer here.

Slick2D comes pre-built to handle the timing issues, and figuring out the deltas between rendering frames, etc. You also get a lot of nice stuff that you don't have to build on your own, such as input handling (keyboard, mouse, controllers), accelerated graphics (your games will automatically benefit from graphics acceleration because the engine takes care of this for you), and when you get ready for audio it also has a great audio library.

Writing all this stuff yourself is going to make you want to cry. Unless you're really into building the engine itself (as opposed to wanting to spend your time building the game logic itself), building engines is a lot of time spent when you could just use a mature tool off-the-shelf.

Community
  • 1
  • 1
jefflunt
  • 33,527
  • 7
  • 88
  • 126
  • Writing it from scratch is funnnnnnnnnnnnnnn! fuunnn I say! ;-) +1 –  Oct 17 '11 at 03:11
  • 1
    :) It definitely can be. I've just learned that I prefer to spend my time on the game, and not the tool. It's definitely a personal preference. Some people love building tools. Just not my thing. – jefflunt Oct 17 '11 at 03:12
  • Thanks for the reply, I would rather prefer to write everything myself as it gives me a sense of accomplishment. I am currently using swing for my game, would you recommend AWT? – Duncan Palmer Oct 17 '11 at 03:12
  • 3
    In years of listening to people write to tell me about their games for sites like DevGames.com and then later GameDev.net, I could count on the fact that the ones that told me all about the sprite library/3D library/or game library they were building first were never ever going to finish an actual game. It just doesn't happen. If you haven't ever built a game you have no clue what to put into the library in the first place and should you actually complete it, you quickly find out that it saved you no time in the building of the game. – John Munsch Oct 17 '11 at 03:16
  • @Duncan - I wouldn't really recommend Java's built-in UI classes for games at all. In terms of the way Java is actually used, most of it in the real world is enterprise/server software, and very few things are actual Swing (or AWT) based desktop applications. Doesn't mean you can't use it for games - just avoid the UI libraries. Java's target audience never was desktop apps. That's really a long way of me pointing you to the game engine again. I get the sense of accomplishment thing, but I agree with John's comment that it never really happens. – jefflunt Oct 17 '11 at 03:22
  • To say it another way, it's kind of like saying you want to write a game to run on Windows machines, but rather than use DirectX (a widely used, mature, bugs already worked out library), you want to write your own library because it would be fun. Trust me - it ain't fun. – jefflunt Oct 17 '11 at 03:27
2

It depends on the type of game.

For a "fast game" (e.g. a shooter) a dedicate game loop (perhaps in a thread) with a yield/wait (as appropriate) will generally function best. For a "slow games" timers will work just fine -- there are however, two types of Timers:

  1. a "Swing" timer (javax.swing.Timer)
    1. advantage: runs on the EDT so can touch Swing/AWT objects
    2. disadvantage: runs on the EDT so has poor resolution and timing guarantees
  2. a "service" timer (java.util.Timer)
    1. advantages:
      1. supports "fixed rate" timer
      2. runs on own thread (so resolution/consistency is better, but not guaranteed)
    2. disadvantages: does not run on the EDT (so can't touch Swing/AWT).

In many cases the game must still compute the "delta" between when the last event occured and when the current event occurred and use this in calculations. Without a model that uses a delta, game speed will vary between systems.

Personally, I would recommend LWJGL: Lightweight Java Game Library which offers a high-resolution clock well suited for "fast game" loops. It also supports "direct" OpenGL bindings ;-)

I do not have any experience developing "slow games".

Happy coding.