Sign in to follow this  

Object Oriented Game Design

This topic is 4242 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, I was talking about making a megaman type game, but i've never dealt with a game that encompasses so many different things, NQ gave me this great post: To me, it sounds as if you'd be able to do something like Megaman. Maybe you don't make it perfect, maybe you don't finish it, but if you're looking for a good learning project then this is probably a good choise. You'll certainly learn alot in a short amount of time! In a brief estimation, ontop of what you already know, I believe you need to learn the following: 1. Basic collision checking 2. Basic physics 3. Basic AI 4. Tile-based scrollable game-map knowledge 5. Sprite animation handling 6. Joystick/gamepad handling (optional) 7. How to make a level-editor (optional) 8. Object/particle-ish system Here's how I suggest you go about them: 1. As others have suggested, check out that bounding box tutorial. 2. For the very basic physics (they're easy - I promise! ) go browse through the articles here on gamedev, under the category Math & Physics. I think you will find this one especially helpful. 3. For AI, I suggest you drive all enemies using an approach called 'Finite State Machine'. This is much simpler than it sounds, and for a VERY brief idea of what this is like - read this forum entry. 4. Hmm... I've used tiles on countless projects, but I can't seem to find a decent introduction tutorial into this area... But basically your map is made up of a large grid of values, where different values mean different images (tiles). You'll have to take into consideration where the 'camera' is over the map, to decide which part of the map to display on the screen. Maybe I should make a tutorial about this... 5. There are plugins you can add to SDL which are ready-to-use, but I think you want to learn, so I suggest you build the animation system yourself. I think it would be quite rewarding. Basically you put all the images in the animation on a surface, next to eachother. To display the different images, you blit only a cropped portion of this animation-chart onto the screen. In every frame, you calculate which image should be drawn, by doing some simple math. (i.e. 455 of 1000 milliseconds have passed >> draw image number 3 of 6) You could have one textfile for each animation, where you specify how quickly it should be animated. First you tune the in-game speed of the object until it moves with a nice speed, then you tune the speed of the animation so they match. 6. SDL provides easy input from joystick/gamepad. You'll have this implemented in a day, by just following the included documentation. 7. Making a level editor would also be a rewarding experience, but you can skip this if you don't want to. You can use Notepad as your level editor, writing long strings of numbers in a grid. You can also use a paint-program to draw a image. Different colors represent different tiles. You can also download and use any of the free tile-map-editors which you can find online. They save their output as a special file-format, so you'd have to program a function to read the info stored in the file. 8. I hope you have learnt how to use the ++ in C++!! By spending a decent amount of time on planning and writing diagrams, prior to programming, you can save yourself lots of working hours later. I recommend trying to use an object-based approach, and thus make your game engine really expandable. Scetch things down on paper first, or in Word if you type faster than you write. Always assume that will will want to add things later, which you have not yet thought about. Plan ahead, to make such additions easier to do in the future. For example, such a procedure could give you a result like this: "Aha! Instead of checking if the player collides with a bullet, then if player collides with an enemy... blah blah blah... and then if enemy collides with bullet, if enemy collides with map... blah blah blah.... I could just make it 'if OBJECT collides with OBJECT' and it will be much less complex!" Hope I provided some information of value. Good luck!! ---------------------- ~NQ - semi-pro artist @ NordquistArt.com Sprites and tilesets available for FREE download on my website! My question to you guys(or NQ) is how to setup my internal game design/game engine. He showed me the majority of the elements that I will need to involve in it, but I would like to know what I need to make seperate classes for, and what do I include within my main code. (i'm taking notes on all of this and drawing it all out before I start coding anything) and I'd just like to know what is a good way to set up a larger project like this and whats the best way to seperate the classes and such, Thank you all so much for anything you can help me with, -Synt4x

Share this post


Link to post
Share on other sites
In my last project, the center of the design was the IGameState class. Each "screen" was a subclass of IGameState. For instance, CGameStateMenu, CGameStateAction, CGameStatePause. One might use it a-like so:

std::vector<IGameState> activeStates;
CTimer timer;

while(eventMsg != SDL_QUIT)
{
//get event messages, get input, etc.

timer.SetDeltaTime();
for(int i=0; i < activeStates.length(); ++i)
{
activeStates[i]->Update(timer.GetDeltaTime);
}

//draw routines
}



Each of those subclassed gamestates would have its own logic for updating, and for interpreting input. Polymorphism made my previous WINAPI-style switches obsolete!

Share this post


Link to post
Share on other sites
Synt4x,

I am currently designing and implementing a 2D game engine for my RPG. Check out the following resources:


a set of questions I placed to the community and the ensuing discussion

Game Engine Design Questions


This series of articles by Richard Fine that use C++ and SDL to create a game engine

Enginuity, Part I
Enginuity, Part II
Enginuity, Part III
Enginuity, Part IV
Enginuity, Part V


My journal is a record of my thoughts as i'm designing my engine (which is based off the Enginuity series but uses DirectX instead of SDL)

GameDev Journal


The Enginuity series listed above contains a nice looking flow chart but I will include mine here so you can see what mine looks like:

My Flow Chart


If you need any help with the design process, your more than welcome to private message me or to comment on my journal and I'll answer any questions you have. Of course, the above resources are not the only ones on this site. I really suggest reading more articles from the Articles section and reading some other GDNet Journals.


I hope I have been of help,

Share this post


Link to post
Share on other sites

This topic is 4242 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this