I wondered how I should do Flying Bullets or other objects that act by themselves if they get activated . Shall I work with threads (I tried already and made some good resutls, but not perfect) or shall I do this with simble Linked Lists (or shall I even combine this two technics). Or know someone what the pros do at such a situation? MARC MARC

I''m not a pro, but I''ve seen this method used for things that need to act on they''re own. This works best with an object oriented language like C++.
Basically it works like this. You would define all objects that act independently as having some member function that told the object to do whatever it is supposed to do. I usually call this function Tick(); (as in the tick-tock of a clock), or you could just call it DoSomething(). In the case of your flying bullets this function could update the bullets position, determine whether it has hit anything or not, and/or draw the bullet. The Tick(); function of other objects would do things relevent to them.
Now, since we''re talking about flying bullets, I assume that your program has some sort of main loop for gameplay. This is where the Tick(); function would be called. You could simply put all your objects on a list, and on each pass of the loop, iterate through the objects calling Tick() for each one.
If your not using C++, but you are using C, this same concept can be accomplished by funtion pointers. But since I''m not really up on function pointers I''ll let someone else explain that one.
The linked lists are a good idea, but IMO threads are complete overkill for something as simple as bullets. Also, I believe using threads would totally kill any sense of timing in a game, since they are independent of each other as to when they update. I think.

I''m not a pro, but I''ve seen this method used for things that need to act on they''re own. This works best with an object oriented language like C++.
Basically it works like this. You would define all objects that act independently as having some member function that told the object to do whatever it is supposed to do. I usually call this function Tick(); (as in the tick-tock of a clock), or you could just call it DoSomething(). In the case of your flying bullets this function could update the bullets position, determine whether it has hit anything or not, and/or draw the bullet. The Tick(); function of other objects would do things relevent to them.
Now, since we''re talking about flying bullets, I assume that your program has some sort of main loop for gameplay. This is where the Tick(); function would be called. You could simply put all your objects on a list, and on each pass of the loop, iterate through the objects calling Tick() for each one.
If your not using C++, but you are using C, this same concept can be accomplished by funtion pointers. But since I''m not really up on function pointers I''ll let someone else explain that one.
The linked lists are a good idea, but IMO threads are complete overkill for something as simple as bullets. Also, I believe using threads would totally kill any sense of timing in a game, since they are independent of each other as to when they update. I think.

Don''t use threads, as microdot said, their hard to control (Because they don''t depend on your main thread).
Using a linked list is a good idea, have one big linked list and each loop go through each item and check it''s state.
If it''s state is DRAW_ME, then update his position on the screen and draw him.
About function pointers, here''s the syntax:

int Function1(void);
int Function2(void);

int (*FuncPtr)(void);

FuncPtr = Function1; // Now FuncPtr will point at Function1

FuncPtr(); // run Function1();



- Goblineye Entertainment
The road to success is always under construction

Another possibility (other than a using a linked list) is the observer pattern.

Your bullets are in need for special informations (current time or frame to update their position, a collision event to calculate their impact and so on). For of these informations or events (the collision event, the next frame event) there are "servers" or "subjects" controlling them. For example a frame-counter is updated at the beginning of every new loop through the main loop.

Every observer (your bullets) subscribe themself to the informations of such a server (like the frame-counter). The servers (or subjects) inform all their subscribers (or listeners, or clients or observers :-) when their event happens (through a method call).

It looks like the main list which you would loop through at every main loop cycle but it has the advantage that you needn''t call every game object in every loop cycle (polling) - you just call your game objects if an important event has occured (event based).

THis method is a little more work to program than the main object list so you should think about the needs of your current project and use the appropriate method.

One problem with the event handling could be the reaction of a observer on several events - when one event is triggered and the listener is called it doesn''t know how many other events will be triggered.

Oh, and the information server need to be ordered - say the first server which updates its listeners is the next-frame server. He calls a bullet. The bullet calculates its new position (based on the last time increment form the last frame) and updates its position in the spatial database ( a grid, an octree or whatever). Now the collision server lokks for collisions (for example using the psiitions of objects at the last and the current frame) and calls the bullet too (it has hitten a wall). So: ordering of the servers is important.

Bjoern

If you want true-to-life ballistics, stick with this updating bullet position based on speed/gravity/vector and stuff. If you want something more like Quake 3''s shotgun/Machine Gun, then its called hitscanning. Basically it works like this, during your Tick(), you check the entire shot vector until it hits something, if that something is a player, do the damage, and thats that, if its an object, well, same thing,it ''dies''. The first way makes for what i feel is MUCH better gaming, but is a bit more processor intensive.
-Run_The_Shadows
-Run_The_Shadows@excite.com