Interviewing PuzzleScripters

[Joe Osborn]

Hello!

I'm Joe Osborn, a Ph.D. student at the University of California, Santa Cruz. I work in a computer science lab called the Expressive Intelligence Studio ( http://eis.ucsc.edu ), where we—among other things—invent new technologies to enable new kinds of game experiences.

I'm currently researching what things people find difficult about making PuzzleScript games. Not (just) in terms of "using the tool" or even "translating a design to PuzzleScript"—more like "design problems encountered by puzzle game designers working within PuzzleScript". Hopefully, understanding these problems and how designers solve them could improve our knowledge of what game design is and how computers could help.

No matter what your level of experience is with game design or PuzzleScript in particular, if you are interested in talking to me about your design process with me I am interested in hearing about it. I'll be doing initial interviews within the next week or two, followed by some experiments and design challenges later in the summer to test hypotheses formed during the early interviews.

Please reply off-list if you'd like to participate, and let me know how proficient you are with PuzzleScript. I'd also love to hear any ideas you may have for improving the nuts and bolts mechanical processes of PuzzleScript game making--of course I have some thoughts of my own here, but I don't want to bias your responses

Feel free to pass this email along to other folks who might also be interested!

Thanks,
Joe

((More about me, if you're curious: I'm a game designer who became a computer scientist. I make tools to provide automated support for the iterative design process, including things like helpful visualizations, fancy debuggers (even "pre-debuggers" that can find errors before playing a game), automatic verification that a game design is sound or that a program correctly implements that design, and making game design suggestions.))

[willia...@gmail.com]

Hi Joe,

I would be happy to take part in your research/interviewing/challenges/experiments.
I am not that great at coding (in fact, rather horrible), but love designing puzzles/games.
I've only made a couple of puzzlescript games, most of which are quite glitchy (like I said, my coding is horrible).
My main gripe with puzzlescript is that fact that there are very little things that the coder has control of. There are no variables or functions (that I know of) and these are very useful for not only more complex mechanics but also tidying up code. Even something like snake is impossible to code in puzzlescript.
Then again, this forces users to be more creative with what they have.

I think that answers most of your questions for now.
If you could send me any more info/questions via email that would be great!

Thanks!

Will

[Stephen Lavelle]

>Even something like snake is impossible to code in puzzlescript.

sure you ca do snake - http://www.puzzlescript.net/play.html?p=7019377 - apples only appear in level 2

