Skip to content

#PROCJAM PuzzleScript + Tracery Tweaking the Content

I’ve not been doing lots of #PROCJAM, but I’ve been slightly tweaking things to make the generated scripts feel a bit more complete, and I think I’ll keep doing this during the rest of the jam, as it’s quite satisfying.

Today I added a bunch more names to the possible list for generating the author name (obviously the author needs to be generated, the person clicking the “GENERATE” button doesn’t deserve the credit ;-)).

I also split up the colour lists, so now the background and wall are dark colours, the player and target are regular colours and the “crates” (things you push) are light colours, so now the levels generated have a much better contrast. This is something I’ll tweak further and I hope to build a way of generating colours where relationship between the colours is generated too (i.e. the background could be light and the player dark, instead).

half-decent-gen

I’ve also been brainstorming ways of getting Tracery to produce levels with just 1 player, and also with the same number of targets and crates. Neither are super easy, and I think will require me to manually put in a bunch of permutations that it can select from. It’s not too bad as it is though, as the multiple player cursors makes it interesting to solve the puzzles, and as long as there are more targets than crates, then the win condition (All Crate1 on Target) can be met.

I’ve also been thinking about how I can determine whether the level generated can be solved, either to regenerate the level or even the whole game script. I came across this PuzzleScript solver, which I will try to integrate at some point. Given the game is essentially Sokoban at the moment, with some slightly varied block moving rules, I think there will be plenty of solver code out there I could utilise. I’d rather not write my own solver as this is a jam, though I could consider that option if necessary.

The current code for this can be found at https://github.com/rikkiprince/procjam-puzzlescript-tracery. I refactored it a little, so now it’s in a class called Generator.

The script for above “game”, in case you want it:

title Rule Generation
author Dr Cecil Le Guin MBE

========
OBJECTS
========

Background .
darkred

Wall *
darkgreen

Player P
orange
00000
00.00
00000
00...
00...

Crate1 C
lightbrown
00000
0....
0....
0....
00000

Crate2 D
lightblue

Target T
red
00000
..0..
..0..
..0..
..0..

=======
LEGEND
=======

=======
SOUNDS
=======

================
COLLISIONLAYERS
================

Background
Target
Player, Wall, Crate1, Crate2

======
RULES
======

[ > Player | Crate2 ] -> [ Player | > Crate2 ] (bump)
[ > Player | Crate1 ] -> [ Crate1 | Player ] (swap)

==============
WINCONDITIONS
==============

All Crate1 on Target

=======
LEVELS
=======

*********
*..T.TTP*
*...*..**
*P...CPT*
*TP.*..T*
*.C...TP*
*********

#PROCJAM PuzzleScript + Tracery Integrating the Editor

For the third year running I’m going to be continuing this #PROCJAM project! This time I’ve taken a couple of days off of work to further participate in the jam, so let’s see if I can avoid the distractions of being at home all day 😉

Looking back at last year’s blog posts, I left myself the note to work on integrating my Tracery-based generator into (a fork of) the PuzzleScript editor. While I do want to do some more thinking about how to generate rules and levels that interact nicely, I think putting my code into the PuzzleScript editor would be a nice starting point for this year. So here goes…!

integrated-with-puzzlescript-editor

Day 1’s work was a simple integration of the code I had last year with the PuzzleScript editor. Pretty straightforward, but a more direct way of demoing what I’ve been working on! Each click of GENERATE will fill the editor window with a complete and compilable PuzzleScript 😀

Integrated code of PuzzleScript + Tracery are sitting in my fork of the PuzzleScript code base: https://github.com/rikkiprince/PuzzleScript-Tracery

My next 2 tasks will be to work on the rule/level generation problem (potentially looking at some sort of validator for whether the rules and level work together), and fleshing out the content so some more interesting combinations of things get generated! Stay tuned 😎

New Year’s Day 2019 parkrun double finder

Welcome back to Year 6 of the New Year’s Day parkrun Double Finder list 🙂 Thanks to everyone that has supported, fed back and shared the Double Finder link! Please keep doing that, and spread the parkrun NYD double-love.

