   State Manager in C#
  After some tests and little demos I am trying to build my first complete gameEngine. I am currently reading the book "Programming Role-Playing Games with DirectX" and I''ve learned lots of things from there, but I am having a rought time decieding the ones I like and the ones I don''t or can''t implement at the moment.Amongst the things I definitely like is the state manager as a stack... I had previously used the good ol'' enum type for the possible states and the big case  But when the time to implement the stateManager arrived I have developed some questions about it:   - In the C++ book code the author puts in the stack pointer to functions. Should I store in the stack full classes, inheriting form a class State, with the Proccess metho overrided? or a struct?    - will this use of classes or structs suppose a huge performance overhead (I don''t belive it has to be so big)   In the end I think I want some orientation, tips and help because I feel it is not a good solution to store the structs, and even worse, and full class hierarchy for the states of the game.   To Iterate is human, To Recurse Divine... 
  This is for C++, but I''m confident you can carry the concept over to C# with minimal effort. The way I''d do it is to have an abstract State class with some kind of execute() interface method and then I''d derive a few classes each implementing a different state. Then I''d have a context class that holds a single pointer to the current state. Switching states would either be done in each concrete state class (which would mean that each state would have to know about at least one other state, which might not be flexible enough for you) by delete''ing the current state and instantiating a new one, or have some kind of state table to select the appropriate state from. In any event, this setup should be flexible and fast enough that you won''t notice a speed drop (remember the 80-20 rule). Worry about efficiency when you finish your game and you''re ready to profile, but on the same token don''t program sloppily. ;  Thanks for your tips.. I''ll try your approach, but one more question. I am afraid I don''t know what is that 80-20 rule about And about optimizations, It''s true that the most important thing is to finsh.. but I like to wait some minutes before coding as a mad man and trying to find the best approach first, both in terms of flexibility and speed at least.   To Iterate is human, To Recurse Divine... ;  I believe in programming context, the 80-20 rule refers to 20% of the code consuming 80% of the execution time. ;  The implication being that it is a waste of time to optimize the 80% of code.   --AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [Blog] [RSS] [Browse the source] [IRC channel] ;  Just for completeness. The C#/.NET equivalent of a function pointer is a delegate, so you *could* put delegates in the stack instead of   state-objects. However, I''d stick to that state-objects-solution as well.Regards,Andre (VizOne) Loker ;  Thanks for the info all of you.. about the Delegates, what would be it''s advantages and it''s trade-offs? I think they are a lot less flexible, but would them be faster? allocate less memory? produce less fragmentation? Thanks again for the info.. this is a great way to learn ;quote:Original post by TheObscured  allocate less memory? produce less fragmentation?  The .NET heap doesn''t fragment.  ;  For what i know it does.. being a generational managed heap... if I start builiding mane new objects, they obviously fall into generation 0.. I thought I must avoid useles objects being spreading like fool, to avoid the need of repacking (I don''t know the english name).   To Iterate is human, To Recurse Divine... ;quote:Original post by TheObscured    I think they are a lot less flexible, but would them be faster? allocate less memory? produce less fragmentation? Well, delegates have a  small overhead, in speed (more indirection), as well as in memory consumption (they derive from MulticastDelegate, so they have (on 32bit machines) the 8 bytes from Object, 4 bytes for the target, 4 bytes for the method and some kind of collection to store the invocation list in - or at least so I'd say...).What you really gain is flexibility. You can link the delegate to any fitting method without the need of deriving gamestateclasses for each and every state.I'd suggest a combination of both worlds: make a abstract class/interface for gamestates with an update-method as you already described. Then derive one version that simply wraps a delegate of the same type as your update-method. Make the updatemethod simply invoke the delegate. This way you can use a delegate but make it compatible to other gamestate-objects.public delegate void StateCallback();public interface IGameState{void Update();}public class DelegateGameState : IGameState{public DelegateGameState(StateCallback cb){m_callback = cb;}#region IGameState Memberpublic void Update(){m_callback();}#endregionprivate StateCallback m_callback;}// ...// usage:DelegateGameState dgs = new DelegateGameState(new StateCallback(DoIt));//...public void DoIt(){   // your update stuff}    OK, most of the time this won't be very usefull. Typically gamestates have some state variables with them, so you'd rather stick to normal gamestate-objects, but if you have a really simple gamestate method you could use a DelegateGameState. Well, just an idea, not really usefull Regards,Andre Loker   [edited by - VizOne on February 18, 2004 6:41:13 PM] [edited by - VizOne on February 18, 2004 6:41:49 PM]