(someone's probably done a realtime actual snake game as well)

--
You received this message because you are subscribed to the Google Groups "PuzzleScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[willia...@gmail.com]

Thanks for showing me that, Stephen!
I am not smart enough to do things like that without variables :(. Thanks for the link to the game, the code was a very smart way to simulate the snake.

Although I still believe that it would be easier and/or tidier with variables and/or functions to do many complex mechanics, I see that smarter people than me can find a way around it! :)

[Christopher Wells]

In my opinion, the lack of variables and arithmetic is something you can work around. Puzzle games that actually involve numbers in the design are difficult or impossible to make, but then... there's lots of games like Sokoban or Chip's Challenge that aren't affected by that. Sure, it limits the design space, but so do things like having to use square grids, or 5x5 images. It's exactly like making a game for a game jam; the limitations inspire you in new ways.

What bugs me is the need to repeat yourself in the code. A lot.

There's lots of ways in different languages to stick by the Don't Repeat Yourself Principle. Copy-pasted blocks of code can be made into functions, defined once and then called multiple times. Slight differences between the copy-pasted blocks become parameters in the function call, usually emphasising important parts and explaining why the structure is the way it is. Or object-orientation that lets you call a Drawable.redraw() function without needing to worry whether you're drawing a simple circle or a bitmap image or something that won't be added to the code until years later. Whatever it is, you redrew it. No need to account for special cases every time you call the function.

Puzzlescript isn't good at that. There's no functions. There's object properties, but they're limited in what they can do. You can't, for example, have an object that can face in four different directions. You have four different objects, and where it's convenient you use an object property to unify them, but any time you have to depend on the direction it's facing, you need four copies of the code. No way to avoid repetition. Adding a way to specify objects as "facing in a direction" has been suggested, but I don't think that addresses the underlying problem.

For an example of what I'm talking about, look at the source of Beam Islands. There's sections of code like this:

[ BgNW1 Animate ] -> [ BgNW2 ]
[ BgNE1 Animate ] -> [ BgNE2 ]
[ BgSW1 Animate ] -> [ BgSW2 ]
[ BgSE1 Animate ] -> [ BgSE2 ]
[ BgNW2 Animate ] -> [ BgNW3 ]
[ BgNE2 Animate ] -> [ BgNE3 ]
[ BgSW2 Animate ] -> [ BgSW3 ]
[ BgSE2 Animate ] -> [ BgSE3 ]
[ BgNW3 Animate ] -> [ BgNW4 ]
[ BgNE3 Animate ] -> [ BgNE4 ]
[ BgSW3 Animate ] -> [ BgSW4 ]
[ BgSE3 Animate ] -> [ BgSE4 ]
[ BgNW4 Animate ] -> [ BgNW1 ]
[ BgNE4 Animate ] -> [ BgNE1 ]
[ BgSW4 Animate ] -> [ BgSW1 ]
[ BgSE4 Animate ] -> [ BgSE1 ]

, which really should be a one- or two-liner. It's just an animation loop. In Game Maker, this would be done with image_index += 1;, and other frameworks have something similar. But Puzzlescript has no way to specify an asymmetric relationship like "is the next animation frame" between two objects*, so we're forced to do structures like this. And there are many other repeated sections of code in Beam Islands, and similar games. It's a recipe for debugging nightmares.

Now, this only comes up with games above a certain complexity. And you can do a lot in Puzzlescript with not much; Sokoban with one line of rules code is amazing. Puzzlescript is excellent for prototyping simple games, with a small number of objects and behaviours, where the complexity arises from the interaction between them. The reason that complex games are difficult to write is the same reason that, for a while, they were impossible to write. I'm referring to the old limit of 32 objects and 6 layers. That limit came about because Stephen never thought anyone would seriously need to use that many objects.

And the reason for that is that Puzzlescript was not meant for complex programming.

Games with simple programming, it excels at. A game like Love and Pieces can be made playable in five minutes flat, and only needs the graphics and the level design after that (which doesn't take much longer). And that's amazing; I've never seen anything like it. Puzzlescript is simply a victim of its own success; people like using it so much that they use it for more and more advanced things. Things which it was not intended to do, not designed to do.

Anyway, I'm happy to participate in your interviews. I'm Christopher Wells, I made Singleton Traffic and It Dies In The Light and some other stuff that I haven't posted here.

*Note to self: This idea has potential. Get the Puzzlescript source and see if you can implement it.

[NiGHTcapD]

Technically, it's like Minecraft and redstone in certain aspects. Sure, you can make it with this, but it's much easier to do it on a program more suited for it. But the challenge exists, to show that "I built that. In Minecraft/Puzzlescript. It can do that." You can make complex programs, it's just that it's not meant for it.

Originally. I guess a reason that Puzzlescript works so well is that we can make games as simple as we want and it won't look lame, unfinished, unpolished or out of place, yet we can complicate matters for ourselves to make it that much more amazing.

I should probably shut up before I go on an essay-long rant. But I'm willing to take part in this, or at least some of it.

[Joe Osborn]

Thanks for all the replies, on- and off-list! I'm still looking for more participants, of course; I don't anticipate the interview will take more than ten or twenty minutes of your time, and I'll conduct it solely by email. Feel free to pass this around outside of this group, too!

Within the next couple of days, I'll be sending out preliminary questions (based on my own theoretical background and an exhaustive review of this group's post history) to two or three people to make sure that the questions are comprehensible; following that, I'll ask a refined set of questions to most or all of the remaining participants.

In the future, I'll be performing both long and short experiments, but I'll recruit separately for those.

When the interviews are done, I'll condense the results and report my findings to the group, in case anyone is interested.

Just to repeat my summons one more time:

I'm currently researching what things people find difficult about making PuzzleScript games. Not (just) in terms of "using the tool" or even "translating a design to PuzzleScript"—more like "design problems encountered by puzzle game designers working within PuzzleScript". Hopefully, understanding these problems and how designers solve them could improve our knowledge of what game design is and how computers could help. 

No matter what your level of experience is with game design or PuzzleScript in particular, if you are interested in talking to me about your design process with me I am interested in hearing about it. I'll be doing initial interviews within the next week or two, followed by some experiments and design challenges later in the summer to test hypotheses formed during the early interviews. 

Please reply off-list if you'd like to participate, and let me know how proficient you are with PuzzleScript.

Thanks very much—and talk to you soon!

Joe

[abrobecker]

Puzzle games that actually involve numbers in the design are difficult or impossible to make

Maybe difficult, not impossible!
The following implements Conway's Game Of Life in Puzzlescript, and since
the latter has been proved to be Turing complete, so is Puzzlescript!

This means every computer program can be written in Puzzlescript.
This does not mean everything can be easily written in it.
I tried to define Puzzlescript as a bidimensionnal finite state automaton with unidimensionnal transition rules,
it's not the standard algorithms that must be used (no loops, no easy access to variables...), and yes it's painfull
to do a simple counter, but it's nonetheless possible.

Writing a PS program is sometimes a Puzzle in itself, and that alone is funny to some people!

[Luckylucanos]

That is what I think is amazing with Puzzlespript. You could do it in another program but it is cool to be able to say "I did this in Puzzlespript"