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.

Newcomers AppGameKit Corner / Coding monster behaviour

Author
Message
trietias
9
Years of Service
User Offline
Joined: 20th Jul 2015
Location:
Posted: 17th Aug 2015 19:37
Link
Hi all,

I've been working with AppGameKit for about a month now, and usually use examples from the forums, other games, or the samples provided with AGK. This has been enough until now, but my next game is going to include a boss monster, and I just wanted to know how people typically code the behaviour for something like that. I couldn't find anything when I searched...

Would all of the monsters behaviours be encapsulated inside it's own function?

So something like

function MonsterBehaviour()
if energy = full
use fire breath
endif

if distance between monster and character <5
use claw attack
endif

if distance between monster and character > 5
Set monster x position closer to character
endif
endfunction


etc etc.

Would it be something like that? Where I just have a bunch of conditionals inside a single monster behaviour function?

Any insight would be much appreciated!

Thank you!
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 17th Aug 2015 23:06 Edited at: 17th Aug 2015 23:08
Link
I would use a State Machine. The monster is always in a specific state (WALK, IDLE, ATTACK, FLEE etc). Based on that state you run the associated code. Within that code the state can change to another state when certain conditions are met.

Here's a very simple example...



Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Back to top
Profile PM Email
trietias
9
Years of Service
User Offline
Joined: 20th Jul 2015
Location:
Posted: 18th Aug 2015 00:27
Link
Hi Batvink, thanks for the quick response!

If I'm already using a state machine for the general outline of my game, would using a nested one cause any problems?

For example, another game I was working on a few weeks ago was using nested SELECT statements:



Inside the nested select statement, I had to keep calling UpdateChar() and UpdateHUD() in each one, instead of putting it outside the select statement right after "Case 1:". It could have been because of the structure of my code that I had to do that, but is doing that something to be expected?
Back to top
Profile PM
JLMoondog
Moderator
15
Years of Service
User Offline
Joined: 18th Jan 2009
Location: Paradox
Posted: 18th Aug 2015 01:17 Edited at: 18th Aug 2015 01:19
Link
I try to avoid case statements, in my opinion I find them more cumbersome in a basic language. That's just my personal opinion! Don't take it as law lol.

But I agree with BatVink, you need to set it up so the boss has "state's".



Keep it simple and may I suggest using an extension file to program your boss's 'states' and conditions so you don't confuse yourself later in production.

Good luck!



http://jlmoondog.weebly.com/
Back to top
Profile PM Email Website
trietias
9
Years of Service
User Offline
Joined: 20th Jul 2015
Location:
Posted: 18th Aug 2015 01:35
Link
Thanks for the feedback! I'm playing around with the case statements right now, but I should put the monster's actions in another file haha.
Back to top
Profile PM
Uncle Martin
18
Years of Service
User Offline
Joined: 9th Jul 2006
Location: Tampa, Florida, USA
Posted: 18th Aug 2015 07:04
Link
@trietias
You can nest levels within state machines, as long as you have separate variables that keep track of the states & sub-states. I usually don't go beyond 2 levels.

For example, your monster could be idle, but is also pacing. So IDLE might be your state & PACING is your sub-state witin IDLE, as opposed to NAPPING sub-state.

Have fun.

Code every line like it might be your last...
Someday it will be.
Back to top
Profile PM
mrradd
9
Years of Service
User Offline
Joined: 24th Feb 2015
Location: CA, USA
Posted: 12th Sep 2015 00:59 Edited at: 12th Sep 2015 01:03
Link
The finite state machine idea is definitely the way to go (imo). At least from what I have seen/done in other utilities like Leadwerks or even modding Project Zomboid, they seem to use the same methodology.

I like to make a States type. This is used in other State "sub types" like my ActorState and GameState. These states are then utilized in the respective types I designed them for: actors, levels, menus etc. I then utilize several general flags in the form of Strings(which I define in globally in a Globals file) in an If Then Else thingy (like JLMoondog I prefer to stay away from cases in BASIC) which is encapsulated in each Actor type's agc file.

The only thing I am unsure of is how taxing it is for Tier 1 to go through so many conditionals every Loop cycle; especially when iterating through a bunch of assets.

-mrradd-
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 12th Sep 2015 01:36
Link
Quote: "The only thing I am unsure of is how taxing it is for Tier 1 to go through so many conditionals every Loop cycle; especially when iterating through a bunch of assets."


The SELECT statement drops out as soon as it hits the relevant CASE. So it is wise to put them in the most efficient order. For example, the chronological order might be:

GAMESTART
GAMEPLAY
GAMEEND

where GAMEPLAY accounts for 99% of the time. So the correct order for an efficient state machine would be:

GAMEPLAY
GAMESTART
GAMEEND

Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-21 14:55:12
Your offset time is: 2024-11-21 14:55:12