next »

[oahda]

I tend to just use global variables instead of singleton stuff.

Nasty.

Oh, come on. You're kidding yourself if you think that a singleton is anything other than a global variable in disguise.

It's not, but that very disguise is easer to keep track off.

[BadgerManufactureInc]

I tend to just use global variables instead of singleton stuff.

This, most of my game logic and assets are also in my main class, not just because I used to code imperatively but because I find it easier to never have a deep object hierarchy.  My way of thinking is that design patterns rooted in other fields are overkill for game dev.  Plus it seems from my testing that it is more efficient to embed one global bitmap data for all objects of the same type, rather than passing one across for each instance.  

We all work differently, and with that in mind I think the best advice you can give is to find your own style after dissecting as much source code as you can get the chance to read through.

Ultimately structure and architecture is not logic and mechanics, although the 2 are inseperable fundamentally they mean different things.  If you can organise your classes in a way that is simple for you and makes sense, then you are all set to focus on your logic.

I was taught on my cs degree (still want to finish the 3rd year sometime) that programmers spend 80% of their time reading code.  Just to fully put it in perspective, this hints at much less than 20% coding, since they have to eat and have a life as well.

Putting it into practice (although it includes reading your own code) certainly gives you a feel for the myriad of possible approaches.  For every documented pattern or architecture system source code, there are infinite other ways of doing things.  Lateral thought, and being able to spontaneously navigate through or shuffle large parts of your functionality is a huge skill to have in the programming field of problem solving, since things always break when new stuff is added, therefore you need to be alert enough to make them work again.  

No single architecture is going to mean that you avoid these hiccups, and by the same token no-one is superhuman enough to forsee every repercussion of every new architecture addition.  

Learning to expect not every line of code to be perfect the first time is a truly humble action that will help you to be less frustrated when they don't work first time.  I'm not sure how much advice you're asking for here, but another major skill is to always read your compiler errors and deal with them one at at time.

I've always modeled a state machine.

My 'state machine' is a collection of constants, again just global variables:

Code:

statesArray[MENU]=MainMenuloop;			
statesArray[GAMELOOP]=Mainloop;			
statesArray[PAUSE]=Mainloop;			
statesArray[GAMEOVER]=GameOverloop;	
statesArray[OPTIONS]=Optionsloop;			
statesArray[HELP]=Helploop;		

..since that's the minimum I could think of to make the program know which state it's on.

[Average Software]

I tend to just use global variables instead of singleton stuff.

My 'state machine' is a collection of constants, again just global variables:

Code:

statesArray[MENU]=MainMenuloop;			
statesArray[GAMELOOP]=Mainloop;			
statesArray[PAUSE]=Mainloop;			
statesArray[GAMEOVER]=GameOverloop;	
statesArray[OPTIONS]=Optionsloop;			
statesArray[HELP]=Helploop;		

..since that's the minimum I could think of to make the program know which state it's on.

I do something like that when I have a state that has a number of substates.

Code:

package body Logics.Game is
    -- Type for substate procedures.
    type Substate_Handler is
        not null access procedure (Object: in out State; Next: out Logic_Access);

    -- Array of substate procedures.
    Handlers: constant array (Substate) of Substate_Handler :=
        (New_Life => Process_New_Life'Access,
         Play => Process_Play'Access,
         Paused => Process_Paused'Access,
         Scroll => Process_Scroll'Access,
         Map => Process_Map'Access,
         Stage_Clear => Process_Stage_Clear'Access,
         Death => Process_Death'Access,
         Score_Entry => Process_Score_Entry'Access,
         Game_Over => Process_Game_Over'Access);

[BadgerManufactureInc]

Intersting to see.  

I know a lot of people use tasks, queues and managers.  Some have experience in real-time programming industries, such as Donald Leabeau who made Gauntlet.  Here are some of his architecture ideas.

Even if you don't agree with or end up adopting someone else's architecture, it's always worth seeing another approach as you may agree with certain parts of its philosophy.

For me I ony use the states listed above, so they aren't substates they are just states.  In fact they are function names, and all they are used for is this:

Code:

..
// On click new game
..
removeEventListener(Event.ENTER_FRAME, statesArray[gamestate]);
gamestate=NEWGAME;
addEventListener(Event.ENTER_FRAME, statesArray[gamestate]);//, false, 0, true);