Jump to content
  • Advertisement
  • entries
  • comments
  • views

Architecture Overview

Sign in to follow this  
Trapper Zoid


I'm still plugging away at the architecture for my revamp of the engine. Above is a hacked together diagram in Inkscape showing where I presently am; click the image for the larger version. Most of those modules are unchanged from what I current have in Ice Slider, however I've added in a few new things into the graphics section based on some ideas spawned from the forums.

Important points to note:

Everything is weirdly spaced for a reason; I'm still thinking through the whole plan. I mainly built the diagram so I can easily shift things around and create new boxes. That's why there's so much empty space.

None of the names are final and the descriptions are very brief.

Audio is currently completely blank; I never got around to making any of the audio code for Ice Slider, and I haven't yet decided what to put here. I'm fairly sure whatever I do will communicate with messages or events, so it should be completely decoupled from the game code.

I'm still in two minds about the relationship between the kernel and the message passing system. In essence the kernel is a specific message passer, sending update signals to tasks. I could therefore wrap the two things together into a single class. However I'm also not too sure about having all messages passed in a single monster controller. It might be nice from a logging perspective (I can just plug in some debug code to see all the messages in the system), but it might be better to make a specific message passer for each type of message. I'm also not sure whether I should be calling them "messages", "events" or something else entirely.

Utility classes haven't been finalised yet. I'll probably add a whole heap more once I realise what I need.

"World" is just my name for the collection of data that describes the state of the game; not the graphics, sound or controls but the positions and internal state of the game actors. Most of this would be game specific but there's a few classes that are universal.

I'm going to try and step through a few procedures on paper to see if I have everything I need for the basics and then start making links. Once I have the basic arcitecture planned I'll flesh out the class interfaces. I don't see any reason to do this in UML form; I'll just write out the C++ headers and create doxygen docs.
Sign in to follow this  


Recommended Comments

There are no comments to display.

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!