using goto for game state machine

Pages: 12
Ducks are omnipotent - they can dive, swim, walk and fly.

And then there's a ducks breakfast - a drink of water and a shit.
(But definitely no spaghetti)
@seeplus again, i don't care if it's gonna be hard to read or if it's a pain in the ass later on.
if there's a part where using goto results in a faster code then i will use it.
there is no specific number of variables. you need to look at the whole design, what needs to happen, and minimize the work to get that done.

Goto isnt faster, I can't say that enough times, its the extra work / extra branching not the tool you use to trigger it that can be optimized. All branches look the same in machine language, it does not know anything besides "goto" (or goto like commands: jump / jumpnotzero/ jumpzero/family).

If you learn how to do this, you can condense a lot of code to a very small amount of code. It is something every coder should know, but isnt taugh at many places:
https://en.wikipedia.org/wiki/Karnaugh_map
@OP

goto doesn't lead to faster running!

Everything, without exception in assembly code, in this case, comes down to jmp or similar type instructions and after your goto's are processed and mangled and higher level branching is compiled it all ends up in the same place.

Trouble is your goto's and lack of discipline probaly won't do any more than crash your pile of spaghetti.

Considering you can't even control a f'kin duck I doubt whether a few nanoseconds at most, even if they existed, will make any difference.

You'd be better off getting a textbook on game programming, follow the tips you have so far ignored and resisted, and make the programs time-efficient by writing them properly.
i don't care if it's gonna be hard to read or if it's a pain in the ass later on.
if there's a part where using goto results in a faster code then i will use it.

Why?

You are prematurely optimizing the code. This is almost always a bad thing. You are sacrificing clarity for the sake of optimization. Optimization that you might not even need. So there's a good chance that your code will be both slow and hard to read.

using goto for game state machine

Then write a state machine:
1
2
3
4
5
6
7
8
9
10
11
12
while (true) {
    input = GetInput();
    switch(currentState) {
    case state1:
         do stuff;
         break;
    case state2:
         do other stuff;
         break;
    ...
    }
}


^^^
if you don't know how (some of your posts indicate you are new to coding) ... here is ONE way to set up states for things:
enum p2 {ground = 1, jump = 2, fly = 4, swim = 8}; //notice: these are powers of 2 from 2^0
uint64_t state = 0; //no state.
you can have 64 distinct states in one 64 bit integer, and combos as needed eg jump and onground can both be set.

then something like
state |= onground; //(if onground)
state &= fly; //or if fly. the & enforces mutex between flying and being on ground.
//you can ALSO implicitly get fly from !onground, but that does not fit well here
state |= jump; //not mutex, apparently you can jump and onground, but can you jump and fly (some games, this is yes!)
state &= swim; //again enforce mutex, cant swim if also flying or grounding... ?
//notice: above has no jump enabled logic, just assignments, but it IS logic and MUST be done correctly for YOUR real program. (that is get the ands and ors and all right!)

those are just examples. they will lead to the above switch off your state.. very clean if done correctly.
Last edited on
From the initial post:

Just want to know what do you think about this?


It is pretty much unanimous from the people you asked what they think about "this." Nobody here thinks "this" is a good idea.

If your purpose for posting was to get a rubber stamp from people here on your code, the here it is: RUBBER STAMP! Code on in peace.

If your purpose for posting was to learn best practices from experienced coders, then you should read and take to heart the feedback you got.

@dhayden and I both suggested state machines. It might be worth your while to learn about them.

A number of people here suggested that the possible benefits of spaghetti code are not anywhere near worth the headaches. Remember, we are experienced programmers who have been where you are now. Weigh that information as you consider our advice.
A rubber DUCK stamp

Let's hope @OP matures into a fantastic programmer.
to get a rubber stamp from people here on your code


Certainly - the REJECT stamp.
i have done state machines before, like simple character movement.
just found out about goto and was interested if it was better to use it.
sorry, but i still have a lot of questions and posting like this does not help.
is there a chat/discord or something like that?
nothing to do with you guys, i'm just bad at explaining i guess so maybe that would help.
Last edited on
Topic archived. No new replies allowed.
Pages: 12