Game State

quote:

---

Original post by Shadow Mint
I''d quite like to see an article or a series of articles describing the representation of objects for a game.

---

Objects in a game are just data. If you don''t understand how to enumerate to yourself th eproperty of your data collections and model those in code, you''re not a decent programmer (derive from that what you will).

If you were modeling a vector, what would you write? In 3d, you''d perhaps have x-, y- and z-axis magnitudes, assuming you were working with cartesian coordinates. If you wished to model a physical particle, you might have variables representing mass (scalar), acceleration (vector) and velocity (vector) to simulate linear motion. You could add angular acceleration and velocity if you found that useful as well.

Okay, a tank in an RTS game. What does a tank have? How important are those parts to the gameplay? Tanks have turrets, the turrets swivel and rise/fall independently of the body, but being fixed to the body "inherit" any movement by the tank as a whole. A tank has a fixed supply of missiles (or energy if your tanks have laser cannons). Perhaps you might wish to simulate independent tractional anchors for your tank''s movement, or perhaps not if the level of detail isn''t that high.

How do objects respond on their own? Autonomous agents - essentially objects that are self-aware (keep all state variables internal) and self-updating (generally, your game world calls their "respond" method regularly, allowing them to react to any changes of their internal state; the game world also informs them via method calls of external events that would cause changes to this internal state, such as a missile hitting a silo changing its state from "in flight" to "detonating").

quote:

---

I still feel the topic is not well covered and needs articles on it.

---

Read a book. Both Tricks of the Windows Game Programming Gurus and its predecessors (Teach Yourself Game Programming in 21 Days, etc, from which virtually of its text was lifted) cover these topics. Buy, borrow, steal... just read.

Thank you for so clearly responding to my post. Despite what you've said, I strongly believe there is significantly more complexity to the issue than the simplification you've presented.

If you think data modelling is a trivial job, I suggest you do some searches/talking around. I dont know in general, but just locally I know a few very well paid people in companies who do nothing but data modelling. Its not, as I've said, a well covered issue. You can probably do a straight CS degree and never hear data modelling in some places.

Most people gloss over it, and focus on other technical aspects, like I said.

Its not a matter of, how do I do this? Like you said, THAT is a trivial matter for somebody to work out (usually). What the question should be is how do i do this -well- and -elegantly- for state models which are sufficiently complex that simply -deciding on a solution- will be an utter disaster.

I'm going to stop short of saying I'm personally offended by your reply; because I'm sure it wasnt intended as such, so I'm not going to view it so. However, if I suggest an article, and your response is basically: That's trivial, read it in a -book-. My question is this:

Whats the point in writing any of these articles, since they're all covered in books?

I would suggest an answer of something along the lines of: Obviously not everyone has access to all the books that are relevant. These articles are here to supplement the knowledge of people studying specific topics, and impart knowledge (even if only a simple understanding of) topics which they are not familiar, or do not have access to resources with which to make themselves familar.

Would you agree? If so, then why is this a bad topic for an article?

But anyway! I rest my case. The point is, I can't find any good online tutorials on the topic, which means that at least in my oppinion its obviously one that should at least be considered for writing an article. Thats all. =)



[edited by - Shadow Mint on June 13, 2002 7:40:36 AM]

I''ll clarify the nature of my response before addressing further issues you''ve raised:

quote:

---

Original post by Shadow Mint
I''m going to stop short of saying I''m personally offended by your reply; because I''m sure it wasnt intended as such, so I''m not going to view it so. However, if I suggest an article, and your response is basically: That''s trivial, read it in a -book-. My question is this:

Whats the point in writing any of these articles, since they''re all covered in books?

---

Books show you what, often in more formal fashion (some too formal; David Eberly''s 3D Game Engine Design is a bore to read). Articles try to be more casual, and target more of niche topics. I despise tutorials.

I''m fairly curt because I feel that the effort of indivudal discovery often yields side benefits that are lost when the answer is merely "given" (which is why I despise tutorials). My own article here on GameDev is fairly short on code, only presenting the portions I feel are absolutely non-intuitive. It''s never personal.

quote:

---

Thank you for so clearly responding to my post. Despite what you''ve said, I strongly believe there is significantly more complexity to the issue than the simplification you''ve presented.

If you think data modelling is a trivial job, I suggest you do some searches/talking around. I dont know in general, but just locally I know a few very well paid people in companies who do nothing but data modelling. Its not, as I''ve said, a well covered issue. You can probably do a straight CS degree and never hear data modelling in some places.

