Jump to content
  • Advertisement
  • entries
  • comments
  • views

Now in Colour!

Sign in to follow this  
Trapper Zoid


I've made some updated to my system architecture diagram. Again click on the image for a larger version:

Again it's still a draft, and I haven't put in any links showing the relationship between the boxes. However I'm starting to get a better feel for how everything fits together.

In this version, the element boxes that hang out over the coloured zones are the ones that can be accessed by the game itself, with the exception of the utility classes on the right which are available to everything.

The major change in this model is the system is much more event based. I've replaced the message passing system with an event system based on some info I've been reading in the forums lately. The kernel now is just a specialised event system, sending update signals to whoever registers for them.

Interfaces between most modules are done through interface classes, which will most likely just be events that code can register functions to. I'm not sure if I'll make some differences between the input and output interfaces, although for some of them (such as the game input interface) the number and nature of the events will have to depend on the number of actions available in the game.

The main break from a pure event driven system lies in the graphics module. I'm just not comfortable with passing everything between the game module and the graphics module by event, having total decoupling. For the purposes of speed at the very least the game module needs to nicely pack up all the sprite info into a nice array structure so the graphics system can quickly blit them all to the screen. That's why the sprite and sprite pool classes are visible to the game.

The other break is in the file input/output classes. Again, I'm not sure if an event passing system is the best way to deal with something as fundamental as the logging system, for example.

That all being said, I'm getting pretty pleased with how this is shaping up. I know that there will be changes once I get to the implementation, but I think the basic methodology behind the system is sound. Once I'm happy with my thought experiment trials of how information is passed around the system I'll move to the next stage of design.

Any comments and questions are welcome; they'll help me figure out the things I've overlooked!
Sign in to follow this  


Recommended Comments

That actually reminds me a lot of a diagram I saw the xna guys drew before creating xna build.

Share this comment

Link to comment
Original post by paulecoyote
That actually reminds me a lot of a diagram I saw the xna guys drew before creating xna build.

In content, or in the use of colour and comic fonts? [smile]

(I'd better check up on XNA Build and see what they're doing...)

Share this comment

Link to comment
Fancy design. I don't think I've done an object design in ten years that didn't fit on two sticky notes.

"Okay, I'll do the internals like this [draws a couple of circles and arrows] and I'll wing the rest."

Share this comment

Link to comment
I never do mine on the computer because it constrains my ability to change shit.

Pencils, paper, beer. That's it.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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!