   Separating my game into modules
  Hi guys, I want to separate all of the aspects of my game into modules. For example I want graphics to be separate from everything else, like game logic and sprite control etc. And then, then the main class will just glue together all of these blocks.I'm building my game in java by the way.How do people generally build games?   
Quote:Original post by S-DawgHi guys, I want to separate all of the aspects of my game into modules. For example I want graphics to be separate from everything else, like game logic and sprite control etc. And then, then the main class will just glue together all of these blocks.I'm building my game in java by the way.Okeydoke.Quote:How do people generally build games?That's way too broad a question to give a useful answer for.   ;  Okay you're right, my head was just buzzing with all my questions.Is there a template or general method that people adhere to when making (2D) games?   ;  I think you want something like Model View Controller. That's the design pattern that I'm trying to use in my game/engine to separate graphics from logic, etc. A search on google or on GD will give you some info on it.   ;  There is no template, it's a process that (at least from a hobbyist perspective) takes into account common software architectural patterns, your own goals, and a healthy dose of independent thinking. The last one is the hard part, at least for me. No, really. It's so very easy to fall into the trap of just thinking about how other people do it that you stop thinking about it yourself as you suddenly start thinking that your own solutions will inevitably be inferior. But if you look at production-quality game code, which you can since numerous commercial games have had their source code released, you will probably run away in horror. It's usually not pretty - people get paid for working systems, not for pretty architecture.  MVC is good to try as mentioned already. More generally, there is the software architecture approach of top-down and bottom-up design, although in practice you usually do a bit of both at the same time. With Java, you can try the following as a very general guideline: separate the systems into different packages and try to keep the dependencies between packages low. Have your lower level systems (graphics, for instance) be completely independent of your higher level systems (scene management, game logic), and instead have your higher level systems use those lower level systems. Get some tool that shows you a dependency graph between your packages (if you're using Eclipse, the metrics plugin will show you the package tangle).What you described is, in general, how it usually works in games. You set up all your systems, then you start the game loop, where you update, draw, update, draw, update, draw, until the user asks to exit or the game crashes... it can get a bit more complicated if you want to decouple some of the update stuff to run at a fixed framerate, but that's the basics.   ;  This is roughly how I'm modulizing my current project: clicky.Azimuth is the math library.  Lodestone is my physics engine.  Sunweaver is a DNA module (the program is an artificial life simulator).The idea is to organize it the same way you would organize classes.  Some modules are "interface" modules which abstract away the specifics of certain sub systems.  Some subsystems rely on more basic subsystems (graphics and physics both use matrices and vectors, so they both rely on the math module).All that said, be sure you want/need to modularize your design.  It's a lot of up front work designed to make your design flexible in the future and easier to maintain.  For lots of projects (games especially), maintaining code in the future is a non issue, and you're copying most of the gameplay elements from existing games, so there's less risk of changing things in the future and so you can get away with being less flexible.   ;Quote:Original post by NumsgilAll that said, be sure you want/need to modularize your design.  It's a lot of up front work designed to make your design flexible in the future and easier to maintain.  For lots of projects (games especially), maintaining code in the future is a non issue, and you're copying most of the gameplay elements from existing games, so there's less risk of changing things in the future and so you can get away with being less flexible.This is something that I've thought a lot about and had a lot of problems with. I'm writing a rather large single-player 2d RPG using C++ and Allegro. I've divided the code into several subsystems, and I'm not using any globals. But this brings a lot of problems and a lot of extra work, and I'm constantly wondering if it really is worth it. The main issues are managing the dependencies between the subsystems and synchronizing them (for example, every subsystem which needs access to the current game map must have a pointer to it, and naturally, they must all have pointers to the same map, thus causing the need to synchronize everything when the level changes) and passing data around between subsystems.A while ago I looked at the source code of the Omega roguelike. It doesn't use OO, and everything is global. I must say I was really amazed by the simplicity of it all. No need to make sure I have a pointer to the graphics subsystem if I want to draw something. Just call draw() from where ever you are. No need to synchronize. No need to worry about circular dependencies between subsystems and the (sometimes very subtle and hard to fix) problems they cause. No need to spend hours thinking about class organization. No need to think about passing data around between subsystems.Does anyone else feel the same?   ;  @formalproof:Yes, sometimes I feel that breaking some of the principles will gain you more than staying with them at all cost. I guess it's about priorities. If performance will suffer and the design will just increase complexity then the 'best' solution could be one which abandons the common guidelines.   ;  I cannot say it amazes me, as it does you, but perhaps I guess I can see why the simplicity might amaze you: perhaps you started programming post 00 era(i.e. after 00 became the mainstream software method); I started with C before OO became so. Yeah, so... these days... the simplicity you speak of is like a breath of fresh air, tinged with a bit of nostalgia. You don't really need classes do you: especially if you are building something by yourself that is 'relatively' simple; with no plans for reuse of some bits/components elsewhere sometime later? RE: your "No need to do this, No need to that" and your 'No need to do other etceteras'. It can sound pretty tedious aswell can it not?I recall, many moons ago, OO was promoted to the mainstream as a solution to manage the anticpated growth in the size and complexity of software. These days, the complexity may well be managed or should that read "managed well?" (e.g. via levels of abstraction, etc)...but the complexity remains(as your 'no need to...' examples attest?). As with any era, in any discipline, some of us are misguided into thinking of the present day era as the most advanced yet, while other previous eras may well be viewed as archaic. e.g. What planet do you think I would come from, if I claimed to be a software developer but didn't know what OO refers to? Planet Earth?Anyhow, thanks for the fleeting feeling of nostalgia (have we just hijacked this thread)   ;Quote:Original post by formalproofA while ago I looked at the source code of the Omega roguelike. It doesn't use OO, and everything is global. I must say I was really amazed by the simplicity of it all. No need to make sure I have a pointer to the graphics subsystem if I want to draw something. Just call draw() from where ever you are. No need to synchronize. No need to worry about circular dependencies between subsystems and the (sometimes very subtle and hard to fix) problems they cause. No need to spend hours thinking about class organization. No need to think about passing data around between subsystems.Does anyone else feel the same?Sometimes there's indeed way too much scaffolding. There's no need to make things more complex than they need to be, just because we can...However, if everything is global... the dependencies are still there, they're just not as obvious. It takes a lot of discipline to keep such a project from becoming a tangled mess. At least passing around pointers too much tells you that you're adding too much dependencies. I wouldn't say 'thinking about class (code) organization' is a waste of time. It's often beneficial to spend some time up-front thinking about how to organize your code, whether you're using classes for that or not.   