Structure of Game Classes

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|729\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> On Topic -> Structure of Game Classes
Wed, 21 Oct 2009, 14:20
Nolan	I have always been terrible at organizing my games, and usually end up becoming frustrated at my inability to design. That said, I figured I might as well ask and see what people suggest as a good structure for a game. In my current game, a remake of rodent's revenge (In Java + Slick 2d), I have a Game class, which holds the game data, such as the screen height/width, etc. The Game class also holds aa Grid type representing the tiles (this is a tile-based game). Then I have a Mouse class, which is controlled by the player. My question is this: Where should the instance of Mouse reside, and where should the control be? For instance, should the Game class hold an instance of Mouse, or should the Grid class hold this instance? How should the mouse be rendered -- in a class method, or from another class? Should the Mouse know where it is in the Grid? etc.. -=-=- nolandc.com
Wed, 21 Oct 2009, 15:14
JL235	In Java I use a system of Worlds and Actors. A World is an Actor that can hold Actors and can perform tasks with them; namely collision detection and painting layers. An Actor is a class with a location, size and two methods: act (for updating the actor) and paint (for painting the actor). There is also a Display to represent the screen, a GraphicsGL object to wrap up all my common OpenGL commands (which is passed into the paint method of the Actors) and a MainLoop to bind the Display to the root World of the game. Using Worlds and Actors to design your game is kinda like using Swing to design a GUI. You have a root World (i.e. a JFrame), in there perhaps two Worlds for the game and title (like two JPanels in a JFrame) and in them there are players, enemies, buttons, etc (like JComponents in a JPanel). In my signature is a link to my website. All of the games on that site were built using Java. They were all built using the above structure.
Thu, 22 Oct 2009, 11:01
LostUser	Could you organise your application similar to the MVC style (model-view-controller)?
Thu, 22 Oct 2009, 12:15
JL235	I'm not really an expert on MVC, I only know what's on Wikipedia. But IMHO not to the same extent as Swing. There is nothing to stop you crossing the painting and game logic together. But I personally always make changes in the act and only paint in the paint function. There is nothing to stop you extending it further so that say the paint functions just pass the input on to separate renders, allowing gameplay logic and rendering to be fully separate. But IMHO this is needed far more for GUIs then games. You might want to change an app so it can have a web, command-line or GUI front end. You'd very rarely want to do this with a game. You'd also want to be able to reskin Swing for use on different OSs (so it looks like a native app), you'd rarely want to reskin a game for use on different machines (apart from offering a lower quality version for low-end PCs).
Thu, 22 Oct 2009, 15:05
Nolan	MVC always seemed more suitable for applications, not games. I do split up my updating and rendering, but I don't really have a controller in the MVC sense. -=-=- nolandc.com
Thu, 22 Oct 2009, 20:08
Evil Roy Ferguso	MVC actually works quite well for games, although "controller" does occasionally seem unnecessary for many game objects, and in those cases I tend to leave it out. One reason to separate model and view is to easily allow multiple representations of the game -- for example, if you're writing an overhead tile-based game, you could write a view to display the game in 3D without having to touch any of the classes where your game's logic has been implemented, while retaining the 2D mode. If you've played the recent Monkey Island remake, separating view from model would also make something like its "switch between classic and new in-place" function much easier to implement.
Fri, 23 Oct 2009, 08:58
LostUser	I can only talk about my experience with MVC with PHP and with Blitz Basic 2D. I've started to build my game in MVC, mainly after some playing around with the PHP framework CodeIgniter and also because the game is more of an application style, rather than an out-and-out game. I put all my data related stuff in the model, such as structs (types in Blitz Basic), data calls, image loading -- my controllers do all the decisions, the loops, switch statements and stuff like that whilst my view is just a function which prints to the screen, which returns button calls. Admiteldy the callback feature in Blitz Basic probably isn't a good example as isn't really as feature rich as say Java. I've heard that IPhone and Android does MVC, I don't know if this is true. Either way, I would try a simple game/test and if helps you then great; if not perhaps one of the other patterns will be more beneficial.
Fri, 23 Oct 2009, 10:38
Phoenix	Good designs usually don't appear the first time. Use an approach you feel works, and afterwards you can evaluate whether it was an efficient way of doing it or not. If it turns out it was an inherently flawed idea, then you're one mistake wiser. In all likeliness, it doesn't matter where the mouse is stored. I have a tendency to think a bit too much about design and a bit too little on actual, working code. It's not a good habit.