Re: Introduction!

[Gregor Mueckl <GregorMueckl@gmx.de>]

Josef Spillner wrote:

> Hi,
> 
> On Monday 25 February 2002 17:24, katie@fysh.org wrote:
> 
>>To kick off a debate - anyone use Design Patterns in their games
>>programming?
>>
> 
> Patterns do automagically appear if projects grow, this is what I've 
> experienced. For a small 2-3k game one doesn't think that much about the data 
> structures, objects (if OOP at all), and related matters - only the UI and 
> the main algorithms determine the code.


True. Games with that little code don't need much of a design. There is 
not much room left for this in that little code. It would most likely 
just bloat the whole thing up.


> But beyond that, if it comes to extend a game and viewing it as a more 
> flexible engine, one will hardly move one without at least some patterns.


Yes. The funny thing here maybe is that the basic patterns actually stay 
the same. Every game tends to split up into input handling, game logic, 
rendering, maybe networking and sound/music output because these are the 
basic seperateable tasks a game engine has to do. And voila: there's 
your design pattern. It's not strict and not too detailed, but it is there.


> On the other hand, games try to avoid patterns in some situations. Imagine the 
> class of units in a game - instead of inheriting from such a class to create 
> a unique set of creatures, it is more likely to try to use one single class 
> (as long as it's possible, excluding maybe special units or heroes), and 
> assigning attributes to them which are not compiled in.


That's the point where at least common 3D engines try to avoid patterns 
as much as possible. Every aspect of the game rules (including physics 
and basic behaviour) that's hardcoded into the engine makes the engine 
less reuseable and therefore less attractive for future development (and 
a good engine still is a huge, expensive and time consuming project). So 
there you go with scriping languages, modularisation and plugins with 
which the game-specific stuff is bound to the engine. And this is where 
most of the design pattern specific stuff should be as well.


> (OK - I talk about free/open games where cheating the one way or the other 
> couldn't be prevented anyway.)
> 


Talking about cheating: It's unavoidable even in commercial, 
closed-source games. Commercial game developers struggle very hard to 
make life harder on cheaters, but technically it's just a new dimension 
of the hacker vs. cracker war.

My humble oppinon here is that cheating is much less fun when the game 
is open source because it's not the same kind of cheating done on closed 
source games. It's satisfying to the cheater if he can exploit a 
implementation bug or a design weakness he first has to discover. 
Cheating in an open source game is different: Open your text editor, 
read the source, find the appropriate passage, modify it to your 
likings, recompile and there you are. So what's the deal with this? 
Nothing. The solution is there. It's straightforward. And that doesn't 
make it fun anymore. At least that's what I believe.

Gregor

-- 
*****************************************************
* Gregor Mueckl                 GregorMueckl@gmx.de *
*                                                   *
* The ChallengeOS project:                          *
* http://challangeos.sourceforge.net                *
*****************************************************
* Math problems?                                    *
* Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].       *
*****************************************************