Let's talk about the structure of a game program
by Ben Heath · in Technical Issues · 05/06/2003 (1:35 pm) · 5 replies
I want to discuss how the overall structure and design of a game program. The more I meditate (ponder) on the idea, the more this is coming clear to me, and the more respect I have for the established game companies and their products. As I play through or think back to the Metal Gear games that I've played, as well as Zelda and Megaman, I begin to notice the layers of FSM's that make up these programs. (The guards in any MG game are finite state machines that (p)atrol, (sl)eep, (sc)out, (rep)ort to their commander, (req)uest backup, et cetera.)
Now, as I see it, a game program really is just a machine! It is not a physical machine, but rather it equates to a conceptual one! A game program is a Conceptual Complex Machine.
Now, think back to grade school. We were taught that a complex machine is made up by more simple machines. So, we come back to my earlier comment about the layers of FSM's that make up a game program. Even the player object is an FSM. Diana Gruber wrote that animated sprites are, in fact, FSM's as well.
This is why it is so much harder to write a role-playing game than Pac-Man or Tetris. There are simply not as many machines (or layers of them) involved in Pac-Man as in Breath of Fire. It just gets too complicated for one sane person.
Summary: A game program is a complex machine that is made up of many simple machines in cooperation. A final note is that this system encourages a modular design, be it object-oriented or not.
Well, I'd like to here any comments of yours. These were just a few thoughts that I wanted to post here.
Now, as I see it, a game program really is just a machine! It is not a physical machine, but rather it equates to a conceptual one! A game program is a Conceptual Complex Machine.
Now, think back to grade school. We were taught that a complex machine is made up by more simple machines. So, we come back to my earlier comment about the layers of FSM's that make up a game program. Even the player object is an FSM. Diana Gruber wrote that animated sprites are, in fact, FSM's as well.
This is why it is so much harder to write a role-playing game than Pac-Man or Tetris. There are simply not as many machines (or layers of them) involved in Pac-Man as in Breath of Fire. It just gets too complicated for one sane person.
Summary: A game program is a complex machine that is made up of many simple machines in cooperation. A final note is that this system encourages a modular design, be it object-oriented or not.
Well, I'd like to here any comments of yours. These were just a few thoughts that I wanted to post here.
#2
Though, obviously, you can look at any program as an FSM. The inputs are the possible movements of the mouse and key presses on the keyboard. The outputs are what you see on the screen and what sounds come out of the speakers.
So I think it's more helpful to think of things like AI in terms of finite state machines.
But you do have a point.
- Steve Fletcher
05/06/2003 (4:04 pm)
I don't think that RPGs really have more complicated FSM's in them. The "story" shouldn't really count as being an FSM. The dialogue is really just data, not an FSM - though you could look at it as being a trivial sort of FSM.Though, obviously, you can look at any program as an FSM. The inputs are the possible movements of the mouse and key presses on the keyboard. The outputs are what you see on the screen and what sounds come out of the speakers.
So I think it's more helpful to think of things like AI in terms of finite state machines.
But you do have a point.
- Steve Fletcher
#3
Also, who is to say that data cannot be interpreted as an FSM?
http://www.fastgraph.com/fsm.html
This is a link to an article by Diana Gruber, "Modeling Sprite Animation Using Finite State Automata." It really helped me think some of this stuff through.
05/06/2003 (4:24 pm)
What I mean, Steve, is that RPGs have so much more depth to them because they have so many more components than do games like Centipede, Donkey Kong, Pac-Man, et cetera. RPGs have so many more "machines" working together. Designing and writing this code can be a daunting task. It can be done by one person, but I would not work on it more than 20 minutes per work day as an indie.Also, who is to say that data cannot be interpreted as an FSM?
http://www.fastgraph.com/fsm.html
This is a link to an article by Diana Gruber, "Modeling Sprite Animation Using Finite State Automata." It really helped me think some of this stuff through.
#4
Languages and Machines: An Introduction to the Theory of Computer Science provides a good introduction to this kind of thing.
05/07/2003 (5:49 am)
Almost any computer or computer program can be reduced to a finite state machine. This is useful for theoretical purposes and when you want to do things like finite state verification to automatically test programs.Languages and Machines: An Introduction to the Theory of Computer Science provides a good introduction to this kind of thing.
#5
For instance, the game I finished (but am waiting to get art for - I think it's actually going to get done this time) is a 2d shooter called Ecoheroes. The programming and level design are done (as well as the music but that's irrelevant to this discussion). It's easily as complicated as Breath of Fire (the original SNES game). Breath of Fire's noncombat engine is basically just walk around and press the button to talk to things, and it's combat engine isn't much different. Then there's just the menu system, which is about the same as the menu "system" in Ecoheroes except that it has alot more options.
Unfortunately, I must admit that Breath of Fire is more fun than Ecoheroes. I do like Ecoheroes though, but since I programmed it, my opinion doesn't really count.
Obviously, more modern RPGs are much more complicated than Ecohoeroes, though. For instance, Fallout has a much higher order of magnitude of complication. And I'm sure there's more complicated examples. In particular, combat systems based on AD&D (well, maybe not 3rd edition - I haven't seen that) are unnecessarily complicated, but all that's hidden from the player. So it doesn't really count.
However, I don't see how you can say that something like Fallout is more complicated than something like Grand Theft Auto 3. Sure there's lots of stuff in Fallout. But there's lots of stuff in GTA3 too.
P.S. Hopefully, I didn't annoy too many people. I'm just wandering the forums while I'm waiting for Enterprise to start.
05/07/2003 (4:15 pm)
Although any RPG would have more characters and such than the games you listed, there are many non-RPGs with similar levels of complexity.For instance, the game I finished (but am waiting to get art for - I think it's actually going to get done this time) is a 2d shooter called Ecoheroes. The programming and level design are done (as well as the music but that's irrelevant to this discussion). It's easily as complicated as Breath of Fire (the original SNES game). Breath of Fire's noncombat engine is basically just walk around and press the button to talk to things, and it's combat engine isn't much different. Then there's just the menu system, which is about the same as the menu "system" in Ecoheroes except that it has alot more options.
Unfortunately, I must admit that Breath of Fire is more fun than Ecoheroes. I do like Ecoheroes though, but since I programmed it, my opinion doesn't really count.
Obviously, more modern RPGs are much more complicated than Ecohoeroes, though. For instance, Fallout has a much higher order of magnitude of complication. And I'm sure there's more complicated examples. In particular, combat systems based on AD&D (well, maybe not 3rd edition - I haven't seen that) are unnecessarily complicated, but all that's hidden from the player. So it doesn't really count.
However, I don't see how you can say that something like Fallout is more complicated than something like Grand Theft Auto 3. Sure there's lots of stuff in Fallout. But there's lots of stuff in GTA3 too.
P.S. Hopefully, I didn't annoy too many people. I'm just wandering the forums while I'm waiting for Enterprise to start.
Torque Owner Badguy
Simple ..
but they show the elegance of a system in place.
you could break this logic down into mechanics as well.
for example a Car vs. a Peddle Bike
examining each component leads to a clear understanding of the big picture.