Game Teirs

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

Recommended Posts

I'm not familiar with all the tiers and pieces of game applications, but a friend of mine wrote this at one point, and I want to know whether it's essentially correct, or what you would do instead. I'm trying to design a game for the first time, and I'd like to do it correctly, so I don't have to go back and redo a whole lot of things as I go along:
Quote:
 The laws of the game engine are hard coded from the start in the form of the Game Logic Layer, Human Game View, and the AI Agent Game View. There are other facets of the design, but these are the major three that damn near anything in the game engine can be noted to be a subset of. All are of equal importance in the making of a successful computer game, though one may not be as large as the other. The Game Logic Layer consists of five major parts. First, and foremost there is the Game State & Data Structures. Let's face it. Some of these can get pretty nasty as far as figuring out what is what. And a video game is nothing more than fancy number crunching of a massive shitload of 1's and 0's. This defines what those 1's and 0's mean to the user. The second major section is the Physics. Fair warning: When I say game physics, I do not mean neutonian physics programmed with he likes of Half-Life 2 in mind, though they're certainly a fair facet of this section. These are merely the laws which govern the said game universe, and define how the program reacts to the user's input. For those who have played Half-Life, they should have a special place in their hearts for the third major section: Events. Again, this is more general than you might want to think. When the game logic makes changes in the game state, such as creating an object, a number of game systems will respond, from the graphics to sound, to AI. The fourth part of the Game Logic Layer is the Process Manager. This is the game's operating system. And Yes, games need their own personalized operating system. The Process Manager keeps a list of processes acting on the game objects and gives each one a little CPU time by calling it once every game loop. The final bit in the Game Logic Layer is self explanatory: the Command Interpreter. This is the interface for the game to respond to the commands input by the player. The next big section falls under the Human Game View, and it also has five subsections, two of which have subsections of their own. First is Display. I could say foremost, as a human gamer can't do shit without something to look at. But like the first section, you take any one of these five out, and the entire game goes to hell. Nowadays it carries its own sections in the form of 3D Scenery, User Interface, and Video. The second group is Audio, which is broken down into Sound Effects, Music, and Speech. There's not a whole lot to say on these items that, this being a game forum, you guys don't know already. The Input Interpreter is what interfaces with the Command Interpreter of the Game Logic Layer. The human gives the game input, the first interpreter turns it into a command, and the second interpreter adjusts the game state and data structures appropriately. The Human Game View has its own Process Manager that can handle everything from button animations to streaming audio and video. They're used all over the game. The final section are the options. Let's face it, no human plays any game the same. They want it set up differently according to their hardware and their own personal preferences. A game without options is a game that will get burned. The Game View for an AI Agent can bee seen as somewhat simpler. There certainly isnt the video and sound processing, but a lot of the other interfaces are similar. The Stimulus Interpreter receives all the exact same events that the Human Game View does. The programmer determines what events will get the AI Agent to modify its course of action, and sets what stimuli the agent cares about. The Decision System is a completely custom-written subsystem that is dependant on what commands the Agent can send into the game. An AI Agent may have access to commands that the Human Player does not, and vice-versa. Following naturally to these two, the AI Game View has its Process Manager and Options, filling the same role as they do for the Human Game View, though the AI Options often are not truly modifiable by the player himself. With this type of setup, the Multiplayer is filtered through the Remote Game View and the Remote Game Logic and transferred from computer to computer over the network.

Share on other sites
Quote:
 I'm trying to design a game for the first time, and I'd like to do it correctly

Aww but you learn so much more when you do things wrong :P

Share on other sites
Quote:
 Original post by Pete MichaudI'm trying to design a game for the first time, and I'd like to do it correctly, so I don't have to go back and redo a whole lot of things as I go along:

You have set an impossible goal. Accept that you will make mistakes, lots and lots of mistakes. The smart approach is to start small so that any mistakes you make are small mistakes and are easily correctable.

Quote:
Original post by Pete Michaud
Quote:
 The laws of the game engine are hard coded from the start in the form of...

The person that wrote this is a newbie with poor writing skills. While what she wrote is not completely wrong, it is not very helpful. There are plenty of other writers that are much better at explaining the concepts. Search the GameDev forums for relevant topics and read the articles and books that people recommend.

Share on other sites
I have done that John -- the first problem is, what would such topics be called? The second is that the majority of information on here is geared toward people who already know basically what they are doing, and want to focus on specific problems, normally related to 3D stuff.

So, since my friend doesn't know his stuff, what books or resources would you recommend as having a fairly thorough overview of the layers that go into a game?

Share on other sites
Hi Pete,

It's good that you're asking these questions early on. Getting into a game project without fully realizing at least what's partially necessary to complete the game, is a good exercise in stress :)

Having said that, it's also important that you understand that mistakes will be made, you'll rewrite portions of code you think suck, or you'll totally trash a section of the game, and write it another method. That's OK. Indie game developers do it. Professional development houses do it (look at Windows Vista). But it's important that you understand concepts early on, in order to circumvent problems that you described as effectively as possible.

I don't have any links for you, but I can give you some advice gleaned from working on my own game engine. You can start by break a game down into logical interfaces which are (for the most part) unrelated: graphics, sound, input. Then you have objects upon which the interfaces interact: textures, sound files, and key-press events. Once you have a basic game shell working that allows you to capture, manipulate, and respond to these very basic elements of any game (e.g. play sounds, render sprites, etc), you can start with the next, more interesting section: the engine.

