OO Game Design ...
BlitzMax Forums/BlitzMax Programming/OO Game Design ...
| ||
| Hi just a general query/brainstorem on how to Design a game system, in effect once you start down the road of a game framework what way do you partition your design. For example a simple Sprite/Game Object type that deals with drawing, logic, triggers sound, interactions, AI, collision detection ect... Or seperate objects/systems for disparate areas e.g. Graphical, AI/Logic, Collision ect... In effect not all game objects may be 'visible' at one time or at all, although their impact may be e.g. Gravity/ Wind/ Event Timers/ Offscreen objects. Or even more abstract Events/Logic Model/View/Controller |
| ||
| I think most people separate stuff out into whatever seems to be a logical natural boundary between areas of the system. Sometimes you have to think about efficiency - it's still a general fact that e.g. using arrays of object data in parallel is faster for various reasons than lots of separate objects. But putting stuff all in one place is also not so great for clarity, it creates hardcoded dependencies, and it's not so easy to modify one part without other parts breaking. If it makes sense to have a `sprite` type that would be great, but I don't think I'd want to put all the logic and drawing stuff in with it. I prefer to have graphics stuff separate from logic stuff and would aim more towards a general particle system which includes sprites and ai. |
| ||
| I think a lot of your design is personal preference but I can give you an example of the method (pun intended) I use. The basic engine consists of using types I call cores. Each core manages a different aspect of the program, and a core can have sub cores as well. The main core manages all the other game cores. Generally speaking the main core's methods are the only ones called outside of another type. Some of the other cores I use include: Zone Core: The zone core manages game levels, which I refer to as zones. Every zone is stored in this core and multiple zones can run at once if needed. Zones: Zones use fixed rate logic to update the actors contained in them. Each zone has its own logic rate properties so different zones can run at different speeds. Display Core: The display core controls the drawing of images. It is attached to one zone at a time and the calls the drawing methods for actors in that zone. Zone logic updates are rather slow (about 20 times a second) so the display also calculates tweening to make the graphics smooth. Resource Core: It manages data loading. It usually has sub cores for graphics, sound, and saved games. Effects Core: Controls particles, sound effects, and music with sub-cores. Bodies: Bodies control physics interactions. Each body is a primitive such as a circle or a polygon. Some body properties include mass, position, velocity, and facing. Bodies use methods for collision detection and physics calculations. Actors: Each actor has an attached body for zone positioning and physics, but actors manage manage most other stuff such as what image to use, ammo, health, etc. An important part of OOP is making types self contained. To help with this I use methods for all type interactions. For example, to calculate tweening the display core doesn't directly access zone variables like this: TweenBase = DrawZone.LogicRate.StepSize Instead a method is called from the zone like this: TweenBase = DrawZone.LogicRateGet() If I mess around with the variables and calculations in a zone the input and output methods stay the same. The display core isn't affected. Also be sure to make this methods specific. I usually title a method so the type of data and processing is explained first, and the data passing is explained second. For example: Body.PositionCordsSet(X, Y) Body.PositionVectorAdd(Body.Velocity) Some other cores you might want to consider are user input and AI. Finally, one of the beauties of OO design is that implanting threading becomes much easier! Cores can run in different threads and use some kind of message system to pass data around. That's just how I do things. Experiment to find what structure makes the most sense to you. Whew! That's a lot. I hope the info helps. Good luck with your design. |
| ||
| Cheers ImaginaryHuman and lukehedman I think I'm going to have to keep with my core development principle K.I.S.S - Keep it Simple Stupid! and see what evolves. Regards Merx. |
| ||
| to be honest I mostly use procedural programming with blitzmax |
| ||
| Now this is an intresting topic So let's see... this would be how I structure my game logic: TApp - Handles the application and it's state. Has a game object in it and various features such as resoultion depth, fullscreen etc. Also has a resource manager TObject - Handles the overall game. It includes a scene. TScene - this is a base class. I have various types derived from it depending on what it need. Most important are the classes that are menu (the first screen you see when entering a game for instance) and the gamelevels. If the derived is a gamelevel then it contains data about the level and everything there. Then I have the objects you interact with. Usually I have the draw method and the update method. I guess it's clear about what they do. furthermore it just depends on what the game is. |
| ||
| Does anyone has experience with [a http://en.wikipedia.org/wiki/Model–view–controller]Model-View-Controller[/a] design pattern? It sounds promising. |
| ||
| @Kistjes - I've come across it it's very abstract and means that your game code has to be divided up into three areas: View - Drawing code, sound(?) Model - Abstract game objects and their states Controller - events and AI user interaction, timers. It tends to be best used when you can have multiple views of the model, e.g. Spreadsheet, Chart, Graph, Hud, Scene I'm not convinced that it would work that well in games, well the simpler ones I do anyway. As it just means you have three code/object streams to update to add a single item to your game!? |
| ||
| I use this pattern in my day-time job. We use Ruby on Rails and the Rails framework is split into model, view and controller. The main aim is to put all the logic into the models. The controller acts as a messenger between the model and the view. I think this could work well in a games environment and is something that I am keen to try myself. Agile Games Development too :) |
   |