Abstract of the previous shows
In the previous installment of my ongoing journal activity, I decided to speak about UML design. I now see that my wording is obscure and contains a lot of (sometimes kebod related) english errors. My bad. Nevertheless I decided to continue to speak about this subject - I find it interesting. Since noone really read this journal (thanks Mushu for the info), I bet it will not hurt your brains.
Good design, bad design
The preliminary design I got yesterday is a bit small. Some pseudo-C++ gives us:1
It raises an interesting question: who performs the drawing? Should we say that the GraphicEngine draws the World object or should we say that the World should draw itself using the GraphicEngine? The answer is not very simple.
First, let's consider a simple design issue: what if I decide to modify the graphic engine? I may decide to finally go the 3D way. I probably won't want to rebuild all the game code because of this modification- even it if is a large modification. Or I may decide to adapt the drawing to the device capabilities (a mobile phone is more restricted than a PC). Using this wording it seems that I should let my GraphicEngine draw the world. It means that my GraphicEngine will have to know how a World object is built. Here comes the problem...
OTOH the GraphicEngine is a base component that should not be aware of what the game really is. If I decide to modify my underlying World representation later - because of some important design issue - I will need to modify the GraphicEngine as well - even if the rendering itself do not change. Moreover, if I decide to add a new object type that have to be drawn then I'll have to modify the GraphicEngine as well.
Conclusion: there is something missing. We have to forget our preliminrary design and we need to find better answers to the questions I asked yesterday: who will use the graphic engine, and what will the actor do with it?
To be continued... :)