Perl + pathfinder == <3
- 1. Perl + Pathfinder = <3 apeiron apeiron@cpan.org YAPC::NA::2012
- 2. What's This About? Having fun RPGs are fun Perl is fun How can we use one to make the other more fun?
- 3. RPGs I like tabletop RPGs and will play most systems However, running combats takes too much time and effort I want to pay attention to my players, not logistics
- 4. Perl Perl is really, really good at automating things RPG combats are simple and defined by deterministic states Don't we have something to handle deterministic states?
- 5. FSA Finite State Automaton Huh? An FSA is a set of rules defining each state and how to move to other states
- 6. FSAs, Cont'd An FSA models a system that moves from one state to the next by a specific, limited set of rules Given an initial state and some data, you can tell which state you'll end up in ... and where to go from there
- 7. Yet More FSAs FSAs have multiple possible destination states when transitioning Each transition is tested; the first one that's true is the destination state Order transitions by priority
- 8. Perl + RPGs == <3 So, what do we have here? A way of keeping track of whose turn it is in an RPG combat, and some other small things like condition expirations Note that only the Pathfinder/d20 system uses FSA::Engine; it's not a requirement
- 9. What Isn't It? It doesn't track creature health It doesn't record what actions one takes It's not a virtual tabletop It does not replace the GM Complete or pretty (right now)
- 10. What Is It? It tracks who goes when It tracks simple statuses ... and if a status precludes someone from acting, it skips them That's it Anything more is a bug
- 11. Why Is It? Every other tool does too much (Almost) Every other tool needs Windows Every other tool requires a GUI
- 12. Why an FSA? Why not just use a REPL and some variables? Let's think about how RPG combats work The model fits really well
- 13. Why an FSA? What happens in an RPG combat? Different creatures take their turns The order matters but what that order is doesn't There's some state that affects who does what when
- 14. Why an FSA? Turns are grouped into rounds, rounds are grouped into a combat Loop over the combatants' turns every round until there's no combatants from one side left Every step of the way is determined by the state of the system at the time
- 15. Why an FSA? Therefore, we need something that moves from one of a finite list of states to another based upon the existing state It turns out FSAs are really good at that
- 16. Automata in Perl We've got a few automata in Perl: POE::NFA FSA::Rules FSA::Engine
- 17. FSA::Engine Moose role Adds some attributes and methods These attributes and methods control the automaton The docs are good, I won't repeat them here
- 18. Using FSA::Engine It's a Moose role, so you compose it into your class as you would any other role Then there are some attributes and methods you need to write which tell the FSA how to transition states Really easy, seriously
- 19. The App Itself It's simple, really Start it, it asks for a list of combatants (PCs and NPCs) Then it runs a combat until one side wins
- 20. Poking Under The Cover Each different game system is supported by a ruleset class This ruleset class is actually the brain of the app It determines who goes when and most everything else
- 21. But... What if a player changes their mind?
- 22. Undo Support When thinking about this feature, I investigated various undo frameworks on CPAN They do what they say on the tin... ... but they require me to write lots of boring code Isn't there an easier way?
- 23. Undo Support It turns out there is The FSA runs various coderefs to determine which state to advance to These coderefs use attributes and variables in scope for the transition subs
- 24. Therefore... All we need for undo support is to find a way to snapshot the object attributes and lexicals and a way to roll back that to that snapshot and then tell the state machine to go to the next state
- 25. The Magic The trick here is realizing that it's not really undo that we need It's just moving the FSA to another state If we can fake that, then it doesn't really matter that it's fake undo
- 26. How? If this was just package variables it'd be easy But it's modern Perl and that means lexicals Thankfully, Perl is awesome We have tools for that, like PadWalker
- 27. PadWalker? Every so often, take a snapshot of the lexical pad Push it onto a stack When requested, unwind the stack, tell the FSA to go to the next state Undo support!
- 28. But... It *is* a bit of a hack It's simple But it's cheating Patches welcome
- 29. Future Directions Other RPG systems Serialize state to disk for resuming sessions later Add support for holding/delaying actions and other things of that sort
- 30. Questions? Code is on github at http://bit.ly/LlqIcR Slides at http://slidesha.re/LSTqT4
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: I love the flexibility offered by tabletop RPGs. When we involve a computer in gaming, the limitations of the technology impose limitations on what we can do in the game world. This code was designed specifically to be as minimal and lightweight as possible so as to not restrict what people can do in the game world.\n
- #11: This application is more defined by what it does not do than by what it does do. Small is beautiful. Less is more. Just as describing something limits it, providing scaffolding and mechanism in a computer program limits what one can do to what the program can do. This is very much a philosophical decision for this application.\n
- #12: I want the freedom to let my players do whatever they want. This means leaving things simple and light. I don't run Windows. It's not an option. I'm a minimalist and I love Unix. Seriously. I live in a terminal all day every day. I have about 50 panes in tmux across all the machines I have logins on. Each one has a purpose. Text is beautiful. Go read ESR's Art of Unix Programming and replace all the jibes at Perl with 'fnord'.\n
- #13: \n
- #14: This is a simplified model, of course, which doesn't account for environmental hazards or other more creative things. It also glosses over the ways different RPG systems \n
- #15: \n
- #16: \n
- #17: POE::NFA is not really what I want; my use case is very deterministic.\nFSA::Rules, well, frankly I'm not sure how I missed it. metacpan bug maybe? I very probably would have used this if I knew about it.\nFSA::Engine is a Moose role that adds FSA capabilities to a class. It's also what we'll be talking about today.\n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: There's a lot left to do here, but the basic groundwork is laid and can be built upon.\n
- #31: \n