This discussion is archived
1 2 Previous Next 18 Replies Latest reply: May 21, 2010 10:22 AM by 843853 Go to original post RSS
  • 15. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    cronosprime1 wrote:
    Can't vouch for Swing; I've never used it.
    That's too bad. It is a nice tool that handily lends itself to game development.
    cronosprime1 wrote:
    don't care at all about realistic timing
    I don't understand what you mean by that and why you think unthreaded code can't provide "realistic timing"
    Say for example you want to move a ball from the left side of the screen to the right side. This is an animation, even though the image does not need to change. Most novice animators just get the thing moving at a set speed, have it maintain that speed right up until it reaches the destination and then stop. It looks ok, but when people view it they almost always get a feeling like something isn't right with that animation but they just can't understand what. Well, most objects in real life don't move at a constant, they accelerate and decelerate. This is called realistic motion. Now, change the ball to a huminoid, complete with swinging arms and moving legs on an animation loop. If the huminoids legs and swinging arms move at the same speed from begining to end but the object itself moves across the screen in realistic motion, then it is going to look really bad. Sometimes you want the framerates to be controlable so you can adjust them to match the motion.

    Yes it is doable in your example, but don't you see a pattern forming here?
    cronosprime1 wrote:
    don't mind having all your animations tied to the framerait of the slowest animation
    This problem can be solved by logic to the effect of:
    if (animationInstance.timeSinceLastDraw > animationInstance.timeBetweenFrames)
    {
    animation.render()
    animationInstance.timeSinceLastDraw = 0.0
    else
    {
    animation.timeSinceLastDraw += timeSinceLastFrame
    }
    Now you are adding non animation code to be run every frame.
    cronosprime1 wrote:
    always plan to have the same animations going at once and with exactly the same number of frames
    You could definitely have a list of animations to run every frame which you add to and remove from.
    More non animation code executed every frame.

    How much extra code per frame do you think you can have before performance starts taking a noticable hit? It really isn't all that much on some of the older machines you should expect people to want to run your game on. Best way around it is threading, even on single thread processors, which are extreemly rare now since hyperthreading has been around for a long time and effectively doubles the processors power when it comes to threading.
    cronosprime1 wrote:
    and either plan on enforcing beefy minimum requirements or seriously limit the number of animations you plan to run at once
    Well, yes, at some point, your requirements get so heavy that you need more than one processor, in which case I agree threads are necessary. For high-performance apps, it does make sense to use threads for animation to allow the user maximum use of his or her system's resources.
    Seriously, there are so many tools for threads it is so easy to use them, I can't understand why so many people are so insistant on avoiding them like the plague.
    According to Guido Van Rossum, creator of Python, "unfortunately, for most mortals, thread programming is just Too Hard to get right.... Even in Python -- every time someone gets into serious thread programming, they send me tons of bug reports, and half of them are subtle bugs in the Python interpreter, half of them are subtle problems in their own understanding of the consequences of multiple threads...."

    A big problem with threads is that it is all too easy to introduce subtle, difficult-to-reproduce bugs. Because the behavior of a threaded program is in many ways non-deterministic, such a program can be very difficult to debug.
    Van Rossum never wrote Python to be good at threads, he always wanted programmers to use multiple processes instead of threads. There are advantages and disadvantages to both, but java was clearly written to take advantage of threading, and does not really suit itself to the multi process paradigm. The basic premise of multi proces and multi thread is the same though, both are splitting the work by moving it to an autonimous controller. Van Rossum is a huge proponent of multi process code, and so would most likely suggest a good python programmer use seperate processes for seperate animations.

    In Java threading is not difficult, and there are tons of tools to help make it easier. Plus animations are one of the easiest things to thread, so what better place to start learning and getting comfortable with threads?

    Edited by: JustSomeGuy on May 7, 2010 7:30 AM
  • 16. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    Another question. In a game in which a player has an inventory, there needs to be code behind the inventory to allow operations like addItem(), removeItem(), etc., but it also needs to display on the screen and update when something changes. Is it best to make the inventory itself a JPanel and add it to the UI or somehow tie the two together, maybe with a custom event and listener? Or am I thinking about this wrong?
  • 17. Re: Basic Game Design
    796262 Newbie
    Currently Being Moderated
    mattrob wrote:
    Another question.
    Then you probably should have started another thread.
    In a game in which a player has an inventory, there needs to be code behind the inventory to allow operations like addItem(), removeItem(), etc., but it also needs to display on the screen and update when something changes. Is it best to make the inventory itself a JPanel and add it to the UI or somehow tie the two together, maybe with a custom event and listener? Or am I thinking about this wrong?
    Generally, it's a good idea to separate what's displayed (the view) from what it's displaying (the model). It sounds like that would be as simple as using a regular ol' List for the inventory, and then writing a separate class (JPanel would work) that displays Lists of Inventory items.

    Another way to look at it is to give each InventoryItem its own paint method that takes in a Graphics instance as a parameter. Then in a JPanel's paintComponent, just iterate over the list of InventoryItems, calling their paint methods with the Graphics given to the JPanel's paintComponent.

    Again, there's (arguably) no wrong way to do this. Do what seems natural to you, then when you have something working, we can comment on it.
  • 18. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    JustSomeGuy wrote:
    In Java threading is not difficult, and there are tons of tools to help make it easier. Plus animations are one of the easiest things to thread, so what better place to start learning and getting comfortable with threads?
    I would argue that someone just starting out learning to program games in Java should steer away from Threads entirely. Using them would only unnecessarily complicate things - you have to worry about synchronization, etc. If you're learning to write games in Java, you will be (should be, at least) writing simple stuff first - Pong, Tetris, Breakout, Pac-Man, etc. I can guarantee you that all of these games can be written without threads, and will just fine on any machine built in the last several years.

    I'm not saying threads are bad when writing games, just that unless you're writing something moderately complex, they're completely unnecessary. And we all know the KISS principle. It's entirely possible to write 2D platformers, RPG's, and shoot 'em ups in Java without using threads. Animations can be done on the EDT at frame step boundaries (for example), and can even be advanced according to time deltas, not just on a per-frame basis, to account for things like varying system load.

    I'm not trying to be argumentative here, but I genuinely think this is bad advice. Do you honestly think advocating the use of Threads for someone just starting out in game programming, and programming in general, as the OP is? Do you think that most hobbyist game programmers have so much animation logic in their games that, even when properly designed, it will slow the EDT?

    </end-rant> :)
1 2 Previous Next