🔒 Locked

Design: State model

Started by Shadow Mint Jun 14, 2002 at 9:59 PM 4 replies 350+ views

Original Post

Jun 14, 2002 at 9:59 PM

Greetings. This is an open design thread; a fall out from a thread I started before on the Article Requests forum. Comments and ideas welcome from all; thread may eventually be used as a basis for an article on data modeling. Objective: - To design a state model for an RTS game. - Have some fun doing so.

Scope: For the purposes of this design, lets start with some pretty rigorous scope limitations. I propose (and I'm open to suggestions on this): * Design covers a single model, State. * State model is responsible for: game object definitions, game object interactions and game object organisation. * State model is not responsible in anyway for other game subsystems. * State model communicates only with two other modules: System Interface and Scheduler. * State may use the System Interface to load data, and to hold copy of data (so other systems can use it too) * State must accept new requests from the scheduler. These represent new input that affects the game state (for example, player input). * Design must specify acceptable requests from the scheduler. I think that covers it; basically, nothing but the game state is relevant in this module. Rendering, audio, whatever. Not important here; only focus is on data modeling and data objects for the game. The state module runs independently of whatever the user is doing, and only changes from the way it normally runs when the scheduler allows a user action (from a network, local interface or whatever talks to the scheduler) to reach it. In reality, some of this information has to leak out so that the game state can be drawn for the user each frame, and so on. For the purposes on this design, lets not worry about that. Notes: This is not I hope, just going to be an exercise in writing a class hierarchy. The point of it is to do some modeling of the data objects, and how they interact. It may include one or more class hierarchies at some point though. Finally, I guess this might not be quite the right forum for this, but its close enough. Anyone is welcome to drop in and make comments; if you arent interested, just ignore the thread.

Edit - Fixed a few spelling mistakes. [edited by - Shadow Mint on June 14, 2002 11:02:03 PM]

Shadow Mint

Jun 14, 2002 at 10:03 PM

Let me kick this thread off with some food for thought:

The system is an RTS, so the general state is going to consist of three things: a set of objects, a set of players and an environment.

Every game frame every object acts as an autonomous agent and has the oportunity to perform some action.

Objects may fall into a bunch of different categories; tangible physical object, further divided into active objects (that can perform actions) and passive objects (that cant), and virtual objects that are part of the game state, but dont represent a physical unit in game terms (for example, an satellite that provides a fixed radius of exploration and moves around, or way points, build queue objects, etc.).

Any suggestions?

I''d suggest at least at a high level:

environment
-> Cant imagine environment type needing different types. I''m thinking a general
-> space, which can hold a finite unit count in discrete coordinates...

player
-> ... sub-class of players? Is an AI player different from a normal player?
-> is a handicap''d player different froma normal player, is a watching player
-> different from a normal player?

object (belongs or is associated with some player)
-->physical (in game world)
---->tangible (is associated with at least one template)
---->template
------>active (does stuff)
--------> ? tank/ship/plane/robot?
------>passive (just sits there; eg. a tree)
--------> ? structural/environmental/field?

->virtual (not directly in game world; affects game world)
-->marker
-->?

lol. I''m probably going about this the wrong way, but I''m just brain sttorming at this point. The question is really: What does an RTS consist of, and what can they do? What generalisations of those things are good to use?

Just thoughts. =)

jermz

Jun 14, 2002 at 10:12 PM

Whats driving all this? Given player input does the state just chug along in its update and then display the results or does it act as more of a database for something else. What exactly goes through the scheduler and system interface? Would npcs interact with the state like the player?

Shadow Mint

Jun 14, 2002 at 11:39 PM

quote:
Original post by jermz
Whats driving all this? Given player input does the state just chug along in its update and then display the results or does it act as more of a database for something else. What exactly goes through the scheduler and system interface? Would npcs interact with the state like the player?

The state handles updating and maintaining the state of game objects.

So...for example if you have 20 units, all with patrol commands. The state ticks over about 30 times a second, and each tick the units move a tiny bit, and potentially, if they interact, take up different actions like shooting each other or running away.

