Me going on about FSM's in #bbg

gistfile1.txt

<Hotroot> Is anyone on?
<Hotroot> More specifically anyone who knows anything about writing bbg "frameworks" for the easy creation of similar games?
<dariusk> what do you mean by that? I've contributed to the Akihabara framework
<Hotroot> I was thinking about a mystery game where you would travel from room to room in X location, talk to witnesses, present evidence to them (ala Phoenix Wright) and ask them various questions.
<Hotroot> Their testimony could change based on presented evidence, etc.
<Hotroot> Considering how similar all the "levels" in a game like that would be, I think a framework would be the best way to go
* PotHix (~pothix@2804:218:0:2001:a6ba:dbff:fe05:6ef9) has joined #bbg
<Hotroot> It would use lots of OO. Like Janitor = new Witness() and then you assign the different dialog trees he presents, etc.
<dariusk> this may seem counterintuitive, but I would not be worried about the framework for the game itself so much as I'd be worried about building the UI
<Hotroot> The different "levels" would change so little, I wouldn't bother unless I was going to make an easily reusable framework
<dariusk> I mean, yes, build a framework
<Hotroot> Why the UI? Just a background image, and some image placements of evidence, people, etc.
<Hotroot> No animation
<dariusk> is there dialogue?
<Hotroot> Some room to room stuff that can be done via ID tag links and a container div
<Hotroot> Yeah, text dialog
<Hotroot> That would be part of the framework of course. Just simple "popup" type stuff (not an actual popup, just a text bubble with a higher Z-index)
<dariusk> okay, sure. so what did you need help with?
<Hotroot> Well I'm clueless when it comes to framework stuff like that
<Hotroot> I mean I have no idea how I would go about it at all
<Hotroot> I suppose it would be a JS file you include? Possibly even a WYSIWYG creator of sorts though.
<dariusk> well, one thing you can do is look at existing frameworks
<dariusk> that's how I learned to build frameworks and game engines, by using and contributing to open source ones
* jimmysparkle (~jimmyspar@213.249.131.13) has joined #bbg
<Hotroot> I would want one specifically tailored to this though. Very few separate things it would need to do
<Hotroot> Oh
<dariusk> okay but you have to design it yourself
<Hotroot> I see what you mean
<dariusk> yeah. see how other frameworks do their thing, learn them inside and out, and then you'll be ready to take your first crack at building your own framework
<dariusk> have you ever built a game before?
<Hotroot> I haven't finished a full game, no
<Hotroot> I sort of have the basics down for an upgraded drugwar clone I'm making though
<Hotroot> So in other words, no, I'm not a pro. I'm also not one of those 10 year olds who stumbles into IRC and wants to create an MMO with no coding experience.
* yogurt_truck (~coding_ob@190.191.221.231) has joined #bbg
<dariusk> okay, so: it's going to be hard. there's no guide or specific advice that can help you
<dariusk> I recommend reading books on game engine architecture, but even those won't help too much
<dariusk> the best thing is to take apart existing frameworks and see how they work. fork a framework like Akihabara on github and try and modify it to do what you want
<Hotroot> I hope it will be slightly easier since I don't really need an "engine" though
<dariusk> well, think about what your game needs and try and abstract it
<Hotroot> I mean regular DOM stuff can handle room changes and witness placement, onclick, state, etc.
<Hotroot> I suppose in essence I need Witness creation, Evidence creation, the state changes those two can cause,
<dariusk> so here's a little concrete advice: use mary rose cook's machine.js for tracking state: https://github.com/maryrosecook/machinejs
<Hotroot> I do need to plan much more first though. Like how will you submit your answer? Will there be a court system, or do you only play the role of detective, etc.
<dariusk> yeah, sounds like you need to nail down your design more
<dariusk> but basically: proceed as piecemeal as you can
<dariusk> try to keep things modular
<dariusk> don't be afraid to throw things out if they're not working for you
<Hotroot> I have no idea what the last word of those two sentences mean =P
<Hotroot> Err, excluding the last post. I meant "Piecemeal" and "Modular"
<dariusk> proceed piece by piece
<dariusk> don't try to make the whole game at once
<Hotroot> I'm good at focusing on one thing at a time with this stuff =)
<dariusk> by modular I mean try and create general functionality that can be reused over and over in multiple parts of the game
<dariusk> have you built a finite state machine before?
<Hotroot> Forsure, that's the whole point of this framework. To be able to easily reuse so much of this.
<Hotroot> dariusk: Err, no
<dariusk> okay: read up on finite state machines and specifically how they're used in games
<dariusk> it's going to be a HUUUGE help for you down the line
<Hotroot> Oh wait, maybe
<Hotroot> Lemme check this wikipedia page
<dariusk> http://www.gamedev.net/blog/802/entry-2217738-system-design----finite-state-machines/
<Hotroot> Oh yeah, I know about state
<Hotroot> I have a telnet chat server that uses state for everything
<dariusk> right, but have you designed a state machine with transitions and formal structure?
<dariusk> because there's a difference between keeping a list of flags and actually having a state machine
<dariusk> a state machine gives you a super ordered way to keep track of everything from game behavior to menu progression
<Hotroot> This was basically flags =3 "State = "loggedin" etc.
<Hotroot> brb
* _gb (~gb@207.180.172.8) has joined #bbg
<Hotroot> back
* yeassay (~fglesser@mail.odd1.net) has joined #bbg
<Hotroot> Err, that page is odd
<Hotroot> Why would you use state for a vending machine?
<dariusk> that's actually how vending machines are designed
<dariusk> (or were for a long time, now they have computers)
<dariusk> it's a slightly out of date illustrative example
<Hotroot> I would just have a coinInput event/function, that decides what coin was entered, and updates the "credit" variable by X amount
<dariusk> except in the 70s and 80s it was too expensive to put an arithmetic logic chip in a vending machine
<dariusk> so we used state machines instead
<Hotroot> Ah
<dariusk> anyway, bad example
<dariusk> better example would be basic game flow control
<dariusk> for example: let's say you're making an Advance Wars type game
<Hotroot> I know almost nothing about that game
<Hotroot> I played it for 10 minutes and was excessively bored
<dariusk> okay but you understand that there's two teams, and they take turns moving units around
<Hotroot> Yep
<dariusk> so, you want to track state on several levels
<dariusk> at the lowest level is the state of an individual unit
<dariusk> every unit has a few states: unselected, selected, animating (moving), attacking, done
<Hotroot> Yeah
<dariusk> at the start of a turn, every unit is in the unselected state; if the unit is in the unselected state, it can't do anything until you select  it, and then it's in the selected state
<BBG> [html5GDs] Rekapi – A keyframe animation tool for JavaScript ( http://feedproxy.google.com/~r/html5gamedevs/ILWu/~3/W9Fb6p-m44I/ )
* robbrit (~rob@38.108.76.250) has joined #bbg
<dariusk> from there it can transition to either moving OR attacking
<dariusk> depending on the game rules you've designed, of course
<dariusk> anyway -- then there's the turn-level state
<dariusk> you want to track whose turn it is, which is a simple state machine. you could handle it with a flag, but if you later wanted to add a three player or four player mode, building it as a state machine will help you immensely
<dariusk> and on the high level there's the state of the game itself
<dariusk> so when the game starts you're in the title screen state
<dariusk> then when the player presses any key, they're in the main menu state
<dariusk> then maybe if you press "new game" you go to the "cinematic" state
<Hotroot> You
<dariusk> the point is that SM's are very very flexible
<Hotroot> You're talking variable assignment though, right? gameState = "Menu";  etc?
<dariusk> yes
* andrewjbaker needs to work an FSM into the Hence compiler...
<Hotroot> Alright, just making sure I'm not on a completely different page, lol
* hughfdjackson (~hughfdjac@host86-182-24-20.range86-182.btcentralplus.com) has joined #bbg
<dariusk> but tracking state isn't the hard part
<Hotroot> So far this sounds a lot like what I did with my telnet chat server
<dariusk> it's managing the transitions (which also isn't HARD, but it's the important, nontrivial part)
* waynegraham (~Adium@d-128-197-167.bootp.Virginia.EDU) has joined #bbg
<dariusk> basically you just need to settle on a pattern for your FSM
<dariusk> and again, I recommend using Mary Rose Cook's machine.js that I linked earlier
<dariusk> although it might be too complicated for your needs
<dariusk> I often just use a switch/case statement
<Hotroot> Sounds good
<dariusk> anyway, I should probably work and stuff, hope that helped
<Hotroot> Yeah, I'm figuring any premade framework is going to be far more advanced than I need
<Hotroot> But I will check the machinejs link, thanks =)
<chmood> dariusk, thanks for the lesson :p
<Vennril> dariusk, that was a nice explanation
<dariusk> thanks chmood Vennril 
<Hotroot> The problem is, how would I do multiple states for one person, say if one witnesses' dialogue could be changed multiple times via different pieces of evidence. Would I have state = "evidence1"  and state = "evidence2" and state = "both" or would it be better to have a state for both evidence 1 and two (eg evidence1state = "true" (or false))
<dariusk> no, that you would not track with states, that could get ridiculous
<dariusk> you would just have a "dialogue" state, and inside that state, evaluate the evidence and say the thing you want
<Hotroot> So a custom dialogue function for each person?
<dariusk> technically you could go wild write an entire game as an FSM, down to the movement: your state could be "x100y100" and then if the player presses right you transition to the state "x101y100", and update the draw
<dariusk> but that would be ridiculous :)
<dariusk> yeah
<Hotroot> I could OO the shit out of it, and have a dialogue function for each witness object, and then have attributes on each witness like "Evidence1Presented = true;" that their dialogue function checks for
<dariusk> yup
<Hotroot> Maybe some sort of array of dialogue options
<dariusk> well, does "presented" mean you presented the evidence to that witness, or just that it was presented at all in the court?
<Hotroot> I'll have to brainstorm and draw it all out on paper, thanks =)
<Hotroot> That you presented that evidence to the person
<dariusk> ok then, yeah