shadow12345: Haha, I didn''t say it would work, but you see I have other programmers on the team and they would be doing the implmentations, not me. So I have to make the hierarchy do as much as possible in order not to erm let them screw it up. Though I concede the fact that this is impossible because anyone who would want to screw things up could do so.

But that''s not the point, I simply want to make it such accidents don''t happen. =p

Ravyne: Yes, I''ve discussed it with the other programmers and though they find no reason not to use static stuff, they say that it''s not really a good design. I disagree, since this way makes classes more closely knit.

What I mentioned about it being obscure is that, you don''t really know what the class is. It can be an instance and thus the actual entity or it could be used for the static members as a Flyweight.

I guess I still have some sorting out to do. I have other things to code in the meantime so don''t worry, I''m not wasting my time just doing thinking. =p

Hmm well I''ve thought about it and the only reason to use Flyweights in this case is to allow designers to create variations of the same entity to exist at the same time.

Imagine if static variables were used, you can only have one type of entity per class. If say you had a manager for loading and unloading flyweights, a designer can take an existing entity and change it and both would exist and use only one class.

My game could probably use that kind of functionality, so I''ll use flyweights.

shadow12345: Yeah keeping it simple is great, but as I mentioned, making it simpler in the long run is worth the trouble now.

Ah just when I''ve thought of almost the same solution, you posted that! =p It was a good read, thanks.

Well already we are implementing such a system in the Flyweight. However, that is not the problem. I realise that I can avoid having two classes for each type of entity, by putting as much functionality into the Flyweight instead of the Exported state.

That being said, all entities in the game are treated the same way, but the Flyweight controls its behaviour. I will have an implementation up soon.

Also if certain entities require more than the default processing, we don''t have to subclass it to create distinct behaviour, instead the Decorator pattern uses object composition to change behaviour. But I''m not sure if this is needed yet.