Sign in to follow this  
space warp

Programming games using scene-classes

Recommended Posts

space warp    122
I'm not sure this is where I should post this but I think it's the best choice... Anyway, I was thinking of making a tutorial/article (I tend to mix it) on game programming and I was wondering how many of you would be interested in a tutorial covering "Windows/OpenGL game programming using scene-classes". By this I mean how to separate all the little parts of the game (splash screen, menu, actual game, result screen, etc.) and turning them into seperate classes that can be used by the central WinMain function. This is a very tidy and effective way to keep different parts of the game separated and organized. So, what do you think? Is it a good idea? PS I'm going to bed now (I live in Sweden), but I'll answer any post when I get back.

Share this post


Link to post
Share on other sites
Endar    668
You're talking about a set of game states and having a game state manager of sorts run and update everything?

Yes, I used the same format for the demo I just made, and that made things much easier because I didn't end up having dependencies between completely unrelated classes like, a class that ran a level, and one that displayed and managed a menu. I used to have stupid dependencies between things like this.

Share this post


Link to post
Share on other sites
Feralrath    163
it seems to me that that would only serve to make more code to write. personly i use a single class to handle the game state. i keep it tidy and havent had any problems with my state manager class yet.

Share this post


Link to post
Share on other sites
space warp    122
Well I suppose it depends on who you're talking with. But if people usualy use state managers then maybe I ought to write the tutorial just to show another way to do it and then people can choose for themselves.

Share this post


Link to post
Share on other sites
jpetrie    13159
I think that tutorials are terrible abominations, and tutorials written by people who are not experts or masters in the particular problem domain are even worse. Then there's the fact that most tutorial authors aren't necessarily all that great at communication to begin with, except in code, so all that tutorials end up being is code dumps, which aren't helpful.

Now, all of the above may or may not apply to you at all -- I don't know you; but statistically speaking its likely that you fall somewhere in the category of "not quite experienced enough to write a tutorial," but who knows. I won't assume.

That's less of an issue, however, than the fact that I don't think the concept you're trying to impart is particularly useful. It sounds like you're advocating the construction of large, monolithic hard-coded classes (one for each "state"), possibly with a lot of duplicate functionality, which is brittle, hard to maintain, and doesn't scale well. It might be ideal for quick, small games, but it really isn't a scalable system, especially the way you describe how transitions might work.

Basically, you seem to be advocating a state machine that is hard-coded and monolithic, versus a state machine that is designed to be generic and reusable. Have I misunderstood you? I don't see any advantage to your suggestion as I currently understand it and think that a tutorial on the subject would only serve to increase the spread of bad or misinformation.

Share this post


Link to post
Share on other sites
space warp    122
First of all, I do NEVER make code-dumps. I said in the first post that I tend to mix tutorial and article writing and I also NEVER make rigid code (sometimes I make code general way beyond what is neccesary but that's another problem).

Second, you have misunderstood. I do not "advocate" a state machine at all. An example of the technique could be a menu. Say there is a MAIN_MENU object that displays the main menu to the user. It has its own program loop and its own message handler. WinMain calls that program loop. The user goes through the displayed menu and presses ENTER. The MAIN_MENU object recieves that message and calls the program loop of a CHILD_MENU object which displays it's contents using it's own draw function. When the user is done with the submenu he/she can select "Back" in order to go back to the main menu. When the CHILD_MENU gets this message it simple exits its program loop and the program has suddenly returned to the main menu.

It looks quite messy when writing it I'll give you that, but it's actually not that much coding. It's really easy to make a general class that can handle anything.

Share this post


Link to post
Share on other sites
jpetrie    13159
Quote:

I do not "advocate" a state machine at all. An example of the technique could be a menu. Say there is a MAIN_MENU object that displays the main menu to the user. It has its own program loop and its own message handler. WinMain calls that program loop. The user goes through the displayed menu and presses ENTER. The MAIN_MENU object recieves that message and calls the program loop of a CHILD_MENU object which displays it's contents using it's own draw function. When the user is done with the submenu he/she can select "Back" in order to go back to the main menu. When the CHILD_MENU gets this message it simple exits its program loop and the program has suddenly returned to the main menu.

That is a state machine. It is very nearly the textbook example of a state machine.

That kind of high level overview isn't enough to dissuade me from thinking that the concept still seems brittle -- consider drawing, for example, which is a decently well-structured medium-to-large scale product will be the exact same process regardless of current state, with only minor variations. You seem to imply that each state object will duplicate the render loop. This is wasteful except in the rare instances where your rendering functionality is completely different from state-to-state. There's just a lot of implementation details that you're not covering here that, based on what you've written and how you've written it, could be implemented in extremely poor ways.

Perhaps you should construct a first draft of this article, which would help us get a better handle on what you are going for.

Share this post


Link to post
Share on other sites
space warp    122
Quote:
Original post by jpetrie
That is a state machine. It is very nearly the textbook example of a state machine.


Really? I though state machines where when you had a enum or similar structure to describe the game state and then a ... don't know what to call it ... "router-function" decides what functions to call based on the game state and I'm definetly not doing that. I'm not sure what you mean about the render loop, because there's only one loop actively running no matter how I do it.

And I think you are correct about me making a draft.

[EDIT]
I've gone through the menu-idea and found that I only need one single menu class to handle everything. Not rigid.

[Edited by - space warp on March 21, 2007 3:47:36 PM]

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by space warp
Really? I though state machines where when you had a enum or similar structure to describe the game state and then a ... don't know what to call it ... "router-function" decides what functions to call based on the game state and I'm definetly not doing that.
No, that's simply one of many idioms used to implement a state machine.

Share this post


Link to post
Share on other sites
space warp    122
Quote:
Original post by Sneftel
Quote:
Original post by space warp
Really? I though state machines where when you had a enum or similar structure to describe the game state and then a ... don't know what to call it ... "router-function" decides what functions to call based on the game state and I'm definetly not doing that.
No, that's simply one of many idioms used to implement a state machine.


Okay. Then it might be a state machine. But I'm still not calling it rigid.

I love programming discussions :)

