This discussion is archived
1 2 Previous Next 18 Replies Latest reply: May 21, 2010 10:22 AM by 843853 RSS

Basic Game Design

843853 Newbie
Currently Being Moderated
I'm pretty new to Java programming (and programming in general), but I understand the basics pretty well. As practice (no current plans to publish) I've been designing some basic rpg-type games, and I seem to be running into the same basic design problems no matter what the game is.

First, is there any guideline as to making multiple categories of a particular type of object? For example, creating many species of dog, or many types of enemies. Is it best to make an abstract base class (dog) and make a subclass for each category (species in this case)? Or is there a better way?

Also, what is the best way to handle an event like a battle or a race? Should it be an object? If so, would it be better to have a base class? Like an abstract class Competition and subclasses Race, Frisbee, etc.? Or should methods be built into the code for a JPanel object? Or a competition interface?

If there's already a tutorial on this somewhere, please let me know. As I said, I'm new, but I catch on quick. Thanks
  • 1. Re: Basic Game Design
    796262 Newbie
    Currently Being Moderated
    mattrob wrote:
    First, is there any guideline as to making multiple categories of a particular type of object? For example, creating many species of dog, or many types of enemies. Is it best to make an abstract base class (dog) and make a subclass for each category (species in this case)? Or is there a better way?
    That seems reasonable. If the abstract class contains only abstract methods, then you might consider making it an interface instead.
    Also, what is the best way to handle an event like a battle or a race?
    Depends on what you're doing, and how this fits into your head.
    Should it be an object?
    Could be. Then you could pass the event into a handler function that performs the appropriate animations and whatnot. Or you could have a method like dog.playFrisbeeWith(Person p). Depends on your actual requirements and how this fits into your head.
    If so, would it be better to have a base class? Like an abstract class Competition and subclasses Race, Frisbee, etc.?
    If they all have common code, then sure.
    Or should methods be built into the code for a JPanel object?
    What? Why JPanel?
    Or a competition interface?
    If they all have similar methods but all implement them differently, then sure.
    If there's already a tutorial on this somewhere, please let me know.
    I'm sure there are a ton of tutorials on basic game design. Your questions aren't really Java-specific, so maybe you should broaden your search criteria?
  • 2. Re: Basic Game Design
    gimbal2 Guru
    Currently Being Moderated
    mattrob wrote:
    First, is there any guideline as to making multiple categories of a particular type of object? For example, creating many species of dog, or many types of enemies. Is it best to make an abstract base class (dog) and make a subclass for each category (species in this case)? Or is there a better way?
    Welcome to the world of development. You are running into the main problem here: experience or lack thereof. There is no "one ring to rule them all"; every application is different, has different problems and thus has different solutions. The hardest part in programming is to FIND a solution that actually works. That requires thought, planning and designing, and the occasional mistake or two.

    In other words there is only one answer to your question: yes there is a better way, there always is. What you are looking for is a clean solution that works. What that solution is? Only you can know because only you have all the requirements.
    If there's already a tutorial on this somewhere, please let me know. As I said, I'm new, but I catch on quick. Thanks
    There are MANY resources on game development out there; its can be pretty daunting to start out so I would seriously stress that you start with the simplest game you can think of. Create pong, create a memory game, create Tetris, whatever, but make it incredibly simple and build from there.

    Websites to check out:

    http://www.javagaming.org - a very helpful forum with decent folks posting there. Clicking through the various topics may give you some idea just how involved game development really is. But there is a forum specifically for people new to the topic.

    http://www.gamedev.net - my favorite website on generic game development, plenty of articles and a large forum that has topics for everyone.

    http://www.cokeandcode.com/spaceinvaderstutorial - this series of articles takes you through the creation of a space invaders game in Java.
  • 3. Re: Basic Game Design
    794459 Newbie
    Currently Being Moderated
    Don't think about it in terms of there being one correct way to do something. Instead, think about it from the perspective of code re-use. You want to avoid duplicate code; that is, code that is in several different places but is nearly identical. Duplicate code is bad because when you want to change it, you usually want to change it everywhere, and you often forget to change it in some of the places where it occurs. Having duplicate code also makes code a pain to maintain, edit, and understand. Really, the object-oriented paradigm is all about avoiding duplicate code.
  • 4. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    Awesome, thanks so much everyone.
    Quick question just to make sure, though. There's no standard practice here? That's really why I was asking. I can figure out a way to do it, but I'm teaching myself for now and I don't want to practice something "wrong" in the sense that there's a different way that everyone does it.
  • 5. Re: Basic Game Design
    794459 Newbie
    Currently Being Moderated
    The standard practice is just what I said earlier. Avoid duplicate code like the EMP, and write your code so that it is easy to read and maintain. For a medium to large game, you generally will end up having superclasses and subclasses, and you might have some abstract classes and interfaces as well.

    I've found that in pretty much every game I've made or tried to make, it was useful to have a VisualThing class, an abstract class extended by every type of visual entity. VisualThing may contain position, etc. instance variables as well as code for collision detection and the like. In my 3D program, VisualThing also contains a rather large amount of code for initializing models and setting their appearance properties.

    Edited by: cronosprime1 on Apr 28, 2010 12:13 AM
  • 6. Re: Basic Game Design
    gimbal2 Guru
    Currently Being Moderated
    cronosprime1 wrote:
    I've found that in pretty much every game I've made or tried to make, it was useful to have a VisualThing class, an abstract class extended by every type of visual entity.
    Yep, I have something similar. Only I call it 'GameEntity' :) I guess most games will have the 'entity' structure, classes for the game loop, classes to maintain game world state (I tend to go for GameWorld and GameLevel) and many more. In most games I split animating entities and static entities from each other, for optimization reasons (static entities don't update for one).


    I also have a structure which I call "kernels". A kernel has the task of updating the state of a certain element of the game. There is only one kernel active at a time. I have the MainMenuKernel, the LevelKernel, the GameOverKernel, the HighscoreKernel, etc.

    The way it works is that kernels can be chained - a kernel can then finish and control will be passed along to the next kernel in the chain. If there is none, the game quits to the desktop. Checking state of the current kernel and chaining the next one if needed is done in the game loop.

    So a simple flow could be:

    MainMenuKernel -> start game (chains LevelKernel and finishes)
    LevelKernel -> player loses all his lives (chains GameOverKernel and finishes)
    GameOverKernel -> player presses the spacebar (chains MainMenuKernel and finishes)
    MainMenuKernel -> quit game (finishes)
    no kernel active = application exits

    To give some more examples, I also have used at certain times FadeInKernel and FadeOutKernel, InGameMenuKernel, etc.
  • 7. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    I agree with gimbal2.

    Create something extremely simple (I usually suggest Tic Tac Toe, simplest game I can think of coding-wise).

    Once you have the basics down (double buffering to keep the graphics from flickering, user input, simple stuff like that), try making something that uses animation, Tetris for example. Unless you want to make a game with 3D graphics, complex AI or networking, it never really gets more complex than Tetris.

    Your game then looks like this:

    initialization / main menu
    game loop
    ...wait till the next frame should start
    ...apply all user input to the data model
    ...advance the game world one frame
    finalization (go back to main menu, exit program, ...)

    One thing that I've learned the hard way was that it's really best to make the whole game single threaded, if possible (only thing I usually put in an extra thread is AI. I guess for 3D stuff where you want to use another CPU core for the drawing would be a similar case,never tried that though). Just store all user input in a queue (instead of executing it when it occurs) and apply it to your data model before calculating the next frame of your game, in the game loop. This way you avoid data corruption without having to put "synchronize" everywhere and having to track where concurrent changes might corrupt things in spite of "synchronize" tags

    Edited by: Zyphrus on Apr 30, 2010 12:24 PM
  • 8. Re: Basic Game Design
    794459 Newbie
    Currently Being Moderated
    One thing that I've learned the hard way was that it's really best to make the whole game single threaded, if possible.
    I agree. Writing bug-free non-threaded code is hard enough. Writing bug-free threaded code is extremely difficult. However, sometimes there's no choice if you're using complex networking and the like.
  • 9. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    I completely agree with the start with something simple, then do something a little harder, then something a little harder still method for learning to write games. I recently found a way of incorperating some of my early simple games into a complex multiplayer game by making it so when a player is waiting for another player to finish their turn they are waiting in "the arcade" where they can play some of the earlier simpler games, and how well they do has a really small impact on the overall mulitplayer game. Stuff like "get over xxx points at game Y to get a hint on the location of object Z".

    I completely disagree with the avoid threading comment. I mean, if your game has zero animations and is small, then sure I can agree you should not add the extra complexity of threads. But if your game does any animations at all, and those animations are not threaded, your game sucks, period. Chet Haase and Romain Guy, two of the bigest names in computer animation programming (especially in Java) agree with me.

    It is simple really, no one wants to wait for an animation to ifnish before they can interact with the GUI. In fact, in most games it is imperative to the game that the user be able to interact with the GUI while animations are running. Sure if you single thread it you can put checks in your animation to look for user events, but then the animation gets real clunky and looses the smooth that makes animation believable. Best solution, threads! Besides the second you use swing you are multithreading, and I seriously hope you all are not advocating adding complex animations to the EDT.

    JSG
  • 10. Re: Basic Game Design
    gimbal2 Guru
    Currently Being Moderated
    I completely disagree with the avoid threading comment. I mean, if your game has zero animations and is small, then sure I can agree you should not add the extra complexity of threads. But if your game does any animations at all, and those animations are not threaded, your game sucks, period. Chet Haase and Romain Guy, two of the bigest names in computer animation programming (especially in Java) agree with me.
    Complete and utter nonsense. It makes absolutely no difference if you play animations using threads or sequentially in a single thread - whatever happens they need to be synced to a steady framerate for your game to "not suck". Either way, it can be done with exactly the same result and I dare say the single threaded approach is quite an amount easier, if only you know how - which you don't seem too, judging by your post.

    Oh and by the way, you agree with these two blokes, not the other way around.
  • 11. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    I've never seen a non threaded complex animation that didn't suck. I suppose if you are not using swing, stick to only one animation at a time, and have a very limited (or keyboard only) interface it is theoretically possible. I personally hate slow unresponsive interfaces, and I believe most people are like me in that regard. If you are doing any sort of complex animation and you are using swing with no extra threads then it is going to wind up blocking the EDT, thus leading to a slow unresponsive interface.

    Plus threads are not that difficult, mastering the threading model does not require very much effort. And using threads correctly makes code more readable and thus easier to maintain.

    You are correct that a framerate of 20 to 30fps or more is ideal for smooth animation, but fps and syncing are far from the only things necessary for good smooth animation. For example the shape and hardness of the animations edges, realistic timing, color vrs background color, and realistic motion all play a great role. But even if you get all those right and the animation is beautiful, if I can't click on any of the buttons on the screen until the animation stops, or worse have to wait for the animation to stop before my click is registered and dealt with, then the game sucks. This is what happens when you don't use threads.

    But since you seem to think you know a better way, please impart some of your information with the group. Because I must say, you are right, I have no clue how to sync up two or more autonomous animations and still have the ability to interact with swing componenets on the interface, all with less complex and easier to read and maintain code than if it were done with threads. If you really know how to do that, please share it as I would love to use it.

    JSG
  • 12. Re: Basic Game Design
    794459 Newbie
    Currently Being Moderated
    I don't know about Swing specifically (I've never used it), but I don't see why you can't just have code to this effect (pseudocode):
    method executeEveryFrame (timeSinceLastFrame) 
    {
        advanceAnimation1 (timeSinceLastFrame)
        advanceAnimation2 (timeSinceLastFrame)
        checkEventQueueForUserInput ()
    }
    That way user input would be checked for every frame. One check per frame is a pretty responsive application if the app is running at 20-30 fps.


  • 13. Re: Basic Game Design
    843853 Newbie
    Currently Being Moderated
    That works fine; if you aren't using swing, don't care at all about realistic timing, don't mind having all your animations tied to the framerait of the slowest animation, always plan to have the same animations going at once and with exactly the same number of frames, and either plan on enforcing beefy minimum requirements or seriously limit the number of animations you plan to run at once. Getting that dance to flow smoothely sounds like a nightmare, and is certainly much harder than getting familiar with threads.

    Use swing and you are going to be placing your individual frame events on the EDT. This doesn't sound bad if you no little or nothing about the EDT, but if the EDT decides to concentrate on something else for a bit and a few of these animations pile up the EDT is just going to choose to jump to the latest frames which means your animation just skipped a bunch of frames and has jumped as well. Start putting to many of these frames from different animations on the EDT and the frames from some animations will make others get skipped.

    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. Especially since newer provessors MUST have threaded code to run the code faster. If your code has no threads 3 of the 4 processors in that shiny new I7 or I5 or quad core or whatever, are doing jack and squat. Do threading right and multiple animations can make use of multiple processors. So why is everyone afraid of threads?
  • 14. Re: Basic Game Design
    794459 Newbie
    Currently Being Moderated
    if you aren't using swing
    Can't vouch for Swing; I've never used it.
    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"
    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
    }
    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.
    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.

    Edited by: cronosprime1 on May 6, 2010 5:37 PM
1 2 Previous Next