Sign in to follow this  

Game Design Basics

This topic is 3595 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

A few years ago, I tried to get into games programming, but failed. I fell short on some of the techniques and my understanding of my languages and object orientation was flawed at best. I've been working in C# for the past few years, and due to circumstance I am unable to work at the moment, and figured it would be a good idea to get back to this site and try learning some more. I've been reading the last few days, trying to follow tutorials, trying to figure out how everyone else goes at this and just can't quite grasp it. So I figure now is the time to ask my questions in the hope that I don't immediately get pointed to Google or the search function. 1) Game States - I can see several 'tutorials' on Game States, and I understand that the idea is that each part of the game is represented by a state, and the states transition between one another. What I can't seem to grasp is; a) Do I basically create a loop in each state, manage drawing to the screen, catching input etc. b) What (in your opinion) is the best way to manage states and transition between states. 2) Object interaction / update / events - This might be an unnecessary sticking point, but how do I communicate between objects, are there any design documents around giving me an idea of how to structure a game? I don't have any grand game plans, I'm not thinking, "oo.. I'll write the next SimCity", I'm going to start with Console and move my way up through a gfx api. Like I say, I have searched Google for GameState tutorials etc, I've looked for design documents. I just think I need to ask my questions to understand for me. I've read the stuff I've found, and I've tried to find simple game source to look at, but didn't find anything I followed. Any help appreciated

Share this post


Link to post
Share on other sites
States:

Well the whole mechanism is pretty straight forward. You have one game loop. What you can then include within that game loop is conditions for the game state, it is no different from creating a variable called 'game_state' and saying 1 means main menu, 2 means play state, 3 means highscore state. It just allows you to keep moving without breaking your game loop.

The way you handle these doesn't really matter as long as it works. You could of course enhance the general mechanism in different ways. For example, if you are into object oriented design, you would create a base state class and then inherit that base to create different states. Using polymorphism, you would then call a single state method, but depending on which state is active, the reaction would be different.

Hope that helps.

Edit: I should also point out that states are great tools in other aspects of a game's creation, such as the ability to change the a.i. state of your game character.

---

Object communication:

Each object would just contain methods and functions that handle 'messages' and requests being passed on to it. For example 'character' and 'car' could communicate by calling: car->openDoor(thePlayer);

This way, the openDoor() method could infact query the object for additional information like:

charId = argPlayer->getId();
if(charId != owner)
thePlayer.warn("This vehicle does not belong to you!", this);

Share this post


Link to post
Share on other sites
I prefer to use the stack. Basically, have several procedures/objects (depending on design style) each of which is a game loop e.g. menu,option,game and then when you want to transition to a state call the main loop of that state. This is useful for hierarchical layouts, so start in main menu, go to options, when options is quit it will return to the last state you were as the function ends and you'll be back to the main menu, or if you called options from the pause menu it'll go back there with no work from you.

Share this post


Link to post
Share on other sites
It sounds like you're complicating matters before you've even started properly. You probably shouldn't worry about 'game states' for now. Just build a simple game. Hangman or such, or tetris, or whatever is doable for you right now. Then gradually work your way up. Just as with normal software, there's usually no One True Solution. You think up on something, implement it and work with it if it does the job, or rework it if it turns out to be seriously flawed. That's how you learn.

Anyway, building a game loop into every state sounds like duplicating functionality, which is a bad idea. As for object communication, that highly depends on the game you're working on. What exactly did you have in mind? Also, what do you see as different 'game states'?

Share this post


Link to post
Share on other sites

This topic is 3595 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