1. Flirting With The Dark Side Domain Specific Languages and AI

2. Flirting With The Dark Side What is a Domain Specific Language? Why are DSLs useful for AI? How do we build and deploy a DSL? Who benefits from this? Concluding wisdom

3. What is a DSL? A Domain-Specific Language is simply a language designed to be highly adept at solving a specific class of problems

4. The Continuum GenericSpecific C C++ Mathematica Java Lua SQL Ruby UnrealScript XSLT PythonRegular Expressions JavaScript Lisp YACC ErlangVerilog

5. What Do DSLs Look Like? if $Aim -> is of class Huge Ship if $distance > 3500 AND $distance < 20000 if [THIS] -> fire missile $Missile on $Aim $Missilesfired.strength = $Missilesfired.strength + $Damage [THIS] -> set fire missile time difference to 16 ms $defend = random value from $Value.def2.min to $Value.def2.max - 1 [THIS] -> interrupt with script '!plugin.fightcommand.defmove' and prio $Prio: arg1=$defend arg2=$Aim arg3=null arg4=null gosub Defensive.Definitions end

6. What Do DSLs Look Like? <camera_find fillspace="50" lookat_reference="@playership“ position_reference="@playership">

7. Language or File Format? DSLs resemble declarative file formats However, DSLs are typically imperative Nothing wrong with a declarative DSL Can think of DSLs as “smart files”

8. Why Use DSLs for AI? Program code will be cleanest when implemented in the same terms that domain specialists use when thinking about problems in the domain Principle #1

9. Why Use DSLs for AI? We can minimize bugs by eliminating low-level concerns that do not directly apply to the problem we wish to solve Principle #2

10. Why Use DSLs for AI? We can maximize productivity by removing details and features that do not pertain to solving the problem Principle #3

11. Why Use DSLs for AI? AI work typically consists of solving a limited set of problems using a handful of well-known techniques Key Observation

12. Why Use DSLs for AI? Expresses concepts in domain terms Eliminates irrelevant lower-level concerns Limited features keep code focused Specialized tools are easier to develop

13. Avoiding Low Level Issues Escaping from C++/etc. gives us several perks No manual memory management No complex syntax No complications like undefined behavior

14. Avoiding Low Level Issues Escaping from C++/etc. gives us several perks Accessible for designers and junior coders Less likely to cause severe bugs in core code Can be radically more productive

15. Making Languages is Hard! Compilers are complicated! What about interpreters? Virtual machines? Garbage collection? Concurrency? Lexers? Parsers? Semantic analyzers? Abstract syntax trees? AST decoration? Optimization? Native code generation? The problems are endless!

16. Making Languages is Hard! Compilers are complicated! What about interpreters? Virtual machines? Garbage collection? Concurrency? Lexers? Parsers? Semantic analyzers? Abstract syntax trees? AST decoration? Optimization? Native code generation? The problems are endless!

17. DSLs Should Be Easy! We can put away the Dragon Book. We don’t need complex parsers, compilers, or virtual machines (We probably don’t even need regular expressions…)

18. Compilers, Be Gone! Syntax is often very simple Therefore, we don’t need complex parsing We can use existing file formats XML JSON Plain delimited text

19. Compilers, Be Gone! Execution of code need not be complex After all, the problem space is limited We can leverage existing data-driven code

20. Building a DSL for AI Hoist configuration data and logic out of core engine code and into the DSL This is essentially just data-driven programming taken to the next logical step Fundamental Goal

21. Building a DSL for AI We always want to do the simplest thing that can possibly work Guiding Principle

22. A DSL From Scratch Identify the core problems our AI must solve Select algorithms and solutions for each Break down solutions into discrete chunks Implement DSL concepts for each chunk

23. Identifying Core Problems Pathfinding Responding to dynamic game situations Anticipating dynamic game situations Planning/behavior selection Achieving specific game design goals

24. Selecting Solutions Choose the options that we would normally implement directly, as the design and specifications require Guiding Principle

25. Breaking Down the Solutions Identify common concerns and issues Determine required decision-making logic Look for branch points Branches are ideal spots for DSL placement

26. Concepts and Languages Typically, when control flow can branch in AI code, this represents a point where a domain-specific concept has come into play; therefore the presence of branches tends to suggest the application of domain-specific logic Control Branches

27. Concepts as Syntax Pathfinding: find_path Reading state: get_player_shields Reasoning: select_enemy_target Changing state: set_unit_armor Computation: calculate_damage

28. Granularity It is important to get granularity right Too fine and we have a general language Too coarse and we don’t accomplish much This depends a lot on the individual game

29. Granularity Many concepts can be implicitly constructed Behavior trees State machines (simple and hierarchical) Utility-based decision making Smart objects Blackboards

30. Implementation Keep syntax simple and clean Or use existing file formats like XML or JSON Deploy simple code (or library) for parsing Map syntax elements to constants or classes Execute the DSL code in some fashion

31. Clean Syntax Should be able to parse very, very easily No complex grammars/regular expressions If we need rich syntax, consider XML/JSON Comma or space delimited fields work great Prefer specific operations to generic ones

32. Clean Syntax Bad: player.health -= weapon.get_damage(); Good: damage player with weapon Vastly easier to parse Maps directly to the appropriate concept Minimizes potential for bugs due to focus

33. Minimal Syntax, Maximum Power

34. Executing DSL Logic Build a miniature interpreter Embed the DSL in C++, Lua, etc. Compile to another language Compile to native code (scary!) Various Options

35. Embedded DSLs Implement using underlying language DSL concepts become functions or classes Benefit: doesn’t require custom tool chain Cost: reintroduces low-level concerns Cost: doesn’t separate AI logic from core

36. Converting Existing AI Code Start by making implementation data-driven Identify logic that can be grouped into DSL Factor out existing logic temporarily Implement chunks of DSL to replace code

37. So Who Benefits? Programmers have a safer environment Junior team members can do critical AI work Designers can write logic directly Code reviewers have a much simpler job Fast turnaround from QA/automatic testing

38. So Who Benefits? Basically everyone wins when DSLs are done carefully

39. Some Brief Tips We can’t depend on realtime execution Splitting AI DSL onto a thread is usually best Minimize direct interaction with game state Respond to events and queue tasks instead

40. Some Brief Tips Put low-level logic in low-level code Design the DSL for non-realtime execution Excess flow control in the DSL is risky It may make sense to deploy multiple DSLs

41. Flirting With The Dark Side Code is cleanest when it maps directly to the problem DSLs are a superb way to achieve this Implementing a DSL can be easy and rewarding http://members.gamedev.net/bag-of-holding/gdc.html