Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Program Layout, Menus and GameOver

Author
Message
Crazy Programmer
AGK Developer
20
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Lost in AGK
Posted: 17th Feb 2015 22:24 Edited at: 17th Feb 2015 23:16
I have been stuck on this for 3 days now so im finally going to ask.
What I am trying to do is end my game, Show the score, and back to menu.
Here is what I am trying to do.

Menu -> LoadGame -> gameloop ---- GameOver -> ShowScore and back to menu.

I have tried using gosubs and functions. I am just having trouble understanding how to call them / use properly.

So what I have tried is.



I have never seen an example with 2 loops but this is the only way I know as of now to load the static objects after menu().
I don't think Im anywhere close to being right on how to do this.\

When this runs it goes to menu and once you click it starts LoadGame() as soon as you die it goes back to menu but does not display menu images only the text with LoadGame() Still running. And once you click it starts LoadGame() all over but does not delete the existing game. Its running 2 games on top of each other it seems like. the old sprites are static no longer moving and just stuck on screen.

I have bought Daniels eBook and spent the whole day reading about gosubs and functions it only explained the very basics and its hard to find his examples of menu on my small kindle.

If anyone could shed some light on this matter I would much appreciate it.
It has had me stumped for a few days now

Some More code...This is an old project im using it as an example of whats happening.



Edit: Im not asking you to rewrite this code. Just a simple explanation would be fine.
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 17th Feb 2015 23:41 Edited at: 17th Feb 2015 23:42
This is how I structure all of my apps...



I believe this is called a state machine. Basically 'CaseSelect' stores the current state of the application, and runs the corresponding functions (TitleScreen, MainMenu, Game etc etc). I then change the state based on user inputs...

Run the above code and tap to progress through the different states... I added the GameOver piece and a score as an example.

If anything doesn't make sense, feel free to ask. I hope this helps...

Using AppGameKit V2 Tier 1
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 17th Feb 2015 23:44
Here's a sample of the sort of thing I think you are trying to do. I have broken it up into three completely seperate bits - the menu, a silly game, and the end screen. Hope this helps

Crazy Programmer
AGK Developer
20
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Lost in AGK
Posted: 18th Feb 2015 01:09
Thanks guys...I knew it was something I should have understood.
Now its clear as day. I should have asked sooner. I just knew I was going to facepalm when I got the answer. Was trying to put it off for as long as I could hoping to figure it out myself.

That's how I learn. I gota fail 100 times before it sticks

@Funnell - That's exactly what I was trying to do.
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 18th Feb 2015 11:26
The samples bundled with AppGameKit are a great help for this kind of thing. Take a look at SantasBadElf for a good example of a multi-file state machine (look in gameloop.agk for the state management code).

V2 T1 (Mostly)
Uzmadesign
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 18th Feb 2015 12:08
But remember AGKs big advantage; unlike most other dev systems you don't need state machines to manage basic transitions - you can modularise it.
unlikely
12
Years of Service
User Offline
Joined: 5th Mar 2012
Location: Ohio, USA
Posted: 18th Feb 2015 16:12 Edited at: 18th Feb 2015 16:14
That's true, as long as you call Sync(), you can have multiple "game loops" in separate functions--perfectly fine. In my opinion, that is much more simple than doing a single game loop with state machine functionality to branch tasks depending on state.

Using AppGameKit v2 T1 + T2
Systems: Primary: Mac OS X 10.10
Secondary: Windows 7
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Feb 2015 17:38
It's one of those areas that divides opinion, but there's no right or wrong answer. I never use use multiple syncs, my mind doesn't work well that way .

I use FSM with a SELECT / CASE statement, to keep everything indented at the right levels and to make it really easy to reorder. With an FSM, you should put your most frequently called routines at the top. Keeping them in order of execution is the most common mistake when switching to this kind of layout.

Quidquid latine dictum sit, altum sonatur
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 18th Feb 2015 17:54
All programs are a finite state machine. It's just an argument about how you implement them!

Onwards and sometimes upwards
Jambo B
15
Years of Service
User Offline
Joined: 17th Sep 2009
Location: The Pit
Posted: 18th Feb 2015 19:37
I agree with BatVink:

Quote: "It's one of those areas that divides opinion, but there's no right or wrong answer. I never use use multiple syncs, my mind doesn't work well that way .

I use FSM with a SELECT / CASE statement, to keep everything indented at the right levels and to make it really easy to reorder. With an FSM, you should put your most frequently called routines at the top. Keeping them in order of execution is the most common mistake when switching to this kind of layout."


This is an advantage if using timer-based movement. The calculations for how far to move sprites can be done each frame at the start of the main loop. One calculation that all the units/functions can use:

I use:



...at the start of the main loop. I've found that this smooths the movement and avoids 'stuttering' as the app gets more or less processor time.

James
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Feb 2015 22:39 Edited at: 18th Feb 2015 22:40
Quote: "All programs are a finite state machine. It's just an argument about how you implement them!"


My programs dedicate variables to the states, so you could say I'm coding in the style of an FSM, rather than inheriting it by default. If you don't consciously do it, then I don't think you're taking advantage of a neat way to program procedurally.

In a similar way, I like to put a cat amongst the pigeons by saying that all programs - including OOP - are procedural But that discussion will take this thread way off topic!

Quidquid latine dictum sit, altum sonatur
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 18th Feb 2015 23:31
Quote: " But that discussion will take this thread way off topic!"


No comment...

Onwards and sometimes upwards
Crazy Programmer
AGK Developer
20
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Lost in AGK
Posted: 19th Feb 2015 02:48
Quote: "No comment..."

Ill comment.
Your guys discussions are exactly what I was needing to read.
In the past all I have done is program in a straight line.
With out any breaks,returns,else statements. Mainly because I didn't know how.
This opens up my eyes giving me the general idea.
Sure I have seen examples but didn't understand what it was doing.
With Funells example. It was really an eye opener.
Now I can start on the right track
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 19th Feb 2015 08:43
I'd agree with FSMs in the main game loop. The thing that you lose is the FSM driving the menus, options screens, title screens etc etc etc.

If you look at (say) Coronas scene transition/management stuff, it's horrible and error prone. AGK2 allows you to do it in a module and avoid clutter, and keep explicit FSMs (for Jim !) for where they are actually needed.

You can write all programs using subtract and branch if negative instructions. (Someone did actually create a hardware machine that did this).
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 19th Feb 2015 10:25
This is where OOP really comes into its own.

AGK for Pascal has a fundamental "scene" object - TAGKScene. Each "scene" you sub-class from this has its own loop handlers. You can then switch scenes with one statement.

For example, your main menu is a "scene" - any time you want to go back to it you switch from (say) your completed level to that or another menu.

There is no vast case statement needing to be parsed in a main loop. Case statements are highly dependent on the efficient of the compiler and run-time system. Big ones can become very hard to read and debug!

Onwards and sometimes upwards
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 19th Feb 2015 18:23
I've written a couple of similar systems.

Login to post a reply

Server time is: 2024-11-25 18:01:10
Your offset time is: 2024-11-25 18:01:10