This year I just re-ran last year’s technology, which is why this is probably the earliest that double finder has been online! I rewrote the code that gathers information about which parkruns have a NYD event and what time it is at, partly because parkrun changed the format of that page, but also because the technology I used last year was overkill.

There is a new feature this year: sorting the list by distance from you. You can either type in the name of a town or leave the box empty to search by your current location. I also have the infrastructure to calculate which doubles are possible travelling by bicycle and public transit, but I need to figure out how to best present this information; watch this space!

The other news is that I now have a Twitter account for the Double Finder. Please follow it and share it with your parkrun friends! @nyddoublefinder

Click for parkrun double finder NYD 2019

As always, a reminder: This is not updated live, so event cancellations in the few days leading up to NYD might not be accounted for. Please check the social media (Twitter and Facebook) and website of the parkruns you intend to double at before setting out. I’d hate for you to be disappointed and miss a double! The good news is that if one of your intended events is cancelled, you have this great resource for finding an alternative 😀

Also, please double check the directions and driving/running/cycling/public transport travel time, and factor in time to get to and from your car. Make sure there is buffer time to allow for traffic and taking wrong turns. Make sure it is possible to travel safely! Please drive sensibly in bad weather conditions!

I hope you enjoy your New Year’s parkrun double. I am hoping to get a double in somewhere in the UK, and depending on how the next few weeks go, it may even be my 250th parkrun 😀 Have fun out there!

#PROCJAM PuzzleScript + Tracery Generating A Whole Script

After my last post, I started ruminating over what I actually wanted to achieve in this week of #PROCJAM. I realised that while I’m very interested in investigating mechanic generation, that’s quite an involved topic and #PROCJAM is only a jam! 🙂 I remembered that part of the aim of this jam project was to generate all the bits of a PuzzleScript using Tracery, so I spent a little time filling in the gaps.

The latest code is checked into Github.

All I really did was build a main Tracery rule that contained the general structure of a PuzzleScript (metadata, objects, collision layers, rules, win conditions, levels, etc.) then wrote some rules to generate some of the metadata (author name), objects (colour of the block), rules (see previous post), and the level (completely random, probably impossible to win, with a ~64% chance of a background tile and equal chance of being a player, crate or target).

The first Tracery-generated PuzzleScript had 3 players, 2 targets and no moveable blocks, so was not possible to complete 😀

It was quite satisfying to pull all the elements together, and be able to copy the entire script into the editor. Obviously it generates nonsense quite a lot of the time, so as the comment in my last post said, maybe what’s needed here is some utility function to determine if a generated game is “good” (for some value of “good”).

I would like to iterate on this, and refine the generation a little. It would be nice to find a way in Tracery to randomly pick from the bag without putting the value back in the bag (e.g. it would be nice to randomly select the player tile when creating levels, but not to be able to select the player tile 3 times!) It would also be good to find a way to create the same number of moveable crates as targets, but for the number selected to not be pre-determined. I’d also like to add some generation to some of the things that are currently static: collision layers, types/design of objects, win conditions and sounds.

