🔒 Locked

Subsystems

Started by Boris Karloff Dec 21, 2004 at 4:41 PM 5 replies 850+ views

Original Post

Dec 21, 2004 at 4:41 PM

I'm in te process of reading the second edition of Code Complete, and I'm trying to put some of the things I learned from that book to the test. However, I'm wondering if I'm thinking about this the right way, and if not, what I need to change. Chapter 5 discusses design, and reccomends using several layers: The entire software system consists of several subsystems (which know as little about each other as possible), which in turn each contain several different classes. (Fortunately, this particular chapter is available as a sample on the author's website as a pdf file. Look at pages 82 through 85 for the discussion on subsystems I'm talking about.) As subsystems, the book lists, for example, User Interface, Graphics, Data Access, Application Level Classes (??), Enterprise Level Tools (???), etcetera. I've been trying to split your basic game up into these subsystems and came up with the following: Input (containing classes like Keyboard, Timer and Mouse which figure out and report if any input happened) Output (containing things like Sound and Graphics) Data (containing scripts and game data, and ways of reading/writing them to disc) User Interface (containing menu structures and such. This keeps turning up as the central hub in every design I make. It asks Input what input has occured, manipulates Data in some way, tells output what to render, etc.) Basically, in all my designs, User Interface keeps turning up as the subsystem interacting with all the other subsystems. I can't shake the feeling that there's something not right about this. How am I thinking the wrong way about this? What could I do to improve the design?

Oluseyi

Dec 21, 2004 at 4:57 PM

Read up on Model-View-Controller. Software Engineering is a craft, a delicate balance of disparate concerns and interest. It takes time to develop a good "feel" for it.

SiCrane

Dec 21, 2004 at 5:34 PM

Commented more specifically, if your UI subsystem is too tightly coupled with the rest of your subsystems, it's probably suffering from a lack of abstraction.

Ok, it's hard to imagine a UI subsystem that doesn't need access to the input subsystem. But it's easy to imagine a input subsystem that doesn't need access to the UI subsystem. In that case you could say that the input subsystem is agnostic to it's users. Consider one way to handle this: instead of having UI elements query input directly, when you create a UIElement, you pass it a InputProvider, and the UIElement registers itself with the InputProvider via some sort of signals and slots mechanism. In that situation, the UI subsystem doesn't necessarily have to deal with the input subsystem directly. Indeed, UIElements themeselves could be InputProviders to create hiearchies of controls.

By abstracting this way you can create a UI system that doesn't need to specifically poke around in the input subsystem.

Take the next concern, the UI elements need to do something when they're twiddled. For example, when you press a button, something should happen. Instead of hardcoding this into a button class, you can abstract it with signals and slots again.

Admittedly something has to know about both the UI subsystem and the input subsystem, and something has to know about both the UI subsystem and the game data. But that's ok; if your program is completely decoupled it can't do anything. I'm just saying UI doesn't have to be some massive hub. Maybe for some application out there, making UI a massive hub is the right design choice. I don't think I've worked on a project like this before, but I'm not betting against its existance.

Boris Karloff

Dec 21, 2004 at 7:18 PM

That sounds an awful lot like implementation details... What I'm currently looking for is a divison of this game/program into various subsystems. How they'll communicate is of later concern, I'm just wondering what a prober division into separate systems would look like for a typical game application.

Boris Karloff

Dec 21, 2004 at 7:21 PM

That MVC page looks interesting, by the way... It reminds me of MFC's document/view system... with Model being the document and View being the.. view. Interesting, I'll check up on that more, too.

Edit: Doh. Just read closer and noticed they mention Document/View on the page.

Shannon Barber

Dec 22, 2004 at 12:53 PM

Doc/View is actually more modern, IIRC it's called APC. With classic MVC, every widget has a model, view, and a controller. With Doc/View there's one model, multiple views (composed of many widgets), and the controller is not well defined.
It is a very common misconception that MFC's doc/view is an example of MVC.

Oluseyi

Dec 22, 2004 at 1:15 PM

Love the avatar, Magmai! [smile]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.