---

Quite true, but this is merely indicative of the poor level of CS, and particularly programming, instruction today. It is widely accepted that C++ is badly taught at virtually every school in the US, and probably elsewhere, too.

The key to good data modeling is thought - design. Prior to writing any code, one must completely plan all the interactions of system components - what data they require from and provide to each other, what functionality they need to expose and whom to expose it to. These are fundamental principles of good software design. Once this has been clearly thought out (in recursive fashio through the subsystems until the design description is virtually code), the implementation proceeds logically from there.

If you so wish, we could run a little example right here on this thread (inappropriate forum, though; I might move it if we do, or recommend starting a new thread): Post a game idea (not too expansive, but not an "evident" design like pong - a small RTS or tank game might be a good choice) and we''ll go through the design phase together. By the time we''re done, I guarantee you that you''ll be able to model the data easily and accurately, and perhaps might even consider writing that article yourself!

I do commend your extremely professional response and wording. It''s quite rare these days to find such an erudite discussion of nearly colloquial matters - even in person. I look forward to your reply.

*raises eyebrows* Ok then, lets see...

quote:

---

Original post by Oluseyi
I'm fairly curt because I feel that the effort of indivudal discovery often yields side benefits that are lost when the answer is merely "given" (which is why I despise tutorials). My own article here on GameDev is fairly short on code, only presenting the portions I feel are absolutely non-intuitive. It's never personal.

---

That's certainly a fair outlook. As I said, I wasn't offended by what you said; I simply disagreed. I agree to an extent about what you say regarding tutorials; but we could probably sit around all day arguing finer points of this issue.

In my thoughts at least, there is a place for tutorials; it’s simply a matter of extents. Providing someone with a solution they can simply copy and paste it into a dozen different solutions achieves nothing. On the other hand, making such a solution not available can hinder someone who wants to use it.

You can liken this to maths in many ways. Much of early maths is based on doing things that there are trivial techniques to do (like differential eqns) in difficult and historically relevant methods. The idea is to teach the students how to think, and how to do maths, rather than just plug a solution that someone else has come up with into the equation.

However, for mathematicians to do real and significant work, they invariably need the more powerful techniques that will allow them to achieve their goals/do their research. The point is that if the advanced techniques were not made available to them, they would have to reinvent the wheel (cliché, I know, sorry) every time they did anything.

I feel the same way about tutorials. It’s difficult, because there is nothing to stop the student simply using the advanced technique and have no understanding. By not making the tutorial available though, someone who is trying to do real work (programmer equivalent of the mathematician) may be frustrated and hindered.

I do agree about your note regarding niche applications. Articles that simply cover topics directly found in other places are not particularly useful. A multitude of articles on a single topic is much less useful than a few articles on topics that get little attention other wise.

It’s an interesting issue, but I digress. As I recall I was going to talk about something completely different...