However, I think the next thing I’ll try to do (and possibly the last part of this’s #PROCJAM) is to integrate with the PuzzleScript editor in some way. I’m not quite sure how I’ll do this, but I’m imagining adding a button to generate a script and replace the existing contents will be quite straightforward. Maybe I don’t even need the editor; I might be able to generate direct into the player.

#PROCJAM PuzzleScript + Tracery Selecting Predefined Rules

In 2017 I started a little project as part of #PROCJAM. The idea was to take Tracery, an engine for randomly generating pieces of text, based on a predefinied grammar for that text, and combine it with PuzzleScript, a markup language for 2D block-based puzzle games, and use Tracery to randomly generate new games in PuzzleScript.

Unfortunately, I didn’t really finish it, partly because I was job hunting and partly because I got a bit distracted by rewriting the parkrun NYD Double Finder. They’re not excuses, just parts of the narrative that make up this description. This year, as PROCJAM begins in 2018, I am enjoying my job as a software developer at Nureva, but have not yet updated the Double Finder for 2018 (I’ll move onto that after PROCJAM). As I have unfinished business with my Tracery-PuzzleScript generator, I am going to pick up where I left off and see how much further I can take it.

Last year I made some progress in investigating the rule structure of PuzzleScript, and put together a really small JavaScript demo using the Tracery library to generate 3 completely random, and because of that, near meaningless, rules! I posted about that last year and the code for that tiny demo is on GitHub.

As a starting point this year, I hope to bring some more meaning and sense to those rules. I think this will require some constraining of the possibility space, which feels like it removes a bit of the pure randomness of procedural generation, but equally I think picking the constraints is part of the art of creating a generator. After all, I already decided to scope this generator down to making block-moving, Sokoban-esque games.

I found in my working directory from last year a text file where I had brainstormed some player-block interactions that make some sort of sense in a block-moving puzzle game, and coded them up in PuzzleScript syntax (see below): push, bump, swap, block, opposite. There were a couple of others that were getting more wacky. There could also be more, so it might be worth me enumerating the possibility space, testing all the possibly rules and see if there are any others that make sense.

Brainstormed types of block-moving interaction:

[ > Player | Crate ] -> [ > Player | > Crate ] (push)
[ > Player | Crate ] -> [ Player | > Crate ] (bump)
[ > Player | Crate ] -> [ Crate | Player ] (swap)
[ > Player | Crate ] -> [ Player | Crate ] (block)
[ < Player | Crate ] -> [ < Player | > Crate ] (opposite)

Based on these potential interactions, I adjusted the Tracery grammar to generate a predefined rule for each type of block in the level (2 currently). My vision here is to generate a bunch of different types of blocks throughout a level, and each type will have a certain type of interaction (push, swap, bump, etc.) creating a puzzle where you have to figure out how to move each block type, then solve the level.

Example generated rules for the two types of block:

[ > Player | Badger ] -> [ Badger | Player ] (swap) 
[ > Player | Crate ] -> [ > Player | > Crate ] (push)

Swap Badger, Push Block

I’m not entirely sure this is where I eventually want to end up. With this approach I’m randomly selecting from predefined mechanics, and placing the blocks that use each of those mechanics in a level. That feels a bit too much like level generation rather than rule/mechanic generation. I guess to an extent it is system generation, as the combination of mechanics will be generated and could make something interesting. I would also like to loop back and see if I can do a bit more in terms of mechanic generation, rather than just selection, after I have a bit of a broader generator.

“Do Androids Dream of Electric Sheep?” by Philip K. Dick

Do Androids Dream of Electric Sheep?Do Androids Dream of Electric Sheep? by Philip K. Dick
My rating: 4 of 5 stars

This novel is one of Philip K. Dick’s most famous, and served as the inspiration for the movie Blade Runner. It is an accessible read, at just over 200 pages in length, with a high-paced but easy to follow adventure-thriller story.

I’ve watched the movie Blade Runner a couple of times, but have always found it a bit slow-moving and inscrutable. I even played a bit of the Blade Runner point-and-click adventure game in the late 90s, and all I remember is being so bored at its slow pace that I went to get a cup of tea while waiting for the avatar to amble painfully slowly across the rooftop parking lot, only to come back to find I’d been killed by an NPC that ambushed me. For me, reading the book was a far better experience than either of the film or the video game.

“Do Androids Dream of Electric Sheep” follows bounty hunter Rick Deckard in his mission to “retire” (read: kill) a number of rogue androids that have made it onto earth illegally. The post-apocalyptic future beautifully and concisely painted by Philip K. Dick manages to be at the same time familiar (set in San Francisco) and alien (most of humanity have moved to other planets after a disaster that killed most of the Earth’s animals). There are a couple of interesting sub-plots that run alongside and intertwined with Deckard’s adventure and his on-going self-reflection of his job and ability to do that job. Overall, the story resolves satisfactorily, though not as dramatically as I was expecting.

I enjoyed reading this a lot and would recommend it to any fan of science fiction, especially to anyone that has seen the Blade Runner movie. I will be following this up by re-watching the movie, from a new perspective. I don’t think I’ll be playing the video game again though!

View all my reviews

New Year’s Day 2018 parkrun double finder

It is the 5th year that I have generated the New Year’s Day parkrun Double Finder list 🙂 Thanks to everyone that has provided feedback about missing doubles and event cancellations over the years, I really do appreciate you taking the time to tell me!

This year I made some changes to the back end, which should speed up development of future features such as ordering the list by closest to your current location, and determining which doubles you can travel between by foot, bicycle or public transport. I’ve also added support for Australia, Ireland, New Zealand and South Africa.

Click for parkrun double finder NYD 2018

As always, a reminder: This is not updated live, so event cancellations in the few days leading up to NYD might not be accounted for. Please check the social media (Twitter and Facebook) and website of the parkruns you intend to double at before setting out. I’d hate for you to be disappointed and miss a double! The good news is that if one of your intended events is cancelled, you have this great resource for finding an alternative 😀

Also, please double check the directions and driving/running/cycling/public transport travel time, and factor in time to get to and from your car. Make sure there is buffer time to allow for traffic and taking wrong turns. Make sure it is possible to travel safely! Please drive sensibly in bad weather conditions!

I hope you Enjoy your New Year’s parkrun double. Unfortunately there’s not one possibly for me this year, as I’ve moved to live in Calgary. Instead I’ll be Run Directing the first New Year’s Day event at Nose Hill parkrun 🙂 Have fun out there!

parkruns closest together

I’m doing some work on making the parkrun New Year’s Day Double Finder a little easier to work with (for me) and a little more useful (for you, assuming you’re a parkrunner looking for a New Year’s Day double).

When running the script, I noticed a few of the driving time calculations coming back as zero. “Presumably I’m being rate limited by the Google Maps API”, I think to myself. Then it dawns on me: why am I requesting this information from Google Maps every time I run the script? The driving time between two places is relatively stable (and I’m going to disregard traffic in this instance, as the morning of 1st January is fairly quiet on the roads, and the scope of this tool is just to provide an estimate).

The sensible solution to this is to pre-calculate the distances and driving times between all parkruns, then my Double Finder script can just look it up as necessary. So that is what I am working on at the moment (aside from job hunting).

As I was working on this, I realised it made most sense to start by calculating the driving time between parkruns closest together, as they’re most likely to fall into the category of “possibly double locations” (presuming they are open on 1st January, and don’t choose to start at the same time). Having done this, I can now answer the question, “Which two parkruns are closest to each other?“:

Country parkrun parkrun Distance apart
gb Brighton & Hove Preston Park 1.68 km
gb Richmond Park Old Deer Park 1.69 km
gb Dulwich Peckham Rye 1.82 km
gb Stretford Sale Water 1.86 km
ie Father Collins Darndale 1.90 km
za Alberts Farm Westbury 1.99 km
au Broadbeach Waters Surfers Paradise 2.04 km
gb Brockwell Dulwich 2.06 km
gb Brighton & Hove Hove Promenade 2.13 km
ie Tymon Bushy Dublin 2.15 km

(Flag icons courtesy of https://github.com/hjnilsson/country-flags)

It turns out it’s a very close run contest between Brighton & Hove/Preston Park, and Richmond Park/Old Deer Park. In fact, all of the top 10 are quite close to each other, all less than 1 parkun (5km) away. (In fact there are currently 187 pairs of parkruns that are less than 5km apart).

These distances are “as the crow flies”, having been calculated using the haversine formula using the latitude and longitude of each of the parkruns, performed by a combination of a Python script and some SQL.

Hopefully that was some interesting parkrun trivia. As I’m working on the Double Finder, I’ll see if I can dig out some other tidbits. If there’s any stats you’re interested in knowing, why not post them in the comments below?

#PROCJAM PuzzleScript + Tracery Rules

In a previous post I spoke a little bit about the inspiration behind the thing I’m working on for #PROCJAM 2017. To summarise, I am taking a tool called Tracery, which lets you define grammars for text and generate random text from them, and attempting to use it to generate some code in a language called PuzzleScript, which makes 2D, Sokoban-style games.

PuzzleScript character definition

PuzzleScript has a nice little visual syntax for defining objects within the game, which could be a nice source of fun procedural content generation (PCG) using Tracery, but I feel like art and characters are quite commonly tackled problems in the PCG world. I am really intrigued by the idea of generating the rules that underpin a game or puzzle, to better understand the challenges of making those rules coherent and making levels suitable for those rules. So that’s what I’m going to attempt for #PROCJAM!

imag0031359827097.jpgOne of the things I asked my Masters student to do, when he was working on a similar sort of task, was to do a brief survey of existing PuzzleScript games to see the variety of rules that have been used by authors. From that work, he identified some categories, such as the basic push rule, position swapping, objects that slide, objects that attachgrow or chase the player. However, from reviewing this work and attempting a small survey myself, I realise the scale of the task! Not only are there over 90 games in the PuzzleScript gallery, but many have subverted the PuzzleScript form and created complex combinations of rules that have subtle and unique meanings in the context of that particular game. Whilst that is exciting, and perhaps a hint that making interesting PuzzleScript games requires more than just the basic types of rules, it also helps me scope what I want to do here. I am going to make this about exploring generation of rules for Sokoban-style, block-pushing puzzles and see where I get. After I have something working, it will hopefully give me some new questions regarding level-generation and how to combine rules that thematically fit together.

Rule Format

Screenshot 2017-11-09 15.42.24I spent a little time getting a boilerplate Tracery going. It’s here in this commit on Github. It took me a few minutes to realise there’s a Tracery2 branch, and that’s the right and stable version to use! The other trick I discovered was that to escape square brackets (which are pretty essential for PuzzleScript rules), you must use a double slash in Tracery: \\[ and \\].

For coming up with the range of possible rules I might try to generate, I brainstormed a little to come with potential variations. I also read the PuzzleScript documentation about rules and directions, which led me to realise that perhaps the right approach is to take the documented syntax and codify it in Tracery to generate a bunch of rules. This will certainly result in a set of rules that don’t interact in any sensible way, but let’s go with it and see what we get.

The generator at this commit generates 3 rules, mixed between the objects and handling different events in different ways for some randomly selected directions. For example:

(1) RIGHT [ Player | Crate ] -> [ DOWN Player | DOWN Crate ]
(2) LEFT [ UP Player | Badger ] -> [ LEFT Player | LEFT Badger ]
(3) UP [ RIGHT Player | Crate ] -> [ UP Player | UP Crate ]

 

I think the immediate lesson here is that whatever the player presses should be the direction the player moves in (but the collided block might do something different) (except maybe if the player is deflecting or bouncing off the block?) (yes that’s 3 bracketed thoughts in a row – where are my footnotes, WordPress?). I quite like that, once the system generates more rules, there can be a different rule  for each direction. Perhaps it should use Horizontal or Vertical, to have some consistency, but maybe not. I can imagine generating a rule where an object can be pushed in one direction, pulled in another, but nothing else. But of course we’re not here to think about specific instances 😉

Next I’m going to expand upon these rules a little bit, maybe come up with a few linked rules (i.e. if one rule does X, it’s combined with a rule that does Y), and have them as potential branches in the grammar. I would also quite like to integrate this into a fork of the PuzzleScript source, so that I can generate new rules from within the editor and not have to copy and paste them in!

#PROCJAM PuzzleScript + Tracery Inspiration

This week is #PROCJAM. This is a virtual event taking place around the world, 4th-13th November 2017. It’s a bit like a game jam, but what you make is some software (or other artefact) that generates something else: it might generate stories, it might generate artwork, it might generate characters or levels for a game, it might even generate a whole game. It’s not strictly game related, but a lot of the work tends back towards games 😄 Read more…