major doubt..
Author
i was wondering, in all these rts games, we see hundreds of units and each unit has their own stats (some are common, except for health and stuff).. what i was wondering was, is each unit represented as a object thread and then manipulated. do they ever use so many threads? so they have one common object for each type of unit.. its damn confusin..
if u can throw me some light on this subject, i would be really grateful for u.. thanx a lot..
Slow and steady wins the race.
Object speed and capability would be stored at the object registry level. (Marine stats, Tank stats)
Position and health would be stored at the game object level. (Marine 1, Marine 2, Tank 1)
Some attributes can be copied from the registry down to the object level to establish a default value, but then be modified by another effect (haste used to speed up a marine, for example, would modify the speed of that marine, not all marines)
Does that help? Separate threads can be used for each object, but that's kind of overkill, I think.
-----------------------
- Waverider
A healthy humility and more realistic approach towards what you know comes from realizing what other people know, too.
[edited by - Waverider on March 21, 2002 2:13:15 PM]
Position and health would be stored at the game object level. (Marine 1, Marine 2, Tank 1)
Some attributes can be copied from the registry down to the object level to establish a default value, but then be modified by another effect (haste used to speed up a marine, for example, would modify the speed of that marine, not all marines)
Does that help? Separate threads can be used for each object, but that's kind of overkill, I think.
-----------------------
- Waverider
A healthy humility and more realistic approach towards what you know comes from realizing what other people know, too.
[edited by - Waverider on March 21, 2002 2:13:15 PM]
Author
its kinda too high level for me.. i think i get ur point.. but how do u control a single unit? in these rts game, u can click a single unit and ask him to do whatever u want and click another unit and ask him to do what u want.. howz all this coordinated and syncronized.. is there major for loop or something similar lol.. i am a newbie to rts stuff..
Slow and steady wins the race.
Slow and steady wins the race.
It is necessary to create an event processor. The event processor has two functions. First, it simulates asynchronous activity by your objects, and second, it provides a simple mechanism for having a constant speed through various kinds of processors.
Asynchronous activity of your objects is simulated by a priority queue which holds a list of event objects and their time/priority stamps.
Constant speed is maintained because it is fairly easy to set up a timer which ticks every microsecond (or millisecond) and then use that as a trigger to execute any current events from that priority queue.
Each event contains a message such as ''KeyboardPress ''a'''' or ''mouseclick RightButton 32, 456''. That event, when executed can in turn spawn other additions to the event queue. Such as, for instance, an event that activates an a.i. or anything that you can imagine.
There are a few wrinkles to this. For instance, to have different kinds of interaction with the user, there needs to be some mechanism for each different kind of interaction that you want. A mouse click means a completely different thing when the method of interaction is a menu then if the game is in the main-play mode.
Also, another perk of having an event-processor is that it becomes fairly trivial to make the game have a pretty constant framerate. That is very helpful when doing animations and such.
If you wish to implement what I''ve been talking about, be sure to read up on the following topics -- polymorphism/virtual functions, queues, stacks, priority queues, homogenous classes, class wrappers, and operator/function overloading. And such a system is most easily implemented with an object-oriented structure. There would be a single instance of the EventProcessor class, a priority-queue of Event classes, a stack of Mode classes.
There is an example of the code for one of these at ''www.xmission.com/~tyrecius/downloads/index.html''. Download the ''shell'' program. This is an old copy of the program. It uses directx, and you''d have to install the directx sdk and tweak the settings to get it to run properly on your particular system.
-D
Asynchronous activity of your objects is simulated by a priority queue which holds a list of event objects and their time/priority stamps.
Constant speed is maintained because it is fairly easy to set up a timer which ticks every microsecond (or millisecond) and then use that as a trigger to execute any current events from that priority queue.
Each event contains a message such as ''KeyboardPress ''a'''' or ''mouseclick RightButton 32, 456''. That event, when executed can in turn spawn other additions to the event queue. Such as, for instance, an event that activates an a.i. or anything that you can imagine.
There are a few wrinkles to this. For instance, to have different kinds of interaction with the user, there needs to be some mechanism for each different kind of interaction that you want. A mouse click means a completely different thing when the method of interaction is a menu then if the game is in the main-play mode.
Also, another perk of having an event-processor is that it becomes fairly trivial to make the game have a pretty constant framerate. That is very helpful when doing animations and such.
If you wish to implement what I''ve been talking about, be sure to read up on the following topics -- polymorphism/virtual functions, queues, stacks, priority queues, homogenous classes, class wrappers, and operator/function overloading. And such a system is most easily implemented with an object-oriented structure. There would be a single instance of the EventProcessor class, a priority-queue of Event classes, a stack of Mode classes.
There is an example of the code for one of these at ''www.xmission.com/~tyrecius/downloads/index.html''. Download the ''shell'' program. This is an old copy of the program. It uses directx, and you''d have to install the directx sdk and tweak the settings to get it to run properly on your particular system.
-D
Author
wow that was kewl.. i have six yrs of experience in c and c++, so i know all these "polymorphism/virtual functions, queues, stacks, priority queues, homogenous classes, class wrappers, and operator/function overloading" stuff.. i used to program games on dos, but right now i am switching to windows game programming.. (have not been working on games for a while). i have a fair amount of knowledge in directx and opengl and stuff.. anywayz, though it looks kinda complicated, i think i''ll get it once i see the sample that u showed me.. thanx man
Slow and steady wins the race.
Slow and steady wins the race.
Sadly, so many threads would kill most processors. So the way you do it is to poll each object very rapidly (maybe 10 to 100 times a second, or even outside this range) and process each object a tiny amount each time. This means that each object has to remember what it''s doing so that it can continue doing it each time. This is just called its state and is often represented as 1 or more variables per object.
Most (but by no means all) games only have 1 ''real'' thread. (Although there may be additional threads handling exotic stuff like message handling or audio mixing.)
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
Most (but by no means all) games only have 1 ''real'' thread. (Although there may be additional threads handling exotic stuff like message handling or audio mixing.)
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement