I just want to say that Lazy Foo's SDL tutorials are really good for beginners. They are very simple, short, progressive, and they work. Kudos to Lazy Foo for these.
It even made me change my sig. I guess that every week or so, I'll put a new web site that target beginners as a link in my sig .
Software Design
It seems that this is what I mostly do these day on these boards. Really, I like it. Actually, I like object oriented software design (this is an evolution: I used to love coding but and I continue to to love it, but software design is so great that I tend to prefer design to code).
The last one was about the design of a game state manager (here) and I believe there's some good ideas in this design.
I won't speak of the subject itself (you are probably clever enough to be able to click on the link above) but the way of thinking that is behind.
First, I tend to encourage closed design. This is the reason why I did the GameStateManager this way: it is generic and don't have to be modified to adapt ato a new situation. The Game object itself may also be generic if we feed it with an abstract factory that will be responsible for creating the different game states. Again, this is a closed design (you don't have to modify the game object in order to modify the behavior of the game). The only things that will need some modifications are the game states and the game state abstract factory. Both inherit existing classes (GameStateFactory and GameState). I don't need to modify these, since I can extend them using inheritance.
2nd point: I tend to encourage the use of design patterns. Inheritance is a key feature for some design patterns - for example, our GameState class is a policy (a multi-policy in fact). The behavior of the object do not depends upon its base interface.
Conclusion: this is an exemple of using the open-closed principle (as well as an exemple of how abstract factories and the policy pattern can be useful).
This conclusion is also true when I reread my answer to Nitage's question. Again, the main goal is to provide solution that won't need to modify anything (adding a new tool don't change the Terrain class) but that will still let the programmer whatever he wants. This time, I achieved the goal by using the policy pattern (for tools) and the (powerfull) iterator paradigm. Moreover, we also dissociated the tool class from the terrain class (the tool class and the terrain class both depends upon the iterator class, which is an abstraction that can be rather... abstract).
Really, I like software design.
Of course, I have to take care of one important thing: it seems that I'm getting prouder and prouder... Oh, well, I guess that someone will remind me what "humble" means [smile]
