This book is about better formalisms for game designers.  If you’re writing a computer game, you’re using formalisms.  Different formalisms have different strengths and weaknesses.  This book introduces ones you may find better for some of your tasks.

What, not how

Declarative programming is a collection of techniques and languages that allow designers to describe what a solution would look like without specifying how to find it.¹  The how part is taken care of by a generic program called a solver.

This book introduces those techniques with an emphasis on their application to game design, primarily video games. 

• Part I describes how to use declarative languages.  Most of it can be read by people with little or no programming experience.  Examples use a specific programming language called Step, but they are easily translated to other declarative languages. 
• Part II describes how to build your own solvers.  This section is much more technical and assumes you have a background equivalent to at least a year of university-level computer science courses. 
• Appendices provide background information or detailed discussion of topics that would divert from the flow of the main text.

Exoteric, not esoteric

This material is not difficult to understand.  However, it is traditionally taught in research monographs, conference papers or graduate computer-science textbooks.  These are esoteric in the literal sense of being written for a small group of experts.  This book is exoteric: it is written for a broad audience.  That said, I love the esoteric stuff too and have included it as additional material in optional marked sections clearly marked “esoteric.” These may be safely ignored if you aren't interested.

Audiences

I’ve tried to write for several different audiences, in increasing order of familiarity with technical computer science:

• Artists and designers with no programming background who want to experiment with story generation, interactive fiction, etc. Part I is self-contained enough for readers like these.  Just skip over the esoterica (or not!).
• Artists and designers who do have programming background, but whose primary role is not programming, but who would like to understand and experiment with the technology.
• Undergraduates taking a course on declarative programming, logic programming, and/or constraint satisfaction.  Both Part I and Part II should be readable by CS students who’ve completed their first year, although those earlier in their careers may need to rely more on the appendices.
• Game AI or gameplay programmers in the game industry looking to incorporate declarative techniques into their games or scripting languages.
• Ph.D. students looking to build on these methods.  These students may also want to be familiar with the parts marked “esoteric.”

How to read this book

If you are reading this as part of a course, then your instructor will be telling you what parts to read.  It’s safe to assume you can ignore the other parts.

If you are in the game industry, I recommend starting by at least skimming Part I to get a sense of whether any of this is going to solve the problems you came here for.  If so, you can either use the solvers used in Part I (they’re on github), or read Part II to learn how to build your own solvers or otherwise incorporate these algorithms into your tool chain.

If you’re a Ph.D. student, you should read both sections as well as the mathematical appendices.  You may never need to use that knowledge, but you should be able to at least nod knowingly when asked about it in job interviews.

What to ignore

This book has five kinds of pages or sections of pages:

• Regular pages should be readable by anyone
• Pages marked omake are optional “bonus” content that can be read or skipped as you like.
• Pages marked technical assume you have a computer science background.  Skip them if you don't or if you otherwise aren't interested in the technical CS.
• Paged marked esoteric are more nerdly things that hyper-technical and/or academic.  Read them if you find them interesting, but they're completely unnecessary to understanding the rest of the book, including the technical sections.
• Background appendices review material assumed in the technical sections, or provide optional deeper background that gives context to the other pages.

The two parts of the book can be read independently of one another.  Each part is intended to be read from its beginning, but I’ve done my best to make it possible to read chapters à la carte whenever possible.

I wish I could make it so you could read Part I without having to learn Step, but we have to use some programming language and Step has a much gentler learning curve than Prolog.

Notes