Jump to content
  • Advertisement
  • entries
  • comments
  • views

Wow. An alien.

Sign in to follow this  
Emmanuel Deloget


News 'n stuff

Customizing this journal is not so complex after all. It may be dangerous but not complex (I hope noone will try to misuse this great opportunity).

I added some links in a column on the right. I'm happy.


My html skills are teh sux0rz. Like my notebook kebord.

Anyway, let's continue my "design course" (can I call this a course? I think it is obvious that my goal is not to design my 2D engine but to show how I design it, and why I design it this way).

Three components and one "little" deflection

I'm not sure deflection is the right word to use. Damn, I'm still unable to write correct english sentences (yeah, I know, I'm teh sux0rz too).

Last night I started to speak about design patterns. I made it clear that a game is made with data, algorithm, and a representation of these. Datas and algorithms can be abstracted as the model, and their representation is of course the view. We need the last one to complete the holy trinity: the controler. This is not difficult to locate it: the game input system is a very good candidate - and for now we'll stick with that.

You got it: this is one of the most famous mecanism: the model-view-controler, or MVC for those who are intimate with him. The MVC is well-known for its ability to be mapped to useful design patterns. Maybe we'll be able to study this in details in a subsequent journal entry (read: certainly not today, and maybe never. I'm dumbass ;)).

For those who don't know how the MVC works, let's define it using simple words. To a view is attached a controler. The controler is responsible for handling (for example) user input. In response to these inputs it modifies the model. In response to this modification, the model updates the attached views. You can learn more about MVC in [1].

MVC implies that the view knows how to represent the data. Since we are developping our graphic engine as a "component-on-the-shelf" (COTS, see [2]) we don't want the engine to know the model. Remember, We have discussed this issue in a previous journal entry. When we consider both predicates (the view knows the model and the graphic engine does not knows the model) we clearly see that the view component of the MVC must be split into two different components: the first one is the graphic engine itself. The second one is some kind of glue which will be able to transform a model into its representation.

The glue object interface may use the observer design pattern. In this pattern, the subject (the model in the MVC) sends an update() message to all its observers when it is modified. Let's do this more clearly using a pseudo C++ language:

class Controler
World w;
modifyWorld() { w.update(); }
onUserInput() { modifyWorld(); }

class World
View v;
updateView() { v.draw(this); }
update() { updateView(); }

class View
set gels;
GraphicEngine ge;

drawElement(GraphicElement gel)

draw(World w)
for_each_element(gels, drawElement);

This pseudo codes shows how we can create a game which is independant from the view. If we want to modify the view (maybe adding a third dimension) then we only have to modify the view. This is of course not simple - it may need a lot of work. But it is far better than modifying the whole game!

What else?

I believe I have to speak about the GraphicEngine itself again... Yeah. I may do that...


[1] Glenn E. Krasner and Stephen T. Pope. A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3):26-49, August/September 1988.
Some info can be found on wikipedia
[2] COTS are discussed at cmu.edu - they appear to name them "commercial-on-the-shelf" because of the nature of teh components themselves. For our purpose, what we want to create is really a COTS-like, not a real commercial component, hence my initial pick: "component-on-the-shef".

PS: it seems I can't remember how to create an anchor in da html. Let's do that next time...
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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!