(nb. I hardly claim to be the programmer equivalent of a mathematician as in my example. I'm simply speaking in general terms)

quote:

---

The key to good data modeling is thought - design. Prior to writing any code, one must completely plan all the interactions of system components - what data they require from and provide to each other, what functionality they need to expose and whom to expose it to. These are fundamental principles of good software design. Once this has been clearly thought out (in recursive fashio through the subsystems until the design description is virtually code), the implementation proceeds logically from there.

---

Yes, I completely agree. Wouldn't you agree though, that attacking the state logic will have a significant effect on the design?

If the logic of the system dictates for example, 3D collision detection happens in the state module, which is a central repository for all general state information. Which means the mesh for the module is stored there. Which means the mesh for rendering is not in 3D engine; introducing overheads (which lets just say in this case) introduce massive performance hits which are not considered until the implementation stage.

Have you read the book: Game Programming Gems (I forget the author/editor; Mark ...blah. Dilope or something)? It has a bunch of useful articles; some of which are directly on this topic. For example the article on having templated units and unit types; I found that facinating. It simply never occured to me, but its a really good idea.

I feel that there should be more articles like -that-. Less basis on providing a solution; more on providing design patterns with full documentation, and possibly a small example of use as applicable to game logic and game state representation.

As with any design pattern they would have to say; this pattern is useful in these circumstances, and not in these. Never ever ever ever use it here. Heck, you could even get game antipatterns. That would be really great (I guess antipattern is more like my example above; dont do this! Or whatever).

quote:

---

If you so wish, we could run a little example right here on this thread (inappropriate forum, though; I might move it if we do, or recommend starting a new thread): Post a game idea (not too expansive, but not an "evident" design like pong - a small RTS or tank game might be a good choice) and we'll go through the design phase together. By the time we're done, I guarantee you that you'll be able to model the data easily and accurately, and perhaps might even consider writing that article yourself!

---

Hmm...definately an interesting idea. I doubt I'm qualified (or will be for a long time) to write any such article, but an excersise in building a state model sounds quite interesting. If nothing else it could serve as a basis for writing an article about not over looking the important of data modelling in game design...

Seem fair. I'm going to spend about the next 5 weeks doing VB programming (=P Its a job, no?), so the interludes of something interesting to think about would certainly be welcome.

heh. Yes, this is not quite the appropriate forum for it. Any suggestion for where to start the thread? I'm thinking either "Game Programming" or "Game Design" not sure which; the latter seems more appropriate by name...but not by typical content (on the other hand at least that forum does cover state stuff every now and then).

Looking forward to it.

(Edit - Lol! Long article. Fixed the obvious mistakes I found on reading through it. Sorry if I left any. =)

[edited by - Shadow Mint on June 13, 2002 10:51:20 PM]

quote:

---

Original post by Shadow Mint
In my thoughts at least, there is a place for tutorials; it’s simply a matter of extents. Providing someone with a solution they can simply copy and paste it into a dozen different solutions achieves nothing. On the other hand, making such a solution not available can hinder someone who wants to use it.

---

It''s largely a function of temperament, aptitude and personality. Some people only need to clearly grasp the principle (me) and as such tend to relate towards others in similar fashion. Others need for the material to be driven into them with repeated explanation and examples. Both are equally valid, I guess. I just have my preference.

As for math, it''s taught that way to accomodate the wide variety of students, given that basic math skills are something that every person requires. I guarantee you that masters-level math is not taught so.

quote:

---

Yes, I completely agree. Wouldn''t you agree though, that attacking the state logic will have a significant effect on the design?

---

A state-based design that doesn''t include state logic and transitions is incomplete. Which proves my point about incomplete design leading to implementation flaws.

(I had written out a much longer and more cordial reply initially, but this blasted machine choked and had to be rebooted. I really need to return to my own place; this "holiday" is proving much more unpleasant by the day).

quote:

---

If the logic of the system dictates for example, 3D collision detection happens in the state module, which is a central repository for all general state information. Which means the mesh for the module is stored there. Which means the mesh for rendering is not in 3D engine; introducing overheads (which lets just say in this case) introduce massive performance hits which are not considered until the implementation stage.

---

Again, faulty design. A key philosophy of good object-oriented systems is to simplify/clarify ownership relationships and responsibilities in code (largely the reason for the existence of singletons). Meshes should belong to a resource manager, which is queried for all available meshes by the renderer/graphics engine. The logic subsystem would query the resource engine for object properties necessary to maintain an accurate game simulation, and so forth.

I haven''t read Game Programming Gems, but I''ll look for it. I also like the idea that we should develop design patterns in the areas of data modeling and simulations - generally applicable but particularly useful for games.

quote:

---

Hmm...definately an interesting idea. I doubt I''m qualified (or will be for a long time) to write any such article, but an excersise in building a state model sounds quite interesting. If nothing else it could serve as a basis for writing an article about not over looking the important of data modelling in game design...

---

Very well then. I''d recommend the Game Programming forum over Game Design, because desin patterns are a code design issue more than a creative design issue and the target audience is more programming-oriented, something we''re more likely to find in Game Programming. Start the thread and email me (it''s in my profile) and I''ll be sure to chime in.

"...take a real time 3D strategy game. How do you represent units? How do you represent corpses, missiles, weapons? How do you do that cool thing where you can select a chassy and put various different weapons on it? How do you organise the data?..."

Am I correct in summing up what you want as : "Someone explain to me how to organize a large game project" ?

Im having similar problems (I think). The round that my tank fires, should it be its own class? Should I make a class that holds all matrix functions and call its members whenever something should move? How does one "pause" a game and suspend all activity? Etc....

Ive found a ton of articles on the use of complex, paragraph like functions, yet NONE on how to organize a project as you described. You can get the documentation for what a D3DXMATRIX is easily, yet how does one string all this together into cohesive units and make a game outta all of it?

-Jason