Coding structure
Miscellaneous Forums/General Discussion/Coding structure
I'll be honest, the only real game making I have done before has been in K&P/CNC so to separate different screens (e.g. options/credits/actual game) its always been a case of just adding a new frame to the application.
So I am wondering, how do you usually go about coding different screens in an application and stringing them all together?
Cheers!
Just before you do a Flip, draw the differnt screen
(A bit brief I know, but true)
On select Flagwhichscreen
On case Gamescreen1 do gamescreen1()
On case GameScreen2 do GameScreen2()
on defalt do GameScreenAttract()
Flip
(EDIT: This isnt real code)
Cls
Select GameState
Case StateOptions
Case StateGame
...
End Select
Flip
That fits my needs.
@K
Thats exactly what I posted. You just copied me, you you code copyer you.
haha nice one thanks :)
thats what I was thinking too, which is reassuring
I use a string for gamestate rather than a numeric. It doesn't half help with debugging.
Apptitle "Game State:"+gamestate$+" Sub State:"+substate$
I use values like "title page" "intro screen" etc.
I use a string for gamestate rather than a numeric. It doesn't half help with debugging.
Is that not a rather slow thing to have for a main loop switch statement? It would force a number of slow string compares, would it not?
I doubt it (would be slow):
Graphics 640,480
Local gamestate:String[400]
For i = 0 Until gamestate.length
gamestate[i] = Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))+Chr(Rand(32,65))
Next
loop = 0
ms = MilliSecs()
Repeat
j:String = gamestate[Rand(gamestate.length-1)]
For i = 0 Until gamestate.length
If j = gamestate[i]
Exit
EndIf
loop :+ 1
Next
Until (MilliSecs()-ms)=>1000
Print "Approximately "+loop+" string compares in 1 second"
My machine does approximately 72552239 string compares in 1 second
>Is that not a rather slow thing to have for a main loop switch statement? It would force a number of slow string compares, would it not?
Eh? Once per frame is not slow. It would be absolutely trivial.
@John
I dont care if it would slow it down or not, a global int, set to Obviously named consts (We DO need enum) is just as good. (And definitly wouldnt slow it down)
BUT, I would be interested how it being a string helps with debuging. (Being that you have actualy finished things)
It helps because it's easy to display. Hence my apptitle example which is something I use quite often.
And of course its easier than defining a constant.
Const GS_TITLEPAGE=1
case GS_TITLEPAGE
is two lines
where
Case "title page"
is one.
I'm not trying to persuade anyone, I was just mentioning what I do and why.
@John,
I wasnt thinking you were disuadeing me from my method. But when it comes down to it, you do have an impressive list of finished products, so any advice that you give on the lines of
It doesn't half help with debugging
I'd be stupid, not to have asked you to alaberate. No?
I've explained twice already.
Apptitle gamestate$
Displays the game game state in readable form
Apptitle gamestate
Displays a number
@ John. I wasnt asking you to explain it again. I was just "sucking up" so that next time Im stuck you'll help ;)
Note To Self. Practice sycophanting
>Is that not a rather slow thing to have for a main loop switch statement? It would force a number of slow string compares, would it not?
Eh? Once per frame is not slow. It would be absolutely trivial.
Fair enough, though my understanding is that it would have to do one string compare for every case statement until it found one that satisfied it, in a massively cache-destroying way. Not that it matters for the 0.0001% of the time it spends doing it. :)
I dont care if it would slow it down or not, a global int, set to Obviously named consts (We DO need enum) is just as good.
Strings are type safe, ints are not. Sorry, you lose.
My framework uses an abstract TScreen type. Then sub-screens are extended from TScreen. Then a global type of TScreen called CurrentScreen is made and pointed to the first extended screen you want to show. CurrentScreen can be reassigned at any point. Each extended TScreen has its own logic and draw methods. The main game loop calls CurrentScreen.Logic() and CurrentScreen.Draw() which call the correct extended TScreen's methods via polymorphism. It's cool :-) of course you can't do this in BPlus or B3D as they are not OOP.
@Flame,
I obviously dont know what "Type safe" means, because I dont understand what you said, yet understand all the other words.
Can you explain. (And Im not sucking up to you)