Process Management
When developing my games, I find it convenient to perceive a game much like an operating system. Both have many things in common - they both have a centralized kernel (or core), they have strict performance requirements which must be met in real-time, they must manage myriad resources, and they both have a series of loosely coupled processes to perform various tasks.
In operating systems, process management has been very thoroughly researched. Resource allocation, scheduling, concurrency, intercommunication - all of these things have been studied to for years.
In video game development, process management is not so well understood. If you talk to ten different people about how to manage the state of a game, you will get ten different management strategies. And I've never been presented with one I liked. Until I looked at operating systems.
I prefer to handle my game states with a process tree. That is, I have a series of processes that each have some small, indivisible task to perform. Each process can have any number of children and each one has its own resources. A process has full control over its children - it can add, kill, or manipulate them at leisure, but a process can not manipulate its ancestors or siblings. Most importantly, each process can receive and handle system events however necessary.
Part of what differentiates this system from an operating system process is that these processes can only respond to events - they are not always running concurrently in the background. In this respect, they moreso resemble interrupt handlers. I prefer to think of them as processes though, since they can have children and they have a large influence over the state of the system. Also, my processes are unprioritized; in operating systems you can assign a process a priority to determine how often it executes and you can also give processes fixed time limits before they must give up control, but in my system each process is guaranteed to receive every event it is interested in and can perform its operation in full before giving up control.
Intercommunication between game processes is done through typical event passing. Thus it is, by its nature, asynchronous and non-blocking. Further, since processes are guaranteed to finish executing without interruption, we do not have to worry about race conditions. However, I could easily envision an advancement for multicore architectures where processes could run with true concurrency - increasing performance, but potentially complicating the system.
That's most of the introductory material for this system. I've implemented it for past C++ games, and I've finished migrating it to my XNA projects. Over the course of the next few posts, I will probably go more in depth discussing implementation details and example usage.
In operating systems, process management has been very thoroughly researched. Resource allocation, scheduling, concurrency, intercommunication - all of these things have been studied to for years.
In video game development, process management is not so well understood. If you talk to ten different people about how to manage the state of a game, you will get ten different management strategies. And I've never been presented with one I liked. Until I looked at operating systems.
I prefer to handle my game states with a process tree. That is, I have a series of processes that each have some small, indivisible task to perform. Each process can have any number of children and each one has its own resources. A process has full control over its children - it can add, kill, or manipulate them at leisure, but a process can not manipulate its ancestors or siblings. Most importantly, each process can receive and handle system events however necessary.
Part of what differentiates this system from an operating system process is that these processes can only respond to events - they are not always running concurrently in the background. In this respect, they moreso resemble interrupt handlers. I prefer to think of them as processes though, since they can have children and they have a large influence over the state of the system. Also, my processes are unprioritized; in operating systems you can assign a process a priority to determine how often it executes and you can also give processes fixed time limits before they must give up control, but in my system each process is guaranteed to receive every event it is interested in and can perform its operation in full before giving up control.
Intercommunication between game processes is done through typical event passing. Thus it is, by its nature, asynchronous and non-blocking. Further, since processes are guaranteed to finish executing without interruption, we do not have to worry about race conditions. However, I could easily envision an advancement for multicore architectures where processes could run with true concurrency - increasing performance, but potentially complicating the system.
That's most of the introductory material for this system. I've implemented it for past C++ games, and I've finished migrating it to my XNA projects. Over the course of the next few posts, I will probably go more in depth discussing implementation details and example usage.
posted by Brian Sowers at
10:57 PM
0 Comments:
Post a Comment
<< Home