10 Replies Latest reply: Jan 17, 2010 12:05 PM by 843853 RSS

    the structure of a game

    843853
      I am pretty new to game programming. I have made a few small games in the past working with classmates or alone, but most of the time I attempt to make a larger game, on my own I end up getting side tracked (homework or life in general). When I come back to continue working on these projects I find that its hard to sort through my old code. I saw a recent thread "[Building A Game On Your Own|http://forums.sun.com/thread.jspa?threadID=5422829&tstart=0]", but I want to ask a different, sort of related, question.

      First off, I know comments, naming conventions, uniform white space patterns (you know just neat code) are essential to writing readable code. Although my code isn't comment heavy, I think my problem is that I have no idea how games are structured.

      I think the obvious place to start is creating a window for the game to take place in, and then deciding what other parts the game needs. I suppose the structure of the game or even engine depends on the type of game, but can anyone provide some general guide lines for the structure or organization of a game.

      For example in the past I have attempted to emulate the way XNA Studios has specific functions or methods in a "Game class" for handling different parts of the game (Although I was working in C++). A method of loading resources, a method for initializing game objects, a method for updating game objects, and a method for printing objects to the screen. Now that I think about the Java Applet class has a very similar structure, I hope that doesn't kill my discussion proposal.
        • 1. Re: the structure of a game
          843853
          To start off with you you'll need an animation loop:

          JPanel and a Timer are great for implementation of this.


          As for the rest, are you looking for a simple game like checkers or are talking something a little more epic here like runescape?
          • 2. Re: the structure of a game
            843853
            I'll just comment on one small aspect of your original post. That of coming back to a project after some time spent in the real world, and finding it difficult to pick up where I left off.

            I have an ongoing game project as a hobby, and I have the same problem as you. In addition to following game structure and proper documentation., When I do a significant update, I review the work a few days later to provide re-inforcement. Breifly returning to the update after a few days away really helps my long term memory of the work done.

            hope that helps.
            • 3. Re: the structure of a game
              843853
              morgalr wrote:
              To start off with you you'll need an animation loop:

              JPanel and a Timer are great for implementation of this.


              As for the rest, are you looking for a simple game like checkers or are talking something a little more epic here like runescape?
              I'm actually thinking of something closer to runescape (though I have never played it) than a simple game like chess or tic-tac-toe. An epic scale project instead of a small one (at least epic scaled for a single programmer). My most recent attempt to make a game is a 2D RPG.

              In my current project I have multiple animation threads. For example: one thread to animate the map (scroll the map, or current zone, below the character fixed in the middle of the screen), and a thread for each character's (PC or NPC) sprite animation.

              I am more looking for guide lines for keeping my self organized, rather than
              "What should I do next? / Where should I start?".

              To start, I feel like the organization of my classes could be all wrong. Here are some of the classes I created for my RPG. Tell me if I am separating these classes in a logical way, or am I segmenting the project/code to much?

              Game_C: extends Applet, is the window the game takes place in.
              Map: extends Panel, on this panel the game is played. (I called it the map because it holds the map of the current zone).
              Console: extends Panel, contains a text field and text area used for speaking to NPCs and possibly PCs.
              Zone: A custom data structure for holding map information, also creates a bitmap image that is the zone/map by reading from a file.
              Character: the super class for NPCs and PCs.
              WorldObserver: This is one of the last classes I created before getting side tracked. At a certain point I decided instead of doing collision checks in the Character class(es), I should create a class that actually contains all the game objects and "observes" them to make sure nothing happens that shouldn't happen (collisions mostly at this point).

              The reason I created the "WorldObserver" class was I was getting sick of passing information around to all objects needing to check for collisions. Instead of character.move() requiring information out side of its scope. The "Observer" has the ability to see and move all the objects. Does this sound like a good idea?

              There are more, most of them incomplete. These are some of the basic nuts and bolts classes I have finished and working. At this point in my game I can move the character around on some sample maps, zoning between two little maps works just fine, and I can create NPCs and have them chase the character (but they get stuck on objects, they don't know how to walk around yet). If you would like to see my code for some of these classes I would be happy to share, just ask.

              I have another questions about creating and organizing classes related to combat skills, professions, and threads for AI, but lets just stick to what I have got so far.
              • 4. Re: the structure of a game
                gimbal2
                Might I ask why you want to make your life so difficult with all the threads? Why not use one timer task that fires for every update cycle (each 17 milliseconds if you want to do 60FPS). This one timer task will then update and draw the entire world, including updating movements and animation frames.

                For my own animations I just keep track of when the last frame was displayed and when the next frame should be displayed. Each update cycle the logic checks if it is time to move to the next frame (or loop back to the first one) based on the current time.
                • 5. Re: the structure of a game
                  843853
                  gimbal2 wrote:
                  Might I ask why you want to make your life so difficult with all the threads?
                  I thought I had already answered that question. Its because I don't know what I am doing.

                  To be honest, it wasn't that hard to through together. Besides, if I avoided any the hard stuff I probably wouldn't learn anything.
                  gimbal2 wrote:
                  one timer task will then update and draw the entire world, including updating movements and animation frames.
                  The WorldObserver class I created does the updating then starts a thread for animating. Oncethe observer has checked if a characters next step is not a collision it moves the character (or calls the object's move) then starts the character's animation thread, which really only changes the index to an array of images. When the animation needs to stop (in the PCs case when the movement key is released) the world observer calls a stop animation method, which simply toggles a boolean to false, so the next time the animation loop is about to execute it skips over the animation loops body and ends the thread (my animation loops do not run constantly ie "while (true)" they run while animation is needed, ie "while (isAnimate)" this way they do not constantly use processing power. ). It's actually the Map class that does all the drawing, It draws the map (backdrop) then draws all the characters on the screen by drawing what ever image the animation has made available (the animation is simply changing an index to an array of buffered images).

                  Yeah its more complex and probably a silly way to do things, huh?

                  Edited by: lessThanNate on Jan 18, 2010 10:03 AM
                  • 6. Re: the structure of a game
                    843853
                    lessThanNate wrote:
                    Yeah its more complex and probably a silly way to do things, huh?
                    I guess what I am asking is:

                    Is it so silly that it was a bad idea to do it this way?
                    • 7. Re: the structure of a game
                      796262
                      Here is how I would/do set up a game:

                      There are three main pieces of any game: the actual objects in the game (characters, walls, etc), the processing that changes the state of those objects, and the thing that draws them all.

                      The actual game objects are where most of your programming should go (which is fine, because they're the most fun anyway). Each object should know how to draw itself, and how to update its own state.

                      That makes the other two pieces easy. For processing, simply have a method containing a single loop that iterates through the game objects, and tells them to update themselves (a GameObject could have a method called update). Things like walls won't do much, but things that move will do that there.

                      Similarly, the thing that paints everything will probably be an extension of JPanel with an overridden paintComponent( ) method. In paintComponent, simply iterate through all of your GameObjects, telling each to paint itself to the Graphics object passed into paintComponent( ).

                      Then you just have to combine them all, which is easy if you already did the individual pieces. Your main Game class will create all of the GameObjects and the class that overrides JPanel. Then you start a Thread with a loop that calls the update method, tells the JPanel to repaint, and sleeps for 17 ms or so. Voila!

                      The single most important piece of advice I can give you is to start small. Get a single character moving around on the screen, using the setup I outlined above. Then it should be relatively easy to add other objects to the game. Then worry about interaction, and the bigger picture of where you want the game to go.

                      Anyway, that's my 2 cents. Take it or leave it.
                      • 8. Re: the structure of a game
                        gimbal2
                        kevinaworkman wrote:
                        Here is how I would/do set up a game:

                        There are three main pieces of any game: the actual objects in the game (characters, walls, etc), the processing that changes the state of those objects, and the thing that draws them all.

                        The actual game objects are where most of your programming should go (which is fine, because they're the most fun anyway). Each object should know how to draw itself, and how to update its own state.
                        Update yes, but draw... I like to handle that by simply having a common interface 'getFrame()' which returns the current frame to display on animated objects and a static image for non-animating objects.

                        >
                        That makes the other two pieces easy. For processing, simply have a method containing a single loop that iterates through the game objects, and tells them to update themselves (a GameObject could have a method called update). Things like walls won't do much, but things that move will do that there.
                        That is why I split those two up into two different sets: static objects (which will never get updated) and actors (which are animating/moving objects). When doing collisions I check both sets, when doing updates I only iterate over the (active) actors.

                        >
                        Similarly, the thing that paints everything will probably be an extension of JPanel with an overridden paintComponent( ) method. In paintComponent, simply iterate through all of your GameObjects, telling each to paint itself to the Graphics object passed into paintComponent( ).
                        That's what I don't find logical; the paintComponent() in my case will simply ask the 'frame' to draw of the object, and draw it at the objects position. An object should have no idea how it should draw itself, as that might change depending on the container it is actually drawn in.

                        >
                        Then you just have to combine them all, which is easy if you already did the individual pieces. Your main Game class will create all of the GameObjects and the class that overrides JPanel. Then you start a Thread with a loop that calls the update method, tells the JPanel to repaint, and sleeps for 17 ms or so. Voila!

                        The single most important piece of advice I can give you is to start small. Get a single character moving around on the screen, using the setup I outlined above. Then it should be relatively easy to add other objects to the game. Then worry about interaction, and the bigger picture of where you want the game to go.

                        Anyway, that's my 2 cents. Take it or leave it.
                        Heartily agree with this last part.
                        • 9. Re: the structure of a game
                          843853
                          kevinaworkman wrote:
                          Anyway, that's my 2 cents. Take it or leave it.
                          I'll take it. That is the kind of answer I was looking for, and surprisingly, that is almost identical to the approach I usually take when creating a new game project.

                          My first attempt to make a simple game engine was in my Object-Oriented Programming with C++ (about 1.5 years before I started Java), It was just a simple shape drawing program in the end, but it had many of the features you described.

                          The main class I created was in charge of creating the application window and drawing objects when needed. The objects I created were named Circle, Square, and Triangle, and they all were subclasses of my super class, Shape, which had a method named "draw" that all the subclasses had to override. Back in my main class's paint method all I had to do was loop through and array of shapes and call the Shape.draw method.

                          Its a simple set up, but I like it.

                          When I get time I have many more questions, but school starts back up today! No programming classes this semester, not excited about that.
                          • 10. Re: the structure of a game
                            796262
                            gimbal2 wrote:
                            kevinaworkman wrote:
                            Here is how I would/do set up a game:

                            There are three main pieces of any game: the actual objects in the game (characters, walls, etc), the processing that changes the state of those objects, and the thing that draws them all.

                            The actual game objects are where most of your programming should go (which is fine, because they're the most fun anyway). Each object should know how to draw itself, and how to update its own state.
                            Update yes, but draw... I like to handle that by simply having a common interface 'getFrame()' which returns the current frame to display on animated objects and a static image for non-animating objects.
                            Let me see if I understand your setup: each GameObject implements GameFrame (or whatever you want to call it), which requires a getFrame( ) method. And getFrame( ) returns an Image?

                            This setup makes sense, because then the Game can get each GameObject's image by calling getFrame( ), and draw it wherever (and with whatever width/height), depending on the view.

                            I guess I'm hung up on the "tell, don't ask" rule of thumb. Wouldn't that rule point to the idea of a game telling each GameObject to draw itself, rather than the Game asking each GameObject for its image, then for its location, etc? I'm honestly asking and not trying to debate in either direction, as the "tell, don't ask" thing is something I've only recently learned to enforce in my own code.

                            That makes the other two pieces easy. For processing, simply have a method containing a single loop that iterates through the game objects, and tells them to update themselves (a GameObject could have a method called update). Things like walls won't do much, but things that move will do that there.
                            That is why I split those two up into two different sets: static objects (which will never get updated) and actors (which are animating/moving objects). When doing collisions I check both sets, when doing updates I only iterate over the (active) actors.
                            Yeah, you're right. I would probably do the same thing (and potentially have a third set of non-colliding objects that only get painted, like, um, clouds maybe).

                            Similarly, the thing that paints everything will probably be an extension of JPanel with an overridden paintComponent( ) method. In paintComponent, simply iterate through all of your GameObjects, telling each to paint itself to the Graphics object passed into paintComponent( ).
                            That's what I don't find logical; the paintComponent() in my case will simply ask the 'frame' to draw of the object, and draw it at the objects position. An object should have no idea how it should draw itself, as that might change depending on the container it is actually drawn in.
                            Fair enough. I can understand separating the model from the view, but then doesn't that get into the "tell, don't ask" issues I asked about above?

                            >
                            >>
                            Then you just have to combine them all, which is easy if you already did the individual pieces. Your main Game class will create all of the GameObjects and the class that overrides JPanel. Then you start a Thread with a loop that calls the update method, tells the JPanel to repaint, and sleeps for 17 ms or so. Voila!

                            The single most important piece of advice I can give you is to start small. Get a single character moving around on the screen, using the setup I outlined above. Then it should be relatively easy to add other objects to the game. Then worry about interaction, and the bigger picture of where you want the game to go.

                            Anyway, that's my 2 cents. Take it or leave it.
                            Heartily agree with this last part.
                            All I have to do is learn how to follow my own advice ;)