It -is- a database, but it is also a physics, logic and control system. Its not a transaction system; user input; system processes and responds. My model assumes something like: user inputs. Some time later (few Ms) the external system polls and determines the user has entered a command. The external system schedules the event and/or sends it off to server/clients. Some time later (probably a few ms, once all current user requests have been processed) the scheduler resumes. When the time for a scheduled event occurs, (a few ms later or few ms + total network latency possibly) the scheduler posts the new request to the state module. We're talking total turn about of about 20ms + network latency maybe. Additionally obviously things that dont affect the state (just selecting a unit but not changing its orders for example) can be processed on the fly, immediately. Whatever. It doesnt matter.

The point is: although the state can accept input from the user, user input is happening not-very-often, and its not happening directly (user->state), so for the majority of the time, the state processes as though there -were no user- attached.

If by NPC you mean AI player, then yes. The systems controlling introducing new commands into the state module are external completely and beyond this scope. An AI player is not distinguishable from a normal player to the state module.

Edit - Spelling error.

[edited by - Shadow Mint on June 14, 2002 12:40:42 AM]

Oluseyi

Jun 15, 2002 at 2:03 AM

Certain properties can be deemed common to all mobile objects (from planes to buildings, which are mobile in the sense that they can be built at arbitrary locations and blown up at will), and certain others even to immobile objects (generally landscape and related features). I consider the latter category first.

In any reasonably modern RTS, terrain should provide advantage/disadvantage based on natural characateristics. What features constitute this bonus?

Elevation: higher ground affords you a better view and an advantage in artillery placements.

Traction: How "firm" the ground is determines whether it''s logical to send heavy machinery over it, and the availability of this information for the state machine would yield more believable AI pathing. As an added bonus, traction can be considered a function of absolute "earth" and "water" coefficients - high earth and low water is rock-like and difficult; low earth and zero water is sandy desert; low-to-medium earth and high water is mud; high earth and high water is slick, slippery rock; zero earth and any water varies from a stream to a river (water magnitude indicates depth). Heuristics such as "at low temperatures, a high earth-high water passage would likely be frozen over" thus emerge from this representation.

Temperature: Cold, warm, hot, temperate... These would affect machinery and troops differently. Cold machinery doesn''t start so quickly, and cold immobile, troops could be susceptible to frost bite and other winter ails (depending on how cold we''re talking about here). It''s already obvious that a little extra state design work has opened up the potential for deeper, more immersive simulation and, consequently, gameplay.

Other landscape states exist (pressure, for example). I leave others to define them and their potential applications. Terrain has little state transition largely due to its immobility and the general stability of weather patterns on our planet. However note that it becomes possible to simulate terrain deformation at the data level merely by altering elevation.

To represent the terrain in data, either a "virtual" mesh of sampling points or a bezier data patch (because there shouldn''t be too much variability over limited areas other than elevation, and it scales in and out well) could be usead. Each vertex/node in this mesh/patch/graph would be the equivalent of a geographical survey reading for that location.

"Talk is cheap. Show the code!"

I would except that in the case of the model above, there''s not much - just a few structs.

I''m tired now.

Shadow Mint

Jun 16, 2002 at 10:55 PM

I''d presonally be tempted to model the terrain as simply another type of object. If the game space is simply a domain, you can have a very interesting map if you allow the environmental objects to be meshes like everything else, just with the -can-be-built-on property set.

For example, you can then have a gun-mount unit, which is simply an elevated platform that can have a gun-type built on the top.

You''d probably have to define buildable, traction, etc attributes for the objects on a per-mesh-polygon basis, determining if the units could move over it, build on it, etc.

Probably something along the lines of:

Object (any) consists of:
(basic attributes) + Mesh

Mesh consists of:
Array of polygons
Array of movable polygons (units can move over these)
Array of buildable polygons (units can build on these)

In order to allow that you''d need to have a building consist of a base plane, which limits the minimum size of mesh it can be built on, and maximum tolerable inclination of the surface, deviation in inclination of surfaces, if spanning multiple polygons).

In fact this means you can have complex structures like bridges; connected to two areas and creating a spanning gap between the two.

It also allows for composite environments for the game. For example; you can have a cave, or a natural rock bridge. You''d have to make sure that in general the environmental objects (basic; ie. the ground) could not be destroyed though.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.