At this point you should be thinking in terms of 1) game-specific objects, and 2) game-specific object-managers. GSO's are those things in the game which can be manipulated, shot, eaten, thrown away, sat upon, or whatever. GSOM's are the managers of the GSO's; they maintain lists of each of the objects, sort them, search through them, and add/delete them. GSOM's can be made from arrays, linked lists, or if you're feeling particularly adventurous, STL containers.

Let's say you're working on a single-player Gauntlet clone:

The engine contains your game-specific objects, as well as an event manager. This means you have Creatures in the game (heroes, monsters). You have Power-ups (potions, food). You have miscellaneous objects (monster-factories, portals, locked doors, keys for the locked doors). And to link all of this together, you have game maps. You also have counters for health and score. You'll likely have at least two separate lists for creatures, and for powerups/misc objects.

Once all of these are working, you should be able to implement the following limitations and features:
- walking around on the map
- colliding with walls
- colliding with items (causing increases to statistics such as health, magic, score)
- moving between areas and maps using portals
- and so on

The last large part of this game would be to design a simple AI which moves nearby creatures toward the player.

There are lots of things which could be done with a game such as this (for example, competing with Diablo!), but this should give you a general layout of a game.

If you have any questions I'd be happy to help.

Share on other sites
Quote:
 ...it's also important that you understand that mistakes will be made, you'll rewrite portions of code you think suck, or you'll totally trash a section of the game, and write it another method. That's OK. Indie game developers do it. Professional development houses do it (look at Windows Vista). But it's important that you understand concepts early on, in order to circumvent problems that you described as effectively as possible.

You're speaking my language here man -- I have been a programmer for long enough to know that you're totally right. What I'm trying to accomplish is understanding the theory before I go hog wild.

Thanks for the post, it was really helpful... but as you know, I'll probably be back for more when I screw up 8)

I might as well ask now: the game I'm planning is meant to have interactivity with the environment. For example, one of the player characters might want to break through a wall. Obviously under normal circumstances with something like a Diablo clone, you could just draw the wall graphics to the screen with a passability map for collision, but if the player is going to be able to break it, then it'll have to actually be a GSO or Actor, or whatever you want to call it. That's great in theory, but if almost everything on screen is an actor, will that be too much data to crunch? Obviously for a Gauntlet clone computers are powerful enough, but what if I want a Diablo clone (which isn't far from accurate) in which walls and objects can be interacted with? Will that burn up too much processor, or is it feasible with current average hardware specs?

Share on other sites
I hope my info helps, but the thing is yes, the more well designed your game on paper before programming the less errors you can run into, but don't expect to not run into error. Other then that, All I can say is do it one step at a time, for instance I am making a mario clone entitled "Skurge" and like you I want to do one heck of a job, and not run into errors, but as I have been developing my images, sound engine, 2D graphics engine, and now working on physics and AI I find a better way to do this, or find an error here, or there and spend bout half an hour a day debugging if not more. But, as long as I accomplish one major goal of the game I had set for that day, or fix a big bug from the game I just go chugging along until I get work done. Also, you might one to set goals for your project atleast you'll be better organized. Well, this is far more info than what I wanted to give. Hope it helps some.

Machs gut!

c.s. finch

Share on other sites
Quote:
 Original post by Pete MichaudI might as well ask now: the game I'm planning is meant to have interactivity with the environment. For example, one of the player characters might want to break through a wall. Obviously under normal circumstances with something like a Diablo clone, you could just draw the wall graphics to the screen with a passability map for collision, but if the player is going to be able to break it, then it'll have to actually be a GSO or Actor, or whatever you want to call it. That's great in theory, but if almost everything on screen is an actor, will that be too much data to crunch? Obviously for a Gauntlet clone computers are powerful enough, but what if I want a Diablo clone (which isn't far from accurate) in which walls and objects can be interacted with? Will that burn up too much processor, or is it feasible with current average hardware specs?

In the example I gave above, you could add a feature to the map to have tiles (it will be tile-based, yes?) which have a "health" or "can be damaged" factor... for example a wall with -1 health might be un-damageable, 0 health is 'broken through', 1-50 health is 'slightly damaged', and 51-127 is 'normal strength'. This then could be represented with 3 graphics: rubble (for the broken-through wall), a wall with cracks (slightly damaged), and a normal wall. Also, it could be represented with a single signed byte.

Also, the way I handle state-change of different objects such that there isn't overload of number crunching, is to set up a state machine for different objects, and only change the state in an event-based manner.

For example, let's say you have a WallTile class, an Actor class (for monsters and player characters), an Object class (for potions, food, doors):

std::map<int, WallTile*> map;std::vector<Actor*> actors;std::vector<Object*> objects;

Each frame you'd run some sort of update on each list, moving movable objects based on time:

void UpdateActors(void){    for each actor in actors    {        actor.update(time_since_last_frame);    }}

And again each frame, render every object that appears onscreen:

void RenderEverything(){    for each walltile in map    {        render(walltile);    }    for each object in objects    {        render(object);    }    for each actor in actors    {        render(actor);    }}

Share on other sites

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

Create an account

Register a new account

• Forum Statistics

• Total Topics
628681
• Total Posts
2984188

• 13
• 12
• 9
• 10
• 10