Share this post


Link to post
Share on other sites
Sneftel    1788
Um, all right. (Has anyone besides you used the word "rigid" in this thread? Does anybody besides you know what you mean by it?)

Share this post


Link to post
Share on other sites
space warp    122
Quote:
Original post by jpetrie
Basically, you seem to be advocating a state machine that is hard-coded and monolithic, versus a state machine that is designed to be generic and reusable. Have I misunderstood you? I don't see any advantage to your suggestion as I currently understand it and think that a tutorial on the subject would only serve to increase the spread of bad or misinformation.


Not the word no, but I figured that's what jpetrie meant.
Sorry if I'm wrong.

Share this post


Link to post
Share on other sites
space warp    122
Thought: Even if this technique is a state machine then I can still make a tutorial/article on it. I still don't think it's an overly complicated way to do things and I really like writing so is anyone still interested in it?

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by space warp
Thought: Even if this technique is a state machine then I can still make a tutorial/article on it. I still don't think it's an overly complicated way to do things and I really like writing so is anyone still interested in it?

Err...... not really. Please don't take this badly, but based on the quality of your explanations here you don't seem to be in a position to write good, clear tutorials which elucidate rather than obscure knowledge. You don't have a good handle on the domain-specific vocabulary or descriptions of software design. Remember, it takes a great deal more expertise (and other things) to teach something than it does to use something, and while you seem to have no problem with the latter I doubt you're ready for the former. Sorry. (I really am. Don't worry, though; you'll get there.)

Share this post


Link to post
Share on other sites
space warp    122
Quote:
Original post by Sneftel
Quote:
Original post by space warp
Thought: Even if this technique is a state machine then I can still make a tutorial/article on it. I still don't think it's an overly complicated way to do things and I really like writing so is anyone still interested in it?

Err...... not really. Please don't take this badly, but based on the quality of your explanations here you don't seem to be in a position to write good, clear tutorials which elucidate rather than obscure knowledge. You don't have a good handle on the domain-specific vocabulary or descriptions of software design. Remember, it takes a great deal more expertise (and other things) to teach something than it does to use something, and while you seem to have no problem with the latter I doubt you're ready for the former. Sorry. (I really am. Don't worry, though; you'll get there.)


I don't take it badly, it fits my own oppinion quite well. I've never been good at explaining things quickly, expert or no expert (but I am from Sweden so there's your language problem). It's just that I think it would be really good if someone wrote a tutorial or article that shows at least one way to organize scenes in games. When I started programming OpenGL I couldn't find any good explanations on the subject, so I had to figure things out on my own (which in the beginning wasn't a good thing really).

Share this post


Link to post
Share on other sites

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