Jump to content
  • Advertisement
Sign in to follow this  
lucky6969b

State machine (Message Passing)

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Without the help of MFC (Just win32), how can I implement a message passing mechanism for the state machine to work with

Here, every agent will get its own Scheduler, all messages are generated by the Main Class or other classes?

 

Thanks

Jack

Edited by lucky6969b

Share this post


Link to post
Share on other sites
Advertisement
I don't know or understand how MFC is related to messaging, but I am guessing you're looking for the main loop?

The main loop is pretty trivial. You have 2 functions: "accept_message", which takes a message to pass around and puts it in a queue, and a "main", which does

while queue_has_message():
    msg = get_message_from_queue(); // Also deletes the message from the queue.
    for m in state_machines:
        m.deliver_message(msg); // Assumption, state machine will copy interesting info from the message.
    end
    destroy msg;
end
Does that answer your question?

This loop ends when you run out of messages. At that moment you probably want to do something else, like wait for a new message/event.


Alternatively, you can add a delivery time-stamp to the "accept_message" parameter, and order messages on time. In that case, you likely also want to broadcast the new time to all state machines.
now = 0; // Start time
while queue_has_message():
    msg = get_message_from_queue(); // Also deletes the message from the queue.
    if msg.time_stamp > now:
        for m in state_machines:
            m.update_time(msg.time_stamp - now);
        end
        now = msg.time_stamp;
    end

    for m in state_machines:
        m.deliver_message(msg); // Assumption, state machine will copy interesting info from the message.
    end
    destroy msg;
end

Share this post


Link to post
Share on other sites

Should I decouple the state machine objects from the GameObject, and use a state machine component to represent it that can run in its own thread?

Thanks

Jack

Share this post


Link to post
Share on other sites

Should I decouple the state machine objects from the GameObject, and use a state machine component to represent it that can run in its own thread?

Assuming the statemachines eventually do something with the game objects, if you move them to a separate thread, you need to handle atomic read/write of the game objects.

Also, assuming other threads use the game objects at the same time, how do you handle consistency? That is, while one thread draws the object, the statemachine updates them, so part of the display is old state, and part of the display is new state?


I would try to fold the delivery mechanism into the gameloop if possible, avoiding such problems. Edited by Alberth

Share this post


Link to post
Share on other sites

I see, seems like I have over-tried to roll everything into a single component.

So in other words, state machine is better off with the same thread as the GameObject thread or

in the main thread, while it is more suited to move the transformations, rendering stuff in other

components and run in their own?

The final words are a bit off-topic. Sorry about that

Thanks

Jack

Share this post


Link to post
Share on other sites

I see, seems like I have over-tried to roll everything into a single component.
Balancing a design is one of the hardest things in programming. Especially when you're at the stage of finding it all out, you are likely to pick the (somewhat) wrong solution.

In general it isn't bad, things generally do work, perhaps a bit less fast or with more programming effort.

 

So in other words, state machine is better off with the same thread as the GameObject thread or

in the main thread, while it is more suited to move the transformations, rendering stuff in other

components and run in their own?
I really don't know, it depends deeply on scale and other design parts.

 

Threads are often seen as the magic way to speed the program up. Many people don't realize that threads do really run independent, and you do need to handle data consistency if two or more threads access the same data at the same time, or it will break every now and then at seemingly random points in seemingly random ways.

Also, debugging is a lot more complicated with threads than without them.

 

I avoid threads like the plague, but maybe for your application they are really needed. If you add them, consider what thread runs when, and what data each thread touches (multiple reads is fine, anything write is tricky). If you have threads reading/writing or writing/writing, consider carefully what should happen in case the access the same thing at the same time.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!