A cursed problem is a problem that contains a contradictory set of goals. In this discussion paper, we discuss the trials and tribulations behind trying to create a language for social simulation aimed at a casual (or at least non-programmer) audience, while also still appealing to ourselves and other more expert users.
In his 2019 GDC talk
In her dissertation
but in practice, these designs do not necessarily hold up,
or at least not for all circumstances and users. The free text
nature does lend itself more to being a little language that
could exist inside of a more general purpose system, but it is
not enough for it to be little. The natural language aspect
enhances readability, but it hurts writability (E.g., is “doesn’t
like” equivalent to “dislikes”?) in that natural language is
not a formal language (Graham Nelson notes in his 2019
Narrascope talk (Nelson) “that the benefits [of natural
language] are double-edged. But they are real.”). Finally, while
the simple simulation is closer to something that can be
updated and shown in real time to a user, in practice even the
simplest of simulations takes at least a few seconds to run for
long enough to show interesting emergent properties, which
is much slower than the fraction of a second for something
like procedural text generated by Tracery
In looking to improve this language, we sought the
feedback of a professional game designer. The designer notes
that “a good tool removes cognitive overhead from the
designer and puts that information directly in the tool, so that
the designer can keep more of their focus on high level
design goals and not get bogged down with lower level
concerns like syntax or data setup, or even just remember what
the system can or cannot do.” In discussing syntax, the
designer states “My philosophy is that I don’t ever want to
have to worry about syntax. If I am spending time on
syntax, then I’m not spending time on design. If you think of
it like Maslow’s hierarchy of needs, syntax is the ’am I
being fed and clothed?’ layer, and I want to work on the
’selfactualization’ layer where all the interesting design is
happening.” The designer has expressed an interest in the
language being entirely behind the scenes, with interaction
being handled via its own one-off graphical editor (a la the
non-public editor for Comme il Faut). However, this goes in
contrast with the other goals – Free text explicitly and
Natural Language implicitly (as there is no reason for natural
language when the language is hidden from the designer). This
also goes in contrast to the goals of other designers such as
Reed
This brings us back to the idea of a cursed problem – a problem (in this case design goals) that have opposing goals. Different users (the language authors, the non-programming game designer, and a social simulation expert) each have different features that are desirable (perhaps even necessary) for them. 1. Free Text – Important for the authors and expert. Unimportant for the designer. 2. Natural Language – Important for the author. Useful for the designer for readability, but a hindrance for writability.
Unimportant for the expert. 3. Simple Simulation – In some cases too complex for the designer and in others not rich enough. Not rich enough for the expert.
Perhaps there is some set of tooling and foldability that makes this Gordian knot cuttable, such that it is usable and interesting to both a non-(to-lite)-programmer and a social simulation expert, and that is what we would like to discuss.
We now note questions that we the authors have that we think can lead to good discussion: • Is this a cursed problem? • Is there a way to please all (most?) users across a wide range of programming comfort? (text editor for programmers, Scratch-like GUI for beginners, drop-down boxes for intermediate?) • Is there a way to please all (most?) users across a wide range of simulation desires? • What human-in-the-loop accessible feedback can be provided in real(ish) time for something that could take 5-100 seconds to generate?