Thimbleweed Park Development Diary The development diary for Thimbleweed Park en Thu, 02 Jul 2020 05:01:04 -0400 Happy Two Year Anniversary Fri, 29 Mar 2019 12:22:00 -0400

Happy Second Thimbleversary, lovely Kickstarter backers and other Thimbleweed Park fan-a-renos.

It’s been two years since we launched Thimbleweed Park!

We’ve done so many things in that time, including:

    ▶︎ Launched on PC, Mac, Linux with Steam, GOG, Humble and Epic Games.
    ▶︎ Launched on Xbox One with Xbox Play Anywhere so you can switch between playing on your PC or Xbox.
    ▶︎ Launched on PS4 and Switch.
    ▶︎ Updated the game to include the much-loved in-game hint line system.
    ▶︎ Added playable arcade games.
    ▶︎ Released the Ransome Unbeeped DLC.
    ▶︎ Sent out physical rewards to all our backers, including 1012 signed big boxes.
    ▶︎ Launched big boxes for PC/Mac and PS4 and Switch, each with their own unique feelies.
    ▶︎ Created a great range of cool swag with Fangamer, including 4 T-shirts, the ViewTron, mugs, and a metal sign.

Fangamer has restocked the PC/Mac big box (for the third time!) and has a crazy deal where you can get the Cast-a-Reno shirt for just $10 when bought with a big box! They’ve also released a cassette tape version of the soundtrack – previously only available in the PS4 big box.

To celebrate two years of Thimbleweed Park, we’re doing something a bit special. We want to show our gratitude for coming with us on this strange journey to a pixelated world of adventures. We’re giving away rare physical swag. Including free shipping anywhere in the world!

Four lucky people will get a rare big box version of the game. They can choose whether they want the PC/Mac, PS4, or Switch big box version.

50 other lucky people will get one copy of the physical phonebook. Originally included in the sold out Switch big box, and only available via this prize drawing.

All you have to do is create an original tweet using the hashtag #visitThimbleweedPark. Tell everyone why they should spend some time in Thimbleweed Park. And if you haven’t been there, tell us why you’re keen to go.

Key Rules

    ▶︎ Tweet using the hashtag #visitThimbleweedPark by 9am (Pacific) April 2 2019.
    ▶︎ Your tweet must include a statement as to why people should #visitThimbleweedPark
    ▶︎ Don’t reply to our tweet, make your own tweet.
    ▶︎ Tweet must not be offensive or inappropriate (we reserve the right to judge this on an individual case).
    ▶︎ Don’t violate Twitter’s rules
        ▶︎ only one account per individual can be used to enter the contest. Anyone caught using multiple accounts to enter a contest will be ineligible.
        ▶︎ Maximum one tweet (entry) per day of the competition.
        ▶︎ Must be over 21 to enter.
    ▶︎ 4 randomly chosen people will win one big box of their choice (either PS4, Switch, or PC/Mac), including postage anywhere in the world.
    ▶︎ 50 randomly chosen people will receive a voucher to redeem on @fangamer for the physical phonebook, including postage to anywhere in the world.
    ▶︎ Winners will be drawn using Once chosen, winners will be checked for validity using above requirements.
    ▶︎ We’ll get in touch with winners via Twitter direct message with details on how to redeem your reward. You must respond within 48 hours to be eligible to get your reward, otherwise we’ll draw another winner.
    ▶︎ All winners will be notified by April 16 2019.

Locking It Down Thu, 26 Jul 2018 23:45:00 -0400

I’m locking comments on the blog.  It’s been a fun few years talking with everyone, but as the game enters it’s new phase of life (and it’s a strong one) most of the comments are now spam that I need to delete, or people asking questions that are better asked somewhere else.

If you have a support issue, please email support@thimbleweedpark or visit our forums at

Thanks to everyone for making our job and the game a lot more fun.

This Can Be Yours! Wed, 09 May 2018 13:12:00 -0400

Thimbleweed Park team member Emily Morganti has spent the last year making this amazing quilt featuring some of the memorable characters from Thimbleweed Park.

Rather than selling it and retiring to the Bahamas, she decided to sell it and donate 100% of the money to The Video Game History Foundation which works to preserve the history of video games.

– Ron

Thimbleweed Park Podcast #68 Sat, 31 Mar 2018 12:20:00 -0400

A very special anniversary podcast where Gary, David and I realize we actually have nothing in common.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Where Are They Now Thu, 29 Mar 2018 15:04:00 -0400

It’s our one year anniversary of launching Thimbleweed Park to the public!

To celebrate, we’re 50% off on ALL digital platforms for less than 24 hours:

Buy it on Steam
Buy it on GOG
Buy it on Humble
Buy it on the Mac App Store
Buy it for Xbox One and Windows 10
Buy it on PS4
Buy it on Switch
Buy it on the iOS App Store
Buy it on Android

We have discounts on some of our great T-shirts and other merch over at Fangamer.

AND we’re releasing the physical versions on Switch and PS4 with Limited Run Games along with an exclusive new vinyl color and an exclusive new T-shirt!

There will also be a one-year anniversary podcast on Monday.

As part of these celebrations, we’ve put together a bumper “where are they now” for many of our team members. So if you’d been wanting to get to know the team better and hear about their other projects, now’s your chance.

We’ve listed everyone in alphabetical order based on first name.

Alexander Preymak

What was your role on Thimbleweed Park?
Russian Translator

Where do you live?
Ryazan, Russia

What is your favourite colour?
Ginger. Sometimes brown

What is your favourite movie you watched in 2017?
Blade Runner 2049

What is your favourite book you read in 2017?
Ned Vizzini, It’s Kind of a Funny Story

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?
Russian Translation

What was your favourite area of the game?

What was your favourite puzzle in the game?
Dime Paradox

What are you working on now?
This was a busy year since Thimbleweed launched, and I’m still translating… Thimbleweed! And a bunch of games with NDA, so check my website from time to time to see my current list of translated games. From the latest projects I can recall Sol 705, an adventure game by Patricio Land which is free everywhere and actually a demo. I also occasionally write for, a Russian video game site — you’ll be surprised, but my latest piece was about Thimbleweed Russian localisation, its ups and downs, and how it’s a great game, and if you’re Russian — buy it and see for yourself.

What’s the best way people can follow you and find out more about your work?
Twitter: @preymak, website:

Chase Martin

What was your role on Thimbleweed Park?

Where do you live?
Seattle, WA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
Three Billboards Outside of Ebbing Missouri

What is your favourite book you read in 2017?
Abbadon’s Gate

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?
Dev Team

What was your favourite area of the game?

What was your favourite puzzle in the game?
Library Stairs – I slapped myself in the forehead after that one.

What are you working on now?
I joined the ID@Xbox Team, to champion and help other independent developers release their games on the Xbox platforms.

What’s the best way people can follow you and find out more about your work?
Twitter: @theplayerpiano

Christophe Pallarès

What was your role on Thimbleweed Park?
French Translator

Where do you live?
Úbeda, Spain

What is your favourite colour?

What is your favourite movie you watched in 2017?
Get Out

What is your favourite book you read in 2017?
The Legend of Zelda – Hyrule Historia

Which section would we find you in at the Edmund Mansion mansion library?
Jokes and Humor

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
Getting Willie out of jail

What are you working on now?
Still working full time on the French localisation of various games. Since TP, I translated Bertram Fiddle (Ep.2), Lydia, The Revenge of Johnny Bonasera (Ep.1, currently working on Ep.2), Just Dance 2018, The Crew 2 (ongoing), Paul Pixel, Tesla vs. Lovecraft, Lucid Dream (ongoing), Midnight Quest, The Goddess Robbery. Various projects in the pipe too! ^^

What’s the best way people can follow you and find out more about your work?
@xtooph on Twitter,,

Concha Fernández Álvarez

What was your role on Thimbleweed Park?
Spanish Translator, QA Tester

Where do you live?
London, UK

What is your favourite colour?

What is your favourite movie you watched in 2017?

Which section would we find you in at the Edmund Mansion mansion library?
Sports and Outdoors

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
Annoying kid conversation

What are you working on now?
I’ve worked on numerous games (AAA, indies, social – sorry, NDAs) and a book project with Spanish publisher Héroes de Papel.

What’s the best way people can follow you and find out more about your work?
Follow me on Twitter! @conchaf7z

David Fox

What was your role on Thimbleweed Park?
Designer, Writer, Programmer, Sound

Where do you live?
San Francisco Bay Area, CA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
The Shape of Water

What is your favourite book you read in 2017?
The Princess Bride

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?
Town, Country, Circus, Mansion, Factory

What was your favourite area of the game?

What was your favourite puzzle in the game?
Finding lost page of Ransome’s Joke Book and charging the battery.

What are you working on now?
Investigating VR (Meetups, connecting, field trips to The VOID), visiting theme parks (research only, hah), updating my old apps (Rube Works: The Official Rube Goldberg Invention Game –, Netflix binging.

What’s the best way people can follow you and find out more about your work?
@DavidBFox, Facebook and LinkedIn

Emily Morganti

What was your role on Thimbleweed Park?
Public Relations

Where do you live?
San Francisco, CA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
Can’t think of any movies, but loved American Vandal TV series on Netflix

What is your favourite book you read in 2017?
Story Genius by Lisa Cron

Which section would we find you in at the Edmund Mansion mansion library?
Young Adult Fiction

What areas of the game did you contribute the most to?
The Upper World

What was your favourite area of the game?

What was your favourite puzzle in the game?
Getting blood sample

What are you working on now?
Doing PR for Wadjet Eye Games’ Unavowed, inkle’s Heaven’s Vault, and Asymmetric’s West of Loathing. Also writing novels and building dollhouses!

What’s the best way people can follow you and find out more about your work?
@fovlet on Twitter or

Fabio Bortolotti

What was your role on Thimbleweed Park?
Italian Translator

Where do you live?
Milano, Italy

What is your favourite colour?

What is your favourite movie you watched in 2017?
Rogue One

What is your favourite book you read in 2017?
Prelude to foundation – Asimov

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
The best “ah-ah!” moment was the forest puddle. It made me feel like in the old SCUMM days.

What are you working on now?
I’m translating two unreleased games (sorry, can’t say which ones!) and I’m working on the DLCs/updates of Rainbow Six: Siege and Ghost Recon Wildlands. I also have a retrogaming channel on Twitch:

What’s the best way people can follow you and find out more about your work?
@fabiobortolotti on Twitter

Gary Winnick

What was your role on Thimbleweed Park?
Creator, Designer, Animator, Inventory Artist

Where do you live?
Felton, CA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
Thor: Ragnarok

What is your favourite book you read in 2017?
Ex-Heroes series

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
Delores Flashback

What are you working on now?
Completing a new comic book ‘The Variants’: an homage to the comics of the 1960’s

What’s the best way people can follow you and find out more about your work?

Heinrich Lenhardt

What was your role on Thimbleweed Park?
German Translator

Where do you live?
Vancouver, Canada

What is your favourite colour?

What is your favourite movie you watched in 2017?
Stranger Things and Black Mirror [TV shows]

What is your favourite book you read in 2017?
Paul Auster: 4 3 2 1

Which section would we find you in at the Edmund Mansion mansion library?
Short Stories

What areas of the game did you contribute the most to?
Additional German translations (HintTron 3000™ text)

What was your favourite area of the game?

What was your favourite puzzle in the game?
Obtaining tools, creating forest footprints and getting Natalie away from her desk.

What are you working on now?
Writing articles for German-language media like GameStar, doing freelance translations and hosting the ‘Spieleveteranen’ podcast (

What’s the best way people can follow you and find out more about your work?  –  Twitter: @hlenhardt

Jenn Sandercock

What was your role on Thimbleweed Park?
Designer, Writer, Programmer, Producer

Where do you live?
Seattle, WA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
Probably the new Blade Runner movie, for the visuals.

What is your favourite book you read in 2017?
I finally finished the Obernewtyn Chronicles, which I started reading almost 30 years ago. Note: most of the delay is because the final book wasn’t finishing until recently. I also finished the Shadowmarch series, which I started around 10 years ago.

Which section would we find you in at the Edmund Mansion mansion library?
Cooking and Food

What areas of the game did you contribute the most to?
Hotel, Sewers

What was your favourite area of the game?

What was your favourite puzzle in the game?
The dialog puzzle with Teddy in the hotel lobby. It was the first puzzle I put in the game.

What are you working on now?
I’m still working a bit on Thimbleweed Park: supporting sales, checking social media and responding to support emails. Mostly, I’m working on an Edible Game Cookbook. That’s real-world tabletop games where you eat real-world food as you play the game. I’m working on a series of games that I can put together into a cookbook with recipes and rules for playing. I’m hoping to Kickstart it this year. You can find out more and subscribe to my newsletter here:

What’s the best way people can follow you and find out more about your work?
Twitter: @jennsandercock

Katerina Bergerova

What was your role on Thimbleweed Park?
Senior QA Tester

Where do you live?
Prague, Czech Republic

What is your favourite colour?

What is your favourite movie you watched in 2017?
I haven’t seen that many movies, but probably Blade Runner 2049.

What is your favourite book you read in 2017?
First two books of Andrzej Sapkowski’s Hussite Trilogy. I also quite enjoyed a series of horror manga by Junji Ito.

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
It’s very difficult to choose just one puzzle. I remember I really liked the puzzle chain during Delores’ flashback – I got a bit stuck the first time I played the game, but all I needed to do was stop and think about the possible solutions. I loved how logical it was in the end. No obscure “randomly combine this with that until something happens”.

What are you working on now?
Well, let’s say I’m planning to practice some game development. But it’s very early to say anything more about this hobby project of mine. I’m also still involved in Thimbleweed Park-related work (as a community manager most of the time, and as a tester when the need arises). Working on this game has been a blast. And who knows what the future brings. Hopefully more great game projects I could participate in.

What’s the best way people can follow you and find out more about your work?
I’m not really an active social media user at the moment.

Katie Postma

What was your role on Thimbleweed Park?
Community Management

Where do you live?
London, Ontario, Canada

What is your favourite colour?

What is your favourite movie you watched in 2017?
Star Wars: The Last Jedi

What is your favourite book you read in 2017?
Parable of the Sower, Octavia E. Butler

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?
Social media

What was your favourite area of the game?

What was your favourite puzzle in the game?
Mouse puzzle!

What are you working on now?
Working at Stoic as the Community Manager for The Banner Saga Series

What’s the best way people can follow you and find out more about your work?
You can find me working here: @bannersaga

Lauren Davidson

What was your role on Thimbleweed Park?

Where do you live?
Southampton, UK

What is your favourite colour?
Peacock blue

What is your favourite movie you watched in 2017?
A Silent Voice

What is your favourite book you read in 2017?
The Disaster Artist

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?
Town, Circus

What was your favourite area of the game?

What was your favourite puzzle in the game?
Riker Burger

What are you working on now?
Dropped Monocle Games’ very talented programmer Denis has been building us a custom point and click framework for the Godot Engine. We have been doing a HD remake of our first ever game, Witchy Woo, to test it and have a full length sequel planned to begin work on shortly after its release.

In my spare time I am working on a dating sim about female serial killers. My Google search history probably has me on a watch list now.

What’s the best way people can follow you and find out more about your work?
@boosegoose is my twitter where I post most of my updates.

Malcolm Stead

What was your role on Thimbleweed Park?
Engine Programmer, Windows & Xbox Programmer

Where do you live?
Vancouver, BC, Canada

What is your favourite colour?

What is your favourite movie you watched in 2017?
In cinema, there wasn’t a lot of great films last year – probably Dunkirk

What is your favourite book you read in 2017?
I spent a few hrs thinking on this one, ended up going for “skag boys by Irvine welsh”. Soley because it was first one which came to mind.

Which section would we find you in at the Edmund Mansion mansion library?
Self Help

What areas of the game did you contribute the most to?
Everywhere. I like to think I was the team’s eye candy

What was your favourite area of the game?

What was your favourite puzzle in the game?
Wait?  Was I supposed to play it?  🙂

What are you working on now?
Just finished working on contract for software for lidar for use in film industry… now working on fun (hopefully) 2d action, comedy game

Also looking at finishing Naked War ™, if enough people want it.

What’s the best way people can follow you and find out more about your work? or Twitter: @ConfusedDuck

Mark J. Ferrari

What was your role on Thimbleweed Park?
Background Artist

Where do you live?
Eastsound (Orcas Island), WA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
Collateral Beauty

What is your favourite book you read in 2017?
All The Birds In The Sky by Charlie Jane Anders

Which section would we find you in at the Edmund Mansion mansion library?
Young Adult Fiction

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
Figuring out how to do the artwork. :]

What are you working on now?
Artwork for a card game based on Sonia Lyris’ ‘Seer’ series of fantasy novels. Check out the first book and the coming card game at

What’s the best way people can follow you and find out more about your work?
Sadly, I am a largely invisible recluse these days, but I do have a website that I myself have neither visited or updated for many years. :]

Octavi Navarro

What was your role on Thimbleweed Park?
Background Artist, Animator

Where do you live?
Barcelona, Spain

What is your favourite colour?
Dark grey

What is your favourite movie you watched in 2017?
I just realized I don’t watch many movies anymore!

What is your favourite book you read in 2017?
Runaway by Alice Munro

Which section would we find you in at the Edmund Mansion mansion library?
Physics and Astronomy

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
The MmucasFlem application puzzle.

What are you working on now?
I’m currently working on Luca Redwood’s new game Photographs and my new short game after Midnight Scenes.

What’s the best way people can follow you and find out more about your work?
Twitter: @pixelshuh

Robert Megone

What was your role on Thimbleweed Park?
Lead Tester

Where do you live?
Basingstoke, UK

What is your favourite colour?

What is your favourite movie you watched in 2017?
Blade Runner 2049

What is your favourite book you read in 2017?
Kitchen Disco (To my daughter)

Which section would we find you in at the Edmund Mansion mansion library?
Short Stories

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
Unlocking the factory.

What are you working on now?
Working full time as a programmer on a new game over at Revolution Software.

What’s the best way people can follow you and find out more about your work?
Twitter: @robertmegone

Ron Gilbert

What was your role on Thimbleweed Park?
Creator, Designer, Writer, Sound, Engine Programmer, Mac Programmer, Audio Director

Where do you live?
Seattle, WA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
Good Time (I just got done watching The Disaster Artist and it is now tied with Good Time).

What is your favourite book you read in 2017?

Which section would we find you in at the Edmund Mansion mansion library?

What areas of the game did you contribute the most to?

What was your favourite area of the game?

What was your favourite puzzle in the game?
Distracting Natalie

What are you working on now?
Desperately trying to come up with a new project!

What’s the best way people can follow you and find out more about your work? (I quit Twitter)

Steve Kirk

What was your role on Thimbleweed Park?

Where do you live?
Seattle, WA, USA

What is your favourite colour?

What is your favourite movie you watched in 2017?
The Post

What is your favourite book you read in 2017?
Testimony by Robbie Robertson

Which section would we find you in at the Edmund Mansion mansion library?
Arts and Entertainment

What areas of the game did you contribute the most to?
Everywhere, Music for all areas

What was your favourite area of the game?

What are you working on now?
I am writing songs with George Sanger and working on a sound design project.

What’s the best way people can follow you and find out more about your work?, @stevekirkpop

Thimbleversary Tue, 27 Mar 2018 19:22:00 -0400

Thimbleweed Park’s one-year anniversary is this Friday, and to help commiserate (I mean celebrate) the game is going to be 50% off for one day on all platforms.  If you’re thinking of picking it up, you might want to hold off a few days.

This will be the deepest discount we’ve offered, after that, it’s back to our normal price (but still less than the Guybrush approved price for a video game).

Physical Releases Wed, 14 Mar 2018 13:15:00 -0400

Physical releases of Thimbleweed Park are coming for the PS4 and The Switch courtesy of Limited Run Games.

Ransome *unbeeped* DLC Wed, 28 Feb 2018 11:59:00 -0500

All clowns swear, don’t let anyone tell you otherwise, but for Ransome the Clown it is an art form.  In our new “not kid friendly” DLC all of Ransome’s beeps can be remove and you’ll be able to hear Ransome in all his unbeeped glory.

Available now on Steam and GOG!

Unfortunately, the DLC will only be on Steam and GOG. All the other platforms require that DLC be rated the same as the main game (they do make exceptions for some AA game, surprise, surprise) so it won’t be coming to Switch, XBox, PS4 or mobile.  We apologize in advance, but that is out of our hands.

When Lauen and I wrote the script, we didn’t add the swearing, we just put in *beeping* or *beeper*.  Adding the swearing would have meant some pre-process to remove them all and it would have been hell on translators.  It was also more fun to write because I had no idea what he was really saying.

When we got to the studio, I wasn’t sure if the actor was going to swear or just say “beep”.  We did some tests and it was pretty obvious that having Ransome say “beep” really undercut his personality.  You got the impression that Ransome was censoring himself, which he would never do.

So, we decided to have the actor (Ian Corlett) go full on swearing. The problem was the script didn’t contain swear words, just *beep*, *beeper* or *beeping*.   Ian didn’t think he’d have a problem just filling in the swear words on the fly and it was amazing to listen to.  He would do first run cold readings and seamlessly add swear words.  It was amazing and hilarious.

I hope you enjoy and please, keep the kids away. We aren’t kidding about this stuff.

– Ron

Aggie Awards Tue, 27 Feb 2018 14:19:00 -0500

Thimbleweed Park Vinyl Tue, 13 Feb 2018 18:01:00 -0500

If your parent’s old turntable is gathering dust in the basement, oh boy do I have an awesome use for it!

Also worth noting that vinyl will likely still be playable after the apocalypse.  MP3’s. Not so much. Think of it as an investment for bartering for food in the future.


Happy 1988! Sun, 24 Dec 2017 12:52:00 -0500

1987 was a great year and we owe a lot of it to you!

Delores Cosplay Guide Wed, 25 Oct 2017 19:10:00 -0400

Thinking about cosplaying Delores for Halloween or some other event?

I got to cosplay Delores at PAX West AND Geek Girl Con this year. I had an immense amount of fun pretending to be a game developer for MmucasFlem games! And now, with this handy guide, you too can have fun!

Assemble your outfit

Let’s start with some reference pictures of Delores.

You’ve got to get all the essentials together to be able to become Delores. Let’s go down from head to foot.


The glasses are the most important part of the entire outfit. If you’re going the simple option, just get these glasses and forget everything else!

If you naturally have Delores’ hair, then I’m super jealous! For everyone else…

▶︎ Temporarily dye your hair
▶︎ Get a wig, there are many cheap ones available, but I like this one from Arda.


You’ll need a t-shirt and jacket.

Delores’ shirt was created to mimic Dave’s shirt in Maniac Mansion. Dave’s shirt is gray with the Lucasfilm logo. So by extension, you can wear any purple shirt with a slogan on it, although I’m sure Delores would prefer MmucasFlem or some other games company logo.

I created as close a replica as I could on Red Bubble as a scoop-neck women’s shirt.

For the jacket, Octavi, who drew Delores, assures me that her jacket is a denim jacket like this light blue one.

Legs & Feet

For jeans, I’m not going to give you a link to find blue jeans because… well… I’m sure you have something that will work! Fold up at the bottom so they’re pretty high.

The most important thing is the curly pink laces. But make sure you also get white socks and plain white shoes (these ones are pretty comfy).


Getting a bag that fits what you want and looks authentic is pretty hard. Still, most cosplay characters don’t have any bag at all, so I feel like it’s a bit of a luxury to be able to stay in character AND get to carry around my mobile phone and keys.

I ended up settling for a bag that wasn’t quite right, but was a bag that I had in my bag collection anyways. If you can make your own bag, do that! But otherwise, maybe this or that option from Amazon will work for you.

Now you’ve got all the basics, you can add in some fun things!

Like a balloon animal….

Or make some damn, fine Thimbleberry Pie…

You can also make yourself a notebook to remember all the things on your TO DO list. You’re aiming for something like this:

You’ll need a blue notebook with spiral binding. I’d recommend picking up something in your local supermarket or office supplies place. However, if you’re desperate, this one from Amazon looks about right.

Download this zip folder with the plain front cover and stickers.

Get In Character

While cosplaying Delores, don’t forget to practice your victory dance and learn to these classic quotes:

▶︎ “But I just want to design games.”
▶︎ “If this were a Sierra On-Line graphic adventure, I’d be dead now.”
▶︎ “It’s my speck of dust.”

Here’s some pictures of me cosplaying Delores for inspiration.

“I’d love to talk to him, but I’m too shy, what with him being famous and all.”

Do NOT attempt to match your head size to Delores, you’ll fall over!

The wig really brings the costume to life and also signals to people around you that “yes, I am cosplaying a character!”

This is me on the left and Elise Kates, the voice of Delores on the right! So much Delores in one photo.

And since I have no shame, I attempted to reproduce the classic “I got a job at MmucasFlem games”-dance! Turns out doing a good moonwalk is REALLY hard! 😉

And that is all! Have fun being Delores!

Android Avaliable Now Tue, 10 Oct 2017 11:53:00 -0400

Google Play Store

Good things come to those who wait (and after I’ve had my morning coffee).

If you’re having support issues, please head over to the support thread on the forums.

Android Slipping A Week. Mon, 02 Oct 2017 13:04:00 -0400

The bad news is we’re slipping the Android version by a week, from the 3rd to the 10th of October.  The good news is the Android build will fully support controllers, mouse and keyboard, plus a wider range of hardware.

Android is always hard due to the vast array of devices. As we got to the end of testing, a few devices showed up with GPU issues that we felt needed to be fixed. We’re committed to having the Android version work with controllers, plus mouse and keyboard and it’s taken longer than we wanted to get it working.

It’s also hard when a version or game slips, it often feels like you failed. It’s only a week and we’ll have more compatibility, plus controllers and mouse and keyboard.

Have I mention controllers and mouse and keyboard? Yes, we’ll have them.

– Ron

Ports Ports Ports Thu, 14 Sep 2017 18:19:00 -0400

Been awhile since I posted here, and I should start doing that more with news and updates. I post a lot of Twitter, but forget that not everyone is on Twitter. I’m starting to think you’re the smart ones.

We released the arcades last month.  There is a new puzzle chain to find tokens for the machines. The puzzle chains can only be done in hard mode, but once you find the tokens, they will be there for every new game, including those started in easy mode.

Occuplying much of our time now are ports, ports and more ports.

The iOS build has been approved by Apple, and now we’re waiting for some PR stuff.

The Switch port has also been approved by Nintendo, but we still have to do some “paperwork” before it will be on the e-store.

Exciting times.

We’re doing last minute testing on the Android port. It’s much harder than iOS due to the huge variety of hardware.  We’ve come across a couple of GPUs that don’t have the power, or are just buggy and needed to rewrite some of our shaders.

We’re also trying to get full controller, mouse and keyboard support into the Android, which is also proving to be more work than anticipated.

Yeah, I know. Bitch, bitch, bitch. Bring us solutions Mr. Gilbert, not problems.

– Ron

P.S. The PS4 port has been live for several weeks now.

Dialogs, Hints and more… Tue, 20 Jun 2017 20:51:00 -0400

There is a new Thimbleweed Park update (Build 1388.918) that includes two major additions and several minor ones.  This build should be live on Steam and will be live on GOG in the next 24 hours.  Due to approvals and reviews, it will be a few weeks before it makes it to the App Store and Xbox.

The first big change is player character dialogs.  You can now TALK TO Delores, Ray, Reyes and Ransome.  There was no point in adding Franklin dialogs, since you can’t really talk to him, and he had one-sided stubs for trying to talk to other players.

This was something I attempted during initial production but abandoned due to me being unable to think about it as anything more than an a overly complex hint system. It always felt to me that all you’d want to do was talk to the other characters and get hints, and the early iterations of the system really showed that, so I abandon it.  Time was also getting short and there was a lot of work to be done, so it wasn’t matter of me writing player dialogs or hanging out at the beach.

This turned out to be a mistake. I should have pressed forward and implemented this.

Allowing the characters to talk to each other actually solved a bunch of problems. It was crystal clear (in our heads) why they were working together (or didn’t care if they were), but that wasn’t clear to players. This is especially true with Ransome. Ransome is an asshole. Why would he be helping?

Player character dialogs solved this problem. You now can chat amongst yourselves while spouting plot clarifying lines. If I had a few extra months I would have made them ever more complex, but maybe they don’t need to be. I’m sure someone will complain that they didn’t talk about X and that is plot critical. Maybe. Maybe not. I do think the dialogs help tremendously and I regret not pushing forward and implementing them from the get-go.

The other slightly related feature we implement was greetings.  When Ray walks by Delores, she will say a quick one line greeting, same for Reyes, Ransome and Delores. None of these are plot revealing, but do make the world feel more alive and real.

The biggest change was a new in-game hint system. I know this will cause the hardcore adventure gamer’s blood to boil (as it does mine), but the lack of hints was widely criticized by some of the more casual press.  As we move to new and more casual platforms like iOS and Android, this becomes increasingly important. I guess it’s a sad fact about not only modern gamers, but older gamers that just don’t have 18 hours to spend on a game.

The first (failed) iteration of the design was based around a new object called the “HintTron 3000™”.  You would find it alongside the road and pick it up.  You could then use it on any object in the game and it would give you a context appropriate hint.

On paper, it seemed like a good idea, until the first implementation and the problems came roaring out. The biggest problem was when you’re stuck it’s often at a conceptual level and you don’t even know what object to click on. This could cause players to randomly click on stuff, hoping the get a hint with no real idea what they needed.

To stop non-stop hint-clicking, we added some friction in the form of a “cooldown”, but it felt artificial and frustrating. We thought about adding a “currency” you find or earn (specks of dust), but these all ran into the issue os rarity and frustration when you can’t find or earn them and you need a hint.

So we abandon the idea. David wrote a lot of code for this… so… a moment of silence.

To me, the most important part of any in-game hint system is making sure it feels like part of the world and game. I didn’t want to do a hint system that was all UI based.

Back in the 80s, we had hint books with red gel, but we also had phone in hint lines.

Thimbleweed Park already has a working phone, so it seemed natural to just have a hint line number you could call and get a hint.

We once again toyed with the idea of a currency. You’re using a phone, so finding money to use it made sense, but unfortunately, the phone is needed for other things and we didn’t want to muck up all that with making them all pay phones, plus some of the phones are in the mansion and hotel. We beat it around for a bit, then just decided to making the hint line “free” to use.

Calling the phone provides some natural friction, in that you’d have to get to a phone (or switch to whoever had the cel phone) and make a call and trip down a hint tree.

The advantage we had over a true 80s hint line was that we know the context of where you are in the game, so the hint line can be smart and focus down to hints we know you might needed, and ignore spoilers and other distractions.

Jenn volunteered to take on the job, and we based it (with permission) on the existing online hints of Meghann O’Neill, so we had a good starting place.  It’s a nice system and hopefully newer players find it fun and helpful.

Now, we know it’s not going to be for everyone, but it is 100% optional in that you just don’t call it. But I know one’s willpower can be weak.  If you set…

hintsEnabled: 0

When you call the hint line, the phone will just ring and ring.

One tricky issue is old save games. To fully implement the AI of the hintTron, we had to add some new variables to track game state. If you load an old savegame, those variables don’t exist.  Jenn wrote some fancy code to try and predict an old savegame’s state. It works 90% of the time, but if you load old games, hints might not be 100% accurate.

And lastly, I implemented some new keyboard commands.

1-6 will now selected dialog choices or they can be reassigned using…

keyChoice1: 1
keyChoice2: 2
keyChoice3: 3
keyChoice4: 4
keyChoice5: 5
keyChoice6: 6

You can assign keys to cycle through characters using…

keySelectNext: 0
keySelectPrev: 9

You can now disable initing of the controller by adding…

disableController: 1

If you don’t have the willpower to avoid calling the new hint lines, you can add…

hintsEnabled: 0

There we more keyboard commands (like the numpad) that I ran out of time, but I’ll save those for another update… because god knows, I can’t stop working on this fucking game.

That arcade machines will make it into the next major update, probably when iOS and Android are released.

Come talk about it on the Official Thimbleweed Park Forums.

– Ron

Official Thimbleweed Park Forums Fri, 05 May 2017 14:05:00 -0400

Announcing the Official Thimbleweed Park Forums. No longer will you have to scroll through hundreds of uncategorized messages looking for that gem of a comment.

I’ve closed all comments on the blog, so if you want to continue to chat about Thimbleweed Park, head on over to the Official Thimbleweed Park Forums.

When I post a new blog entires, the comments for those entries will open up again.

Special thanks to Robin Ward, a backer, blog reader, and co-founder of Discourse, for helping to set all this up.

– Ron

Thimbleweed Park Podcast #67 Sun, 30 Apr 2017 21:15:00 -0400

The very last Thimbleweed Park podcast… can we have a moment of silence.

WARNING: This podcast is filled with spoilers…

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Friday Questions Questions Tue, 25 Apr 2017 12:14:00 -0400

Welcome to what could be the last Thimbleweed Park Friday Questions Podcast.

Time to get all your questions in, although we will be recording on Thursday, so the cut off will be Wednesday evening (PDT).

Please keep your questions about the final game and design, art, production or developer issues related to that.

I think it goes without saying that the comments will be filled with spoilers, so don’t read this is you’re trying to remain pure.

3… 2… 1… GO!


The podcast should be up this weekend, Monday at the latest.

Whiteboards Sun, 09 Apr 2017 18:48:00 -0400

Now that we can post preproduction design docs without fear of spoilers (warning: spoilers ahead) I thought we’d start with the whiteboards.

Early in January, right after the Kickstarter finished, Gary and I got together for a few days of brainstorming on the whiteboard. At this point, we knew the basic story, in so much as these agents show up to investigate the body, and there was a clown, a dead guy and computer programmer.

We didn’t really know how the game would end, or how we’d get there, but hey, that is the fun part.

After the first brainstorm session, Gary had the idea of a big factory and this tube based AI. It seemed ripe for digging, so we ran with that and never looked back.

A couple of months later, David Fox joined the team and we started to get into the nitty-gritty of solving the murder.

After the first day with David, I was really bothered by all the details of finding evidence. It seemed like an arbitrary  jumble and players would be lost.

I went home feeling a little dejected and overwhelmed. What the evidence gathering stage needed was focus, then the idea of TronMachines hit me. By placing them in the Coroners office, it would give that focus. The TronMachines wanted specific items, and that meshed better with how an adventure game worked.  David and Gary seemed to like the idea and it gave out design sessions more focus as well (always a good idea).

Originally the Coroner’s office had 4 TronMachines, the BloodTron, FaceTron, FingerTron and EnhanceTron.  The EnhanceTron was going to be used to enhance a video image taken from the Quickie Pal video camera, but it felt like too much, so we cut it.

We saved the flashbacks for last, and for those brainstorm sessions Jenn join us. Ransome’s flashback started to get huge and we cut it back significantly.

We took pictures of the white boards at the end of each session, or before we erased them.

Most of what you see made it into the game, although tweaked quite a bit. Other parts never got off the whiteboard.  Some of it made it off the whiteboard and into the wireframe version, but was cut before final art.

Patch Notes Tue, 04 Apr 2017 18:33:00 -0400

In the continuing series called “Hey, let’s make a video game”, I thought I’d take people through all the patch notes and talk about what happened, why it happened and how we fixed it.

Note that these patch are for Steam Build 1309.859 only, the GOG versions will be up tomorrow and the Mac App Store and Xbox a few days after that. You can see the build number by looking in the lower right of the Options menu.

We group post launch bugs into three categories.

1 – Game breaking bugs that render the current game unplayable.
2 – Bugs that cause issues (or even crashes), but reloading the autosave fixes it.
3 – Small feature changes to keep players happen or avoid confusion
4 – Everything else.

If the bug is level 4, it just gets moved to fix next rev.  For these patch (live patches) we want to make safe and easy changes, because they are not going though a full cycle of testing. These are emergency fixes only.  In a few weeks, we’ll do a major rev with all the little things change (and maybe some new content) and it will go through a full testing pass.

But for the live patches, we want to change as little as possible.

Don’t read any more if you don’t want the game spoiled.

Level 1 bugs.

Ransome’s Cheese

If you picked up the cheese in Ransome’s fridge, and then tried to put it back, the cheese would disappear, making the game unfinishable since the cheese was needed for a later puzzle.

This ended up being nothing more than a bad copy/paste error, where the wrong object was pasted into the line that made the cheese visible again.  It was missed because none of the testers thought to put the cheese back.  It’s the type of bug TesterTron™ won’t find, because it’s never going to be smart enough to solve the whole game, and get stuck because it has no cheese.

Rathole Cheese

If you put down the cheese by the rat hole, and then picked up the cheese, the rat hole was untouchable.

Text update after more information from David Fox

For the bug where picking up the cheese from the rat hole caused the hole to become untouchable, this had to happen during the 1/10 of a second when the rat stopped by the hole and saw the cheese to when he went over to the cheese a few pixels away. If you picked it up at that moment, the hole would already have been made untouchable. You did get the cheese but could never put it back there again. That’s why it was hard to catch.

A Street Dime.

The dime needed to make the call to free the trapped agent is randomly placed. One of the places is on A Street.  But… A Street is blocked off and a WC-67 tube is needed to solve the puzzle.  If Ray goes to the store and gets the tube, then walks into the alley and gets captured, there is now no way to get to A Street and get the dime since she has the tube.  If Reyes had been captured, it would have been OK since Ray has a cellphone (that won’t work in the sewer).

The captured agent puzzle is one of the first puzzle we did, close to 2 years ago.  The pigeon sisters used to be out on the highway, but we moved them to Main Street late in the project, and we never thought about that dime on A Street. It’s pretty rare situation, since the dime had to spawn on A Street (1 in 4 chance) and then you had to get captured while holding the tube.  It just never came up in thousands of hours of testing. Since the dime puzzle was created so long ago, it was out-of-mind for us as well.

Disappearing Robot Tube

If you used this one specific tube you had on the robot in Chuck’s work shop, it would vanish.

There are a lot of tubes in the game and a lot of places to put them. We tried to create a “system” to deal with them, but this one tube was not flagged correctly, so it would vanish from your inventory.  Solution was just to tag it. Again, just a rare situation not caught in testing. You had to work pretty hard to be in the situation where you had that tube and the robot head.

Radio Station

The puzzle chain that happens around the radio station is very complex. You have to switch between three characters to solve it and Cassie (the DJ) is walking around the whole time.  There were several places, where if you interrupted the sequence, or the sequence interrupted something you were doing somewhere else, it would break.  All these were issues that had to happen in exactly the right frame, so it ended up being pretty rare. None of them resulted in unplayable games and could be solved by just quitting and loadings, but they were ugly enough to fix.

Most of the 1-frame issues are a result of this being a new engine, now that I see what is happening “under the hood”, I can make system changes to prevent them, but that is a larger issue than can be address in a hot fix.

The Hat Bug

This was a bad one, and the one that messed up the most players.  If you are wearing the pirate hat, and then try to give it to the comic book salesman, the hat vanished. Unfortunately, it was need for a puzzle at the end of the game.

When you give an item to someone, it runs through this complex chain of code, querying objects and actors along the way seeing if the object is givable, if the actor wants it, if the actor holding it wants to give it a way, etc.

That chain is correctly followed for the hat… unless you’re wearing it when you give it away. In that case, the code just gave the hat to the NPC without running though the correct query chain. Had it gone though the query chain, it would have failed and not been given away.

What makes this bug so dangerous, is the comic book salesman is looking for something “valuable”, so it make complete sense to try and give the pirate hat to him, and what looks cooler on your head then a pirate hat. Perfect bug storm.

The correct solution would be to send the hat give through the query system, but for a hotfix, this was too much code, so if you try and give the pirate hat to an NPC, it won’t let you.

Level 2 bugs

If an agent is stuck in the sewers, you have to look up a phone number and call the Sheriff for help.  If the Delores flashback happens while an agent is captured, Delores can call the number and get help sent… from the past!  It’s a funny bug, it doesn’t break anything, but we decided to fix it. Now, if you call the number from a flashback, nothing happens.

There were a few places where an NPC actor was moved to the circus for Ransome’s flashback and not returned where they came from, and then not inited correctly.  Most of these show up if you do things a extremely out of order. Quick fix to force them back.

If you call the bank before visiting, you get a black screen and the game appears to hang. Overriding the cut-scene (ESC) fixes the issue.  This is because the banker might have moved to the circus for the Ransome Flashback (it’s ransom), so he was in this special room called the Void. The fix was to init the banker when the phone call happens.

If an actor was on a ladder, and the engine teleported them somewhere, they stayed in their ladder animation until they got on a ladder, or one of many other events reset the animation.  For example, if Ray was on a ladder, then Reyes talked to the Sheriff at the Vista, there was a scene where Ray should up… but she was on the ladder. Easy fix to just reset the animations in the four places that happened. There is a better, more proper fix, but we’re hotfixing, so that was just 4 lines of new code.

If you used the hotel card key in the pigeon van, the game would crash. It was accessing a variable that didn’t exist. Quick fix, 1 line of code.

The phone uses 4 digit numbers, but the security pad uses 6 (and they both use the same programming code, so if you used the security pad by the cabin, the phone now thought it needed 6 digits. It didn’t break the game, but made calling backer phone numbers imposible.

There were a couple of places where gates would open and close. The internal flag to show the gate was open was set when the gate got to the open state, which could take a few seconds. If the player switched character while the gate was opening, the flag never got set.  The multitasking threads that are opening the gate are “room local”, so they get killed when you leave the room.  We solved this by wrapping the opening animation with an inputOff(). It was the quickest thing to do for a hotfix.

When Franklin creates and walks through his portal, if the Cassie/Radio cut-scene happens at that very moment, the portal was gone on the other side. We added a safety check for the portal not being there and creating it.

Level 3 bugs

There was a big where if the Kid in the hotel was standing close to the drinking fountains, but so was a playable character and they were 1 pixel closers, it would fall into some code with a null pointer. We now trap for the null pointer.

If you were exchanging the bottle for the nickel, if you hit ESC at just the right moment, you would have two nickels.  It didn’t break the game, but was confusing.

If Chuck’s favorite number was 1, then a dialog to guess it got very confusing. Nothing broke, but players thought it had.

For the puzzle for getting the map from Natalie, many players didn’t realize that if you messed up, the puzzle was reset to a new answer.  We fixed that by making it clearer that the answer was reset, and also calling attention to the radio.

We added the key mapping screen to Options Help. We just forgot to add this. Dumb mistake. It’s english only right now, we’ll translate it for the next rev.

F5 now brings up the Options screen. I was tired of hearing people complain about this. 🙂 You also can now remap the skip dialog key. And the mouse scroll wheel now scrolls the inventory. Ctrl-O now brings up the Options so O can be remapped to verbs.

We also fixed a bunch of typos.

One of our big challenges was for players who had Level 1 bugs and their savegame became unplayable.  We added code to the postLoad() routines that detected the bad state and corrected it. So, for example, if you gave away the pirate hat, the loadLoad() code would realize that and magically put it back for you. Same with the dime.  Not a lot of people were affected, but if they were, this patch magically fixes it.

It may seem like a lot of bugs, but it’s pretty much par for the course.  We spent a lot of time testing and there are (literally) thousands of things to test, so it’s not unexpected when a few fall though, especially ones that a really rare.

This group of testers is one of (if not the) best I’ve ever worked with. When these bugs started show up, everyone jump on Slack and the testers ninja reproduced them and we fixed them.

Some of these bugs are 1 in 10000 odds, but when you have 2 or 3 times that many people playing, they become a 100% chance of happening to someone.

Stay safe out there.

– Ron

Options Fri, 31 Mar 2017 19:10:00 -0400

As promised, here are some of the options you can set in Thimbleweed Park.

First, you need to find the Prefs.json file.

Mac: ~/Library/Application Support/Terrible Toybox/Thimbleweed Park
Windows: AppDataRoamingTerrible ToyboxThimbleweed Park
Linux: ~/.local/share/Terrible Toybox/Thimbleweed Park

Most of these are just debugging, so don’t complain (haha… don’t complain… who am I kidding) about them giving you weird results, these are not meant for mere mortals, which is why they are not on the options menu.

We’re a very small team and we just didn’t have the time to iterate on these without letting more important issues slide.

Can the window be resized when in windowed mode. Since we use nearest neighbor scaling, this can produce ugly result.  If things get goofy with the windows, go into Prefs and delete all the entries that start with “window” to return back to the default.

windowResizeable: 0

Amount of wiggle when mousing over the verbs, 0 = none

verbWiggle: 1

Amount of wiggle when mousing over the dialog lines


Turns on pixel perfect mode. It hasn’t been tested very well, so it might cause issues. I’m sure it could be better, but we ran out of time.  Remember, this is only the game scene, not the UI.

UPDATE: pixelPerfect mode seems to be broken if you’re not running windowed at 1280×720. No idea, used to work just fine.

pixelPerfect: 0

Number of times to “pop” the inventory when adding an object.

inventoryPopCount: 5

Holding down the TAB key will show you hot spots. It’s not 100% accurate and might show false positives or false negatives.

hotspotCheater: 0

When the verb or dialog is on screen, how transparent is the background.

uiBackingAlpha: 0.33

Alternate location for save files (like dropbox).  You have to use /, even on windows. If you save them in dangerous places, it’s all your fault.  Applications that are sandboxed may not allow the saves to this location.

savePath: “/path/path/”

Show the system cursor.

systemCursor: 0

Clicking the right button will skip dialog, but only when you’re in a cut-scene or the cursor is off.

rightClickSkipsDialog: 0

For key mapping, you can only use lowercase, as it won’t see the shift key.  You can also use numbers without quotes for scan codes. Some international keyboards map keys oddly.  The only key you can’t remap is “o”, since it beings up options.  I’m changing o to control-o for options in the next patch, then you will be able to.

keySelect1: 1
keySelect2: 2
keySelect3: 3
keySelect4: 4
keySelect5: 5
keyOpen: “q”
keyClose: “a”
keyGiveTo: “z”
keyPickup: “w”
keyLookAt: “s”
keyTalkTo: “x”
keyPush: “e”
keyPull: “d”
keyUse: “c”

There are a lot more options, but most of them are for debugging and have no effect on a release build. If there is something I missed, let me know, I might have forgot it.

Released! Thu, 30 Mar 2017 09:51:00 -0400

Thimbleweed Park is officially out!

If you are a backer, log in to your PledgeManager account to get your key.

If you aren’t a backer, you can buy it here…




The forgotten help screen… literally, we forgot to add it.

– Ron

If you need tech or backer support, please email
We won’t be answering support questions here.

Final Development Post Tue, 28 Mar 2017 15:04:13 -0400

This won’t be the last one, but it’s the last “development” blog entry.  Any blog post in the future will be post-release blog posts, they won’t be about the development process, but more about the care and feeding of a game post-launch. They will also come once every one or two weeks.

Maintaining a blog with multiple updates each week, while you’re trying to make a game, is a lot of work. As much as I like writing these and reading everyone’s comments, it will be nice to take a break.

And yes, I do read ALL the comments. When a comment is added, I get an email with the text of the comment and a link to take me to the comment. I read them all.

For this last “development” blog entry, I thought I’d talk about what we’re doing right now.  What does the last few weeks of a project look like?

It’s a lot of scrambling around, dealing with marketing, PR, storefronts, launch trailers, and endless little decisions like pricing.

Let’s start with pricing

We starting talking seriously about pricing 9 months ago.  We had three basic choices: $14.99, $19.99 and $24.99.  We really needed consistent pricing across all the stores, and while some allow for finer grained pricing, not all do. This was a common intersection between all the stores.

$14.99 is probably the most common for indie games.  This was our first pick and hung on for quite a while.  As we got closer to finishing and more and more people played the game, we realized it was a huge and deep game.  The two choices now became $19.99 and $24.99.  $19.99 won out for a while, then we settled on $24.99.  It felt like the game had enough value to warrant the price. It was higher than a lot of indie titles, especially 2D titles, but we felt we could support it.

We lived with $24.99 for a bit, and felt any point-and-click fan would gladly spend the $24.99. As we’ve talked about on the blog and on the podcast, one of our main goals is to introduce new people to the joy of point-and-click. It started to feel like $24.99 might be a barrier for that group.

Pricing is always hard. None of us are experts at it. We talked to several industry friends and no one was overly excited about $24.99. It seemed too high. Not for the people who bought the game, but for all the people that were on the fence. Pricing at $24.99 might do well with the core, but it wasn’t going to attract a new audience. Given that was one of our main goals, we settled at $19.99.

Moving on to storefronts

We have to deal with five storefronts on launch: Steam, GOG, Xbox, Win10 store and the Mac App Store. And every store front has different size images they need.  Steam has 5 or 6 images size for the main store, then there are all the Steam Achievement images and Steam Trading cards, badges, etc, etc.

It’s a lot of art to produce. Some of it is just resizing images, but you’d be surprised how long it takes. Plus, resizing pixel art is harder than normal art. We can’t just drop the size by 5%, otherwise the pixels get all screwed up.

GOG has it’s own sizes, and the App Store has it’s own sizes, and Xbox and the Win10 store. Everything need it’s own art sizes.  Jenn spent weeks and weeks getting all the art into the right sizes.  If you’re releasing a game, don’t underestimate this.

Launch trailers

We’ve done several trailers for the game so far, but for launch we need one trailer that sums it all up.  I wrote the Ransome trailer before we went into the studio, but before we even had a rough cut.  I didn’t think to write a launch trailer in advance, and we didn’t have the budget to pull actors back into the studio.

I talked to Derek Lieu about it. He has done all of our trailers so far and he’s amazing. We talked about doing a movie style trailer where all the dialog was taken from the game and pieced together to tell the story.

I got Derek the entire script and he poured through it for a week and came up with a first draft.  We beat that up and tweaked it, then he did a first cut with black cards where the footage would go.

I then made a cut-list and started capturing footage. All in all, it took me about 3 days to capture and recapture all the footage and Derek a few weeks to put it all together.

Review copies

We send out several hundred review copies to the press.  Before we did that, I needed to get Steam working. It only took a few days, and maybe a few more to fully understand it.  Once that was in place, we tested the review build (which is, in theory, the final build) for a good week and then sent out the review steam keys.

All-in-all it went well, the reviewers found 3 or 4 bugs that we opted to fix and pushed new builds to Steam.  When we got a report of a bug, we’d immediately try and figure out what was happening. Most of the time, it was obvious what the issue was. A few times we had the tester team attack it and find a repro case.

The first bug we got from a reviewer completely stumped me. It made no sense. I poured over the code for a few hours and couldn’t see how it would happen.  Friends arrived for board game night and I took a break. About an hour into board games, it hit me and I knew what the issue was. Bug solved.

I’m sure post launch will be like this. We’ll get bug reports and, evaluate the severity and immediately fix the big ones, and move the others for a future rev.

When you’re fixing bugs on a “hot” version, you want to change as little as possible.


Part of send out the review copies was setting up interview and podcasts. Our PR master, Emily, did all the work in setting them up, but me and other teams members had to take time to answer questions and do podcast. Again, don’t underestimate the time this takes.

We also sent these ViewTron 3000’s to some press and will have them for sale on Fangamer in a few days.


In addition to PR, there is also marketing that needs to be done. For small indie titles, this is main social media.  So, we spend time on Twitter and Facebook and all the others, posting images and countdowns.  More stuff to write and create.  Marketing is probably our weak spot right now.


The Steam builds are locked down and everything is under control. We’re a little behind on the GOG builds, but by the time you read this, everything should be fixed. I wasn’t planning on doing a Mac App Store build, but I had to do the code signing for other reasons, and once you’ve done that, you’re 90% there, so I decide to put it up.

The Xbox is a whole different story.  You have to go though Xbox’s cert process and it can take anywhere from a week to a month. It was a huge wild card. We submitted a few around a month ago and it took a couple of weeks to make it though. The issue was, a lot of bugs got fixed while it was sitting in cert. So, last week we made a new build with all the bug fixes and entered cert again.  Just yesterday we passed that cert and are ready to go.

Backer keys

Wow, how hard can that be?  Well, actually pretty hard. If we had done nothing but Kickstarter, it would be a lot simpler, but since we took pledges from Humble Bundle and then later via PledgeManager (to allow backers to upgrade), it’s a been a real challenge to get all the names and backing levels integrated.  PledgeManager doesn’t have a system for sending email to backers, so Jenn had to set up a separate system.

We also have the issue with the DRM-free keys being done by GOG.  We should have set up separate “products” in PledgeManager where you picked Steam or GOG, but we didn’t, so we had to set up a separate system to cull that information and make sure everyone gets the right keys.

It’s been a learning experience. The whole project has been a wonderful learning experience. Did I say wonderful? I meant terrifying and stressful.

– Ron

Soon Is Soon Mon, 27 Mar 2017 13:31:00 -0400

If you were a backer through Kickstarter, Humble Bundle or PledgeManager, you should be getting an email today listing out what will happen on International Thimbleweed Park Launch Day and how to get your key.

I won’t repeat the whole email here, but the gist of it is…

On launch day, you will get an email from PledgeManager saying your key is ready and you will then login to your PledgeManager account and get the key.  If you’re a backer and one of the over 2000 people that has never logged into PledgeManager, I suggest you do that right now, so you’re not fumbling with it while everyone else is playing.

Once you get the email and if you have any questions… email

Do not ask questions here.

We’ve also set the price of the game at $19.99 on all launch platforms.

As an added bonus, if you backed at the soundtrack level, you will also be getting the Thimbleweed Park soundtrack and printable CD and cassette tape sleeves. Instructions will be in the launch day email.

One Last Entry Sat, 18 Mar 2017 18:46:00 -0400

I know you’re starting to tear up like I am, but our time together is coming to a close.  It’s been two years filled with joy, laughs, learning, and anxiety (mostly anxiety).

Before the game launches on the 30th, I’d like to do one more big dev blog post. Any suggestions?

And for those of you skeptical that we made any progress over the last two years, here is the first video of the game I posted.

– Ron

P.S. Just to clarify, we will continue to post on the blog after launch, but the posts will become less frequent, only when news shows up. Keeping the blog current is exhausting work.

Tracking Talkies Sat, 11 Mar 2017 20:44:00 -0500

With over 16,000 record lines of dialog, someone on Twitter asked for a blog entry how how we keep it all organized.  “Ha ha, we don’t”, Ron said laughing.

OK, not really, but kind of.

A quick refresher on how we enter and extract dialog from the Thimbleweed Park.

During early stages of development, we embed the dialog in the source code.

sayLine(delores, “George the postman will never pick it up without stamps on it.”)

Every time I bring this up, someone pipes in and says it’s stupid to keep text in source code and I should have my game dev license suspended.  I don’t disagree. Keeping text embedded in source code is a crazy, dangerous and a rookie move.  And we don’t. Hear me out.

All the text in the game stays embedded in the source code for a good 3/4 of the project. It’s just easier that way.

I’ve seen game dev code that looks like this

sayLine(delores, TEXT_27243)

And that’s fine if you have a few dozen lines of text, but becomes a creative nightmare when you have a tens of thousands and you’re trying to write and iterate. Remember, our source code isn’t just programming, it’s also our script and the implementation of the game’s expression.

We need to iterate and iterate fast. Having to look up, or enter lines of text in a “text table” would slow things down, so we just stick it in the source code.

About 5 months ago, I ran a fancy python tool over all the source code and it was turned into this…

sayLine(delores, DELORES(27243,“George the postman will never pick it up without stamps on it.”))

…and emitted a spreadsheet that looked like this…

DELORES    27243    George the postman will never pick it up without stamps on it.

The spreadsheet served a secondary function, and that was to do the translations. The translators would go though and add a new column for their translation. The original English was saved as ThimbleweedText_en.tsv and the Spanish was ThimbleweedText_es.tsv. We can keep adding translation files as we add translations. When we open the game up to fan translation, this is how it will work.

DELORES    27243    George el cartero no se la va a llevar si no tiene sellos.

Anytime we changed a line, we changed it in the source code and then re-ran the python tool and it would update the spreadsheet.  The spreadsheets were readonly. We never edited them directly.

This went on for several months, then it came time to record.

Each line of text got tagged with these MACROS that told us who had to say each line.

DELORES if only Delores said it, RAY if only Ray said it, or AGENT if both Ray and Reyes said the line.

Then it got a little trickier.

PLAYER_AD if the Agents and Delores said the line, or PLAYER_DR if Delores and Ransome said the line, etc, etc.

sayLine(PLAYER_ADR(29971,“There are no drawers to close.”))

The preceding line needed to be recorded by Delores, Ray, Reyes and Ransome.

The preprocessor macro looked like this…

#macro PLAYER_ADR($a,$b) “@$a:”

The actual text string is compiled out of the final code, leaving just the line ID. See, there is no text is the code.

Ultimately, this was needed to emit the scripts for the actors. If there was no voice, we could have used one tag (PLAYER) and be done with it.

When it came time to print the script for Reyes, we need to grab all the lines he needed to record (REYES) and the lines both he and Ray said (AGENT), plus any lines he, Ray and Delores, and Ransome needed to record (PLAYER_ADR).

It was tricky business to make sure all the lines were correctly tagged and we made a few mistakes. Some lines didn’t get recorded and when that happened, we’d have to find another line that worked as well, or did some clever wav file editing.

We could have done a pick-up session, but so few lines were missed, that it wasn’t worth the cost.

OK, so once the script was exported, we would go into the studio, record the dialog and then it would be cut up into .wav files.

You’ll notice when the script is exported for Delores, lines tagged with PLAYER_AD get shown as DELORES, this is so when the editor cuts up the dialog, it gets save as DELORES_28938.wav, not PLAYER_AD_28938.wav.  From that one line, we’re get 3 .wav files (DELORES_28938.wav, RAY_28938.wav and REYES_28938.wav).  It one line of text that’s read by three different actors and needs to appear in the game assets three different times. They all have the same text ID because, as you recall, the text is striped and all that is left is the ID. When an character in the game says a line, the engine knows to prepend the name (RAY/REYES/DELORES/etc) to look up the .wav file.

The marks you see in the third column are the take-marks I did while recording to indicate the take I wanted.  The /1 was the first take and I liked the A read, not the b read (the actor read each line twice). The fs means the actor had a false start and didn’t read the whole line. The /4 means after they read one section of the script, we went back and did a fourth take.

When the recording was done, we had 16,000 .wav files and each was put into a folder named for the character.


It’s around 6GB of .wav files and we needed to compress them for inclusion in the game.  We used .ogg files due to it being free of the patent and licensing issues that .mp3 has, although either would have worked.

I have a bash script that takes all the .wav files and compresses them into .ogg files, ready for the game to load.

Any editing we do is always done on the high quality .wav files so we can compress into any format we need.  For example, we might need to compress the voice more for mobile and it’s just an automated process.

We also have a script that runs each line though the lip-sync tool and produces .lip files, which are small text files with timing and mouth data. This process takes around 16 hours to run.

Of course, it gets more complex with Ransome and his foul mouth.

When the actor playing Ransome recorded his lines, he swore, then each of those .wav files had to be beeped.  We kept all the original lines for two reasons. The first is we want to release an uncensored pack at some point and the second is Ransome needed to be lip-synced against the non-beeped lines, so when the lip-sync process was run, we need to point it at the original Ransome lines, not the beeped ones.

In the case where we had to hand edit a Ransome line, we had to edit the original, then edit the beeped version then make sure each got to the correct folder. It was nerve racking.

There you have it. Making games is easy.

– Ron

Thimbleweed Park Podcast #66 Sat, 04 Mar 2017 14:36:00 -0500

The podcast hailed by critics and historians as pointless and of no real value, it’s Friday questions!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Friday Questions Wed, 01 Mar 2017 15:03:00 -0500


After a long break, Friday questions are back!

Post your questions for Gary, David or I to answer on this week’s Thimbleweed Park™ Podcast and we’ll do our best to answer them.

One question per-comment and please try and keep them short. If you leave a long meandering question, we’ll get bored and start reading twitter.

If you question relates to these final stages of the project, it will be more likely to be answered.

And as always, be nice and no wagering.

– Ron

FAQ Tue, 28 Feb 2017 18:28:00 -0500

All hail the new FAQ. If you have a general purpose question that is not answered here, please post it in the comments and we’ll add it to the FAQ (where appropriated).

Q: When is Thimbleweed Park coming out?
A: Soon! Just kidding. March 30th, 2017

Q: What platforms is it coming out on?
A: Mac, Windows, Linux and Xbox One.

Q: I backed the Kickstarter, what platforms will I get?
A: Backers will get a key for Mac, Windows and Linux.

Q: Do I have to choose Mac, Windows or Linux?
A: No, backers will get all three.

Q: Will I get a key for the XBox?
A: Unfortunately, only the Mac, Windows and Linux platforms are part of the Kickstarter reward.

Q: I want a DRM free version, can I get that?
A: Yes, before the launch date, you will get a email asking if you want Steam or GOG (DRM free).

Q: Where can I buy the game?
A: Initially on Steam, GOG and the Xbox and Microsoft Store. We’ll add other places as soon as we can.

Q: Is there Cloud saving?
A: We use Steam Cloud saves for Mac, Windows and Linux, and you can save from the Xbox to the Windows 10 store copy. You can share saves between Mac, Windows and Linux, but you can’t share saves between Steam and the Xbox.

Q: Will the game be play anywhere on Windows 10 and Xbox?
A: Yes.  If you bought the game on Xbox or via the Windows 10 Store.

Q; What will the price be?
A: $19.99 USD.

Q: Will you release it on the Playstation and Switch?
A: Hopefully, but we can make no promises now. Once the game is released and we have some free time, we’ll look into both of those. Ports take time and money, neither of which we have much of right now.

Q: Will the game be translated?
A: Yes, it will be subtitled in French, German, Spanish and Italian. Russian will follow a few weeks after release and will be a free upgrade.

Q: Is it only English voice?
A: Yes, for now it is only English.

Q. Will there be a boxed version of the game I can purchase?
A. Yes, once the Kickstarter boxes have been sent out, we will be selling an (unsigned) boxed version of the game.

Q: When can I expect my other Kickstarter rewards?
A: Probably a few months after the game releases. We’re a small team.

Q: Are you going to open source the game engine?
A: We don’t know. If we do, it won’t be for several months after the game is released. Open sourcing is not as simple and just releasing a bunch of code, and you’d get to see what a crappy programmer I am.

Q: Help, I’m having issues with my Kickstarter, Humble Bundle or PledgeManger order!
A: Send an email to support [at] thimbleweedpark [dot] com. Don’t post questions to the blog.

Q: I really want to buy some Thimbleweed Park t-shirts and mouse pads, where can I get those?
A: Right HERE

Release Date! Mon, 27 Feb 2017 14:09:00 -0500

We had a big meeting this morning and decided that we should announce the release date.

So set your calendar reminders, make sure you’ve got your “I’m starting to feel sick” routines prepped for the day before release…

You’ll be able to play Thimbleweed Park on Thursday, March 30th!!!!!

The game will be released on Mac, Windows, Linux and Xbox One.  Other platforms will follow in a few months.

That is all. Grab a goodie bag on your way out.

– Ron

Compatibility Test Thu, 23 Feb 2017 14:40:00 -0500

UPDATE: We are no longer taking compatibility testers.

Play Thimbleweed Park!

OK, not really, that was kind of a click-bait opening.  But you can play a small section of the game to help us with compatibility testing. And by small piece, I mean just a few rooms you can walk around and see if the game runs on your hardware.  There might be one puzzle.  It’s unlikely there will be any spoilers, but if seeing great art is a spoiler, you might want to steer clear.

We’re going to start small, only sending out a few copies, then slowly open it up to around one hundred people over the next week unless something goes horribly wrong, in that case we’ll just pretend like the whole thing never happened.

If you’re interested in helping out, CLICK HERE and fill out this form.

Why don’t you just release a demo? I can hear you saying that.

The reason is we don’t have a demo that tells the right story. The only thing we have is the Ransome demo shown at PAX and the fan events. It doesn’t really tell the story of Thimbleweed Park. A good public demo is like a good movie trailer, it should entice you and leave you with unanswered questions. The Ransome demo does none of that, it can also mislead people into thinking this is a game about a clown, which it is not.

– Ron

Thimbleweed Park Podcast #65 Sun, 19 Feb 2017 10:24:00 -0500

OMG! WTF! LOL! Just when you’d given up all hope, it’s a Thimbleweed Park Podcast!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Steam Page Is Live Sat, 18 Feb 2017 11:19:00 -0500

The Thimbleweed Park Steam page is live. No release date yet, but we’re very very very very very very very very (breath) very very very very close to announcing that.


“What’s the hold up with announcing the release date? I thought making games was easy?”

Oh, yeah, don’t get me wrong, making games is super easy, it’s releasing them that is hard!

The main reason we haven’t announced a release date is that we don’t want to be wrong. We’re working through some last minute technical and marketing issues, but we have 95% confidence that those are resolved.

Trust is, we want to release this game more then you want to play it.

– Ron

P.S. It will also be available on GoG and probably some other online stores.

London Sun, 12 Feb 2017 11:29:00 -0500

Finally back in the States, head to the grindstone, franticly working on Thimbleweed Park. Many thanks to the other team members who picked up the slack.

We had a great time talking to fans and the press, trying to spread the word about this amazing point and click adventure game we’re working on. Maybe you’ve heard of it. It’s called Thimbleweed Park. Please buy 10 copies.

Here are some pictures of the London event, curtesy of @FinlayCostello. We had a great time showing everyone the game, signing boxes, taking selfies and 80’s Polaroid’s.

David, Gary and I will be recording a podcast on Monday. We’ve been busy working on this amazing point and click adventure game. Maybe you’ve heard of it. It’s called Thimbleweed Park. Please buy 10 copies.

München Mon, 30 Jan 2017 01:22:00 -0500

Had a great great time at the Munich Thimbleweed Park Fan Party.  So many great people, all playing Thimbleweed Park and talking about adventure games. Thanks to everyone that came along. We even had a crappie 1980s polaroid camera to take phone with (no on wanted to be the dead body).

Thimbleweed Park does Europe Update!!! Fri, 20 Jan 2017 14:44:00 -0500

We’ve had a great response for our three fan events in Europe! Thanks to everyone who let us know they’re coming.

We’re now able to confirm that the full details for the fan events are:


Date: Sunday 29th January 2017
Time: 7:00pm – 11:00pm
Location: Stragula, Bergmannstrasse 66, 80339 München

IMPORTANT NOTE: We were unable to secure a place that can fit more than 80 people and also adheres to our other requirements. We’ll do our best to get everyone who turns up to come in. But with over 140 people signed up so far, it might be hard. We’re asking for your patience and help in letting everyone have a chance to see the game.


There’s been a lot of concern about the venue capacity of our Munich fan event.  We’re listening to you.

At this point, it’s too late to find somewhere that will be able to fit everyone and meet our requirements. FYI: Our main requirements are to have a relaxed venue where you can hang out with some of the dev team and other adventure game fans. Other venue options that we looked at in Munich that were larger would mean that the event would become more formal and corporate-like. Ron’s at his best when he’s meeting you all individually, rather than addressing the multitude. We also want a place that served food and drinks.

UPDATED UPDATE: We’ve been able to arrange it so that we can open to everyone at 5pm (17:00). So that gives us more time for everyone to come, hang out, grow bored, leave and let new people in.

However, we want to make it clear that we will not kick anyone out. We do ask that if you feel like you’ve had a good experience and there are people waiting outside that you respect them and let them have a chance to come inside and hang with everyone. But we will not kick people out.

We will have a limited number of stations to play the game on, so it’s unlikely everyone will get to play, but we won’t be kicking people off after a few minutes of play, you will get to complete the demo. This has been true at all the past events and a group usually gathers around the station and everyone played it “adventure game” style. We try and have big monitors so everyone can watch.

We know this isn’t ideal, but we hope everyone still has a great time.

Berlin (powered by Games Academy)

Date: Saturday 4th February 2017
Time: 6:00pm – 10:00pm
Location: Games Academy, Rungestraße 20, 10179 Berlin


Date: Thursday 9th February 2017
Time: 7:00pm – 11:00pm
Location: Zigfrid von Underbelly, 11 Hoxton Square, London N1 6NU

At each location Ron Gilbert and I (Jenn Sandercock) will be there. At some of the locations some of our European team will join us. In Munich we’ll have: Boris Schneider-Johne (German translator), and some of our test team. Joost Peters (programmer) will join us in Berlin. Rob Megone (lead tester) will join us in London. Others of the development team will also try and join us if they can.

Ransome the *Beeping* Clown Thu, 19 Jan 2017 11:24:00 -0500

Ransome the Clown tells you what he really thinks of Thimbleweed Park

Germany and London Events Sat, 14 Jan 2017 11:38:00 -0500

We’re going to be do a little press tour in a few weeks through Germany and London and we’re going to set up some fan events when you can hang out, chat about adventure games and play a little Thimbleweed Park and complain in person about .

We looked into going to some other counties, but time and money was a limiting factor, so we apologize for that.

As we say in America: ROAD TRIP!

The prefered way to sign up is with Facebook by going HERE.

Or you can sign up HERE if you don’t have Facebook.

But please don’t sign up on both or you will make us cry.

We’re not announcing where the fan parties are going to be until we have a count of people.

– Ron

For Immediate Release Fri, 13 Jan 2017 11:29:00 -0500

State Of The Game #4 Thu, 12 Jan 2017 11:09:00 -0500

It’s time for another action packed State of the Game post!  Gather around the radio, turn up the volume, get grandma in the rocking chair, and let’s begin.

A lot has changed since Gary and I sat across from each other at lunch and joking said “Let’s do a Kickstarter”, followed by an awkward moment of silence where we both realized it wasn’t a joke.

Would anyone want to play a point-and-click adventure? Would they appreciate the classic nine-verb SCUMM interface? Could we build a game that was how you remember those old game, not how they actually were?  Could we grab a new generation of gamers and shed them of their misgivings about what a point-and-click adventure is?

Well, we were a mere months away from finding out.  It’s been a long journey, one that you have shared with us, encouraged us, and held us honest throughout.  I can honestly say, Thimbleweed Park is a better game for having you all here.  And I’m not just blowing smoke up your *beep*.  I’m not that kind of person.

Since our last State of the Game post, we’ve gone into content lock, meaning all the art is done, all the sound and music is done, and all the puzzles wired up.

We still continue to test and an occasional bug is found where we have to tweak one of the above, but we’re not making any more changes or adding any new content.

We’ve set a date of January 27 as an engine lock for Mac, Windows, Linux and Xbox.  At that point the engine is done and we’re adding no new engine code.  We will continue to test and if showstopper bugs are found, they will be fixed, but we’re done with the engine.

That is also the version we will submit to Microsoft for Xbox cert, which can take a month.

We’re in the process of getting our coming soon Steam page set up, so hopefully that will go live in the near future.

Thimbleweed Park runs on iOS and Android, but we’re not actively working on them, there is just too much to do to get the game done on the core platforms.  They will probably come out a few months later.

We haven’t announced anything with PS4, but our intentions are to release there was well. As I’ve mentioned in the past, Microsoft has a three month exclusive, so it will be at least three months after the core platforms.  Our Microsoft deal also specifies that we can’t release on any other platform before the Xbox, so Mac, Windows, Linux and Xbox will all release at the same time.   It’s not really holding anything back, it’s actually giving us breathing room on for getting the Steam builds tight.

The big news over the past few months is the voice acting.  I could write a whole book about the the voice acting (henceforth known as Clusterfuck #1). It has nothing to do with the voice actors, they were all marvelous.  As much as I’d love to shift blame to someone else (I’m taking volunteers), it rests solely on my shoulders.

I contemplated writing about this earlier, but decided to wait and see how it all panned out. Writing about clusterfucks while they are happening invites too much second-guessing (on everyone’s part).

We did our first casting back in March, when we did the trailer for Ray.  It’s important to remember that Thimbleweed Park has 47 speaking roles, and that is a lot to cast for.  My goal was to cast here in Seattle and use local actors.

We did the casting for Ray and then I planned on doing a full casting in June and the first recording session in time to have voice in for the demo we showed at Seattle PAX.  June came and I was overwhelmed with work, and June became July, we did a first pass at casting, but just weren’t finding the talent, then I became overwhelmed with everything else and pretended none of this was happening.  Oh yeah, and a shit-bag was elected president and that didn’t help (note to self: get the Russian translations done ASAP).

So now June has become late October and we still don’t have the game cast. Panic is at DEFCON 1.

We eventually decided to cast in Vancouver Canada (also known as TV America) and within a few weeks had the game cast and were ready to roll.   The actor who plays Delores is in Seattle, so we recorded her at Bad Animals in Seattle (fun fact: after casting her, she became the Thimbleweed Park sound designer and so is basically the real life Delores).

There is a character in the game who is German and no one we auditioned could do a German accent that didn’t sound like something out of Hogan’s Heroes.  I contacted Tom Kerstin at Daedalic to see if he could help, and he got in touch with an actor and studio in Germany. Many thanks for that.

In Vancouver we recorded at Studio X Labs, which coincidentally is the same place we recorded DeathSpank.  I went up to Vancouver for a week and we record everyday for 8 hours.  Union actors work in 4 hour stints, so we couldn’t record (for example) Reyes for 8 hours each day, we had to split it with other actors and the other roles.

Only the five keys roles needed more than 4 hours, we got everyone else in one 4 hour session.

To record, we’d run though the script and the actor would read each line twice and I’d mark the take I liked, or marked it for pickup. We’d go through around 30 lines, then go back and grab anything anything I’d mark.  Ransome’s voice was hard on the actor who played him, so after the first session we had him do each line once, rather than twice. He was amazing, so I rarely needed a retake.

That’s the thing about working with pro-actors. They are really good at reading a script and can do 95% of their lines in one take.

All the actors on Thimbleweed Park was a pleasure to work with.

After my week in Vancouver, I came home and we spent the next 3 weeks recording with me calling in on Skype.  All in all, it took 5 weeks to record over 16,000 lines.

Which gets me to the other clusterfuck on my part.  Lauren, David, Jenn and myself wrote way way too much.  I was mentally keeping track of the lines in my head, and I completely misestimated by a factor of 2.  When I first pulled the text and saw how many lines where were, I was shocked and mortified.

Initially, there were more than 16,000 lines (with a third of them needing to be recorded 5 times), so we went through the whole game and blocked characters from going into specific areas they didn’t need to go, mostly to save recording.  I don’t think players will really notice it. We always gave charaters a good reason for not going somewhere and made sure it wouldn’t make a puzzle frustrating.

An example is keeping Ransome out of the Cemetery. There is no puzzle reason for him to go there and we gave him a plausible excuse for not wanting to go in there, so it seems natural.

So, lessons learned (that I already knew but didn’t follow):

    1 – Cast early and set a deadline and stick to it.
    2 – Pull a script early and often so you have a real line count.

After recording was done, it’s taken another two weeks to go through and cut, clip and process all the dialogue. It’s in the game now and it’s been transformational. It is so amazing to hear everyone speak.


Boris has started the German translation a month ago and a few weeks later we hired the translators for French, Italian and Spanish. They are all on our Slack, so it’s fun to chat about odd issues that come up. Each of them has a copy of the game they can debug jump to any room and hot load their translation as they write them.  The translations are all scheduled to be done by the 27th.

We are now fully into the final stages setting up all the marketing and PR. Do not underestimate the importance of these two things, they are just as important as building a great game. But those will have to wait for another post.

So, the bottom line is our evil plan is finally coming together to make a point-and-click adventure game that feels fresh and modern without running from anything that made those games so great.

Thanks for being a part of it.

– Ron

1084 Library Books Reviewed! Thu, 29 Dec 2016 18:41:00 -0500

When we asked people for some library books to fill up the Edmund Mansion mansion library, we weren’t expecting such an overwhelming response. We’re really amazed by the creativity and time so many people took to write a book for us.

We received 1084 entries. As part-coder, part-jack-of-all-trades, I pulled the shortest straw and had to read through all the books. I read through around 80 books a day, which took around an hour and a half. At that rate, it took me 14 days to finish all the books. Due to the sheer volume of books, I wasn’t doing any sort of grammatical or spelling checks. Whatever people wrote is pretty much how it will end up in the game.

I was looking for anachronisms, inappropriate content, puzzle spoilers or red herrings, things that didn’t work within the world of Thimbleweed Park. Many books I only skimmed and didn’t get to absorb their awesomeness.

Out of the 1084 entries, 997 were ok on the first pass, 16 were duplicates (entries that someone submitted twice, presumably to fix mistakes), 11 were in a language other than English, 55 needed review and 5 were definite cuts.

Although we’d spoken about letting people translate their entries into other languages, the sheer number of people involved and coordinating that has meant we’ve decided against that. We used Google translate to check the 11 entries not in English to check that there weren’t any issues. All of them were given the go ahead.

For the 55 books for review, we went through them all and talked about why we should or shouldn’t accept them. We had to edit some to remove minor issues, anachronisms or author names that might lead to lawyers needing to be paid.

In the end we have a total of 1056 books in the library. That is, only 12 books were cut completely from the game! That’s an impressive amount of content, much of it great quality.

We still need to go through and make sure the books fit on the page-art for the most part. But know that if you submitted a library book, it’s mostly likely you’ll be able to find it in the game!

Although I couldn’t take the time to fully read all the entries as I skimmed them, two entries stick out in my mind as my favourites. So in the interests of giving you a sneak peak into how amazing our fans are, I’m going to share those two books with you.

First up is a book sent in by Dinko Galetic in the “Short Stories” section. It’s called “Flash Fiction Anthology” by Various Authors:

My other favourite was a book sent in by Synne H. Rustad, it’s called “Everyday Enchantments” by Synne Cinnamon.

– Jenn

Seckrit PAX Footage Wed, 28 Dec 2016 21:03:00 -0500

Once we’re back from the holidays, I’ll do a post on the voice recording, but in the meantime, enjoy this Seckrit footage from PAX.

Thimbleweed Park Podcast #64 Sun, 18 Dec 2016 13:00:00 -0500

Join us and our special guest, Boris, as we talk about text and translations and voice recording. And *beep* you if you don’t like that.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Tutorials Mon, 28 Nov 2016 18:19:00 -0500

I hate tutorials. I really hate tutorials. Let me just get that out of the way.

OK, now all that said, I just got done adding the tutorial to Thimbleweed Park.

Working on tutorials isn’t something that I hate, it’s something that actually makes me angry.  Tutorials have about as much place in narrative games as they do in a movie. Can you imagine sitting down to watch a film and having pop-ups come on screen to tell you who the protagonist was and when a plot point happened?

Now, the big difference in a movie and a game is, when watching a movie you just sit there. Understanding the movie might affect your enjoyment, but not understanding who the protagonist is doesn’t cause the film to stop, or move in slow motion.  I will grant you that.

I think the main reason I hate tutorials is they are conditioning players to be un-inquisitive. Modern players often expect to be led through the experience, and it’s starting to go beyond just the tutorial, but into the game itself. Some players don’t want to explore, they want to be told where to go and what to do.  They are being conditioned to do only what they are told to do.

For me, part of the enjoyment of starting a new game is figuring out what I can and cannot do. I enjoy exploring the bounds of the game. I want to feel clever when I figure out a short cut.

The problem Thimbleweed Park (and any point and click adventure) has is that it’s complex. Not just in the logic, but the UI.

In the good old days, it would take 20 minutes to install the game from floppy, so to kill some time, we’d read the manual.

Today, players just jump right into the game and a large share of them are immediately frustrated when they don’t know exactly what to do (I’m not talking about the puzzles, but what to click on and how).

If you’re well versed in the language of adventure games, then it’s quite self evident, but if you’re new to adventure games, it can be a little unwieldy.  Part of the goal of Thimbleweed Park is to convince a large group of people that love narrative games, but don’t play point-and-click games, to give Thimbleweed park a shot.  If you liked Firewatch or Gone Home, you’ll love Thimbleweed Park.

But, Thimbleweed Park is a lot more complex than either of those two games and can be daunting to a new-to-point-and-click player.

For those people, I think we need a tutorial (please understand I can came to this conclusion kicking and screaming).

Since the beginning, the story of Thimbleweed Park started out in this little self-contained area, and we designed the first few puzzles to teach you the basics: opening a door, talking to someone, picking up objects and using them.

While this steps a new player through the basics early on, it’s not telling you “how” to do these things and that is where a small, lightweight tutorial comes in.  “This is how you open a door” and “this is how you pickup an object and use it”.

How to do these thins probably seems obvious to everyone reading this blog, but if you’ve never played a point-and-click adventure before, it’s actually not.  You couple this with some players reluctance to just explore the UI and it’s going to be tears all around (mostly from me when I have to go get a real job).

The compromise I reached with myself is: the tutorial will only happen in “easy” mode. If you select hard mode and dive right in, we’re going to assume you know what you’re doing, or you don’t mind a good challenge.

I felt dirty for a day, then took a good shower and now I feel fine.

We’re hoping to get a chance to test the tutorial out on casual players that have never played a point-and-click adventure. Given the circles we travel in, that’s harder than it might sound.

– Ron

Thimbleweed Park Podcast #63 Sat, 19 Nov 2016 12:36:00 -0500

Join us as we discuss the beeping beepers and beeping in general.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Zero Bugs Wed, 16 Nov 2016 12:58:00 -0500

We’ve reached the next important milestone in our quest to releasing a game, and it’s called Zero Bugs.

As of the 15th, we have zero bugs in our bug lists. That’s not to say the game has zero bugs (far from it), but we fixed everything, and if we didn’t fix it because it wasn’t that important, we closed it.

Zero Bugs.

Testers continue to test and file bugs, but the rule now is at the end of each day, there are zero bugs in the bug database.  We also take a hard look at the bugs coming in and decide whether to fix it or not.  Sometimes the bug isn’t that critical or it’s an edge case, so we just close it. Other bugs are just too dangerous to fix and they aren’t that important. If it was 2 months ago, we would fix it, but not now.

It’s important to clarify what we mean by bug.

If something crashes the game, or makes the game unplayable or is painfully ugly, it’s a A bug and we fix it.  If it’s just something that makes the game a little glitchy and it’s not common, that’s a B bug and we’ll fix it if there is time and it’s a safe fix.  Bugs that are unlikely that anyone would even notice or are rare edge cases, those are C bugs and usually just get closed.

We had a bug where sometimes (rarely) an actor would face the wrong direction when you gave them something. Fixing it would touch a lot of code and there was a high likelihood of breaking other code, so we opted to not fix it.  It the kind of bug you might see once in an entire playthrough.

We had another bug where the input and cursor were being turned off for a split second to keep the player from messing up a special-case animation, but a bug caused the input to be turned on prematurely and left on during a cut-scene.  It’s an edge case, but the consequences catastrophically break the game, so we had to fix that, despite needing to touch a lot of code to do so.

Testers still continue to report everything and we triage all the new bugs each day.

The thing about fixing bugs is, anytime to fix a bug, there is a likelihood you’ll introduce a new bug, so we don’t want to just keep fixing.  The goal is to get a completely stable version where testers aren’t finding any A or B bugs anymore.  The only way to accomplish that is to lock the code down as much as possible.

We want to say there will be no bugs in the game, but that’s just not realistic.  The game has close to 100,000 lines of code and that is only the game code, not the engine. It’s a complex beast.

There is a point where you have to say: we’re done.  If you don’t, you never finish.

That is the real reason for these milestones: to force us to make hard decisions and move on.

Now, all that said. The Zero bugs relates to the game code, there are still several open bugs related to the engine and platforms, but there don’t affect the game.  An example of one of these is, when you scale the screen for safe mode, garbage shows up along the edges. That has nothing to do with the game code, and is purely an engine issue, so it’s low priority. There are 10 or 20 such bugs, but we decided to focus on the game related bugs first.

I also have a big memory leak I need to find and fix. It’s not the kind of memory leak a leak detector will ever find, it’s memory the game is holding onto because it thinks it needs to, but doesn’t. That’s going to take me a few days of lock-myself-in-a-room-debugging to find.

There are also a lot of issues with the Xbox port, mostly related to Microsoft’s cert issues, but that’s probably a whole ‘nother blog post.

– Ron

Thimbleweed Park @ PAXAus Sun, 06 Nov 2016 00:37:00 -0400

We had a great time at the Thimbleweed Park community event in Melbourne.  We didn’t have a booth (apologies to those of you who wondered around the floor looking for us), but opted instead for a open event that anyone could come to and enjoy a nice drink.  We didn’t have the budget to ship our whole booth the Australia, or pay for booth space.

Instead, we took over a corner in a bar close to the convention center and set up a station for anyone to play.

It’s hard to say how many people came, there was another PAX event there, and it was still open to the public, but a lot of people came by to say hi and we had some great conversation about adventure games, pixels, Thimbleweed Park, Maniac Mansion, and Monkey Island.

Great fun all around!

We’re planning on a trip to Europe in January.  I don’t know where we’ll stop, budget is pretty limited, but we’ll do a few community events.

– Ron

Text Lock Thu, 27 Oct 2016 09:04:00 -0400

We’ve now entered the next phase along our wonderful journey to release a game, and it’s called Text Lock.

A few weeks ago we entered content complete, where all the art, animation, puzzles, and music were in the game and no more could be added.  Text lock means all the text is now final. We’ve made all the last minute edits, additions, and now we’re stuck with what we have. No more text changes.

The text in the game started out like this…

deloresRoomActionFigures2 =
    name =“action figures”
    verbLookAt = function()
        sayLine(delores, “These are part of my action figure collection, including my prized Howard the Duck.”)
    verbDefault = function()
        sayLine(delores, “These are in MINT CONDITION! No way I’m going to touch them.”)

A few months ago, I ran a series of python scripts and we got this…

deloresRoomActionFigures2 =
    name = NAME(0,“action figures”)
    verbLookAt = function()
        sayLine(delores, DELORES(0,“These are part of my action figure collection, including my prized Howard the Duck.”))
    verbDefault = function()
        sayLine(delores, DELORES(0,“These are in MINT CONDITION! No way I’m going to touch them.”))

Each line was wrapped in a MACRO, identifying who said the line and unique text id.  The text ids are set to 0, because they have not been extracted into the text DB yet. We lived with this for few weeks, making any changes to the text we needed.

There is also code in the game that displays a warning if it encountered any text that hadn’t been wrapped with the MACROs (the python program missed a few lines due to formatting).

Last week, I extracted all the text from the game, turning the lines into this…

deloresRoomActionFigures2 =
    name = NAME(27084,“action figures”)
    verbLookAt = function()
        sayLine(delores, DELORES(27342,“These are part of my action figure collection, including my prized Howard the Duck.”))
    verbDefault = function()
        sayLine(delores, DELORES(27341,“These are in MINT CONDITION! No way I’m going to touch them.”))

when the final python program was run, adding the text ids, a .tsv file (Tab Separated Values) was written out that looks like this (don’t be fooled, the actual file is 11,000 lines long)….

NAME 27084 action figures
DELORES 27342 These are part of my action figure collection, including my prized Howard the Duck.
DELORES 27341 These are in MINT CONDITION! No way I’m going to touch them.

The translators then translate the text in the .tsv file and the game loads a different file, depending on the language.

The text MACROs are pretty simple.

#macro NAME($a,$b) “@$a:$b”
#macro TEXT($a,$b) “@$a:$b”
#macro DELORES($a,$b) “@$a:$b”

During  preprocessing phase, they take the ID and the TEXT and merge it into a string…

“@27341:These are in MINT CONDITION! No way I’m going to touch them.”

The advantage is the text is still a simple string, easily passed around the code. When a sayLine command is called in the engine, it extracts the ID and looks up in the text DB and display the translated line.

Starting next week, the MACRO will be replaced with this…

#macro NAME($a,$b) “@$a”
#macro TEXT($a,$b) “@$a”
#macro DELORES($a,$b) “@$a”

All the text is removed from the preprocessed version of the code, so when the game ships, all the text has been removed, but it still stays in the source to make it easy for us.

We have several macros to help the translator and also to make script extraction for voice recording easy:

// Text that is displayed, but never voiced
#macro TEXT($a,$b) “@$a:$b”

// Names of objects.
#macro NAME($a,$b) “@$a:$b”

// Text that appears in art, but never appears as text strings.
#macro ART($a,$b) “”

// Text that would be said, but is never voice, like some dialog choices that are never echoed back.
// Translators need to translate it, but voice actors don’t need to record it.
#macro NOTALK($a,$b) “@$a:$b”

// Text displayed on computer screens in the game.
#macro TERM($a,$b) “@$a:$b”

// System text, such as the options screens.
#macro SYSTEM($a,$b) “@$a:$b”

// Ray and Reyes
#macro AGENT($a,$b) “@$a:$b”

// Agents and Delores. Useful when Ransome has an alt line.
#macro PLAYER_AD($a,$b) “@$a:$b”

// Agents and Ransome. Probably not used a lot.
#macro PLAYER_AR($a,$b) “@$a:$b”

// Agents, Delores and Ransome. This will be the most common in the world, not in the hotel.
#macro PLAYER_ADR($a,$b) “@$a:$b”

// Delores and Ransome. Useful if the agents have a separate sayLine.
#macro PLAYER_DR($a,$b) “@$a:$b”

// Everyone. Probably used in the Hotel.
#macro PLAYER_ADRF($a,$b) “@$a:$b”

// Agents, Delores and Franklin. Ransome alt lines in the hotel.
#macro PLAYER_ADF($a,$b) “@$a:$b”

// Agents, Ransome and Franklin. Delores alt lines in the hotel.
#macro PLAYER_ARF($a,$b) “@$a:$b”

// Lines said by only one character
#macro RAY($a,$b) “@$a:$b”
#macro REYES($a,$b) “@$a:$b”
#macro RANSOME($a,$b) “@$a:$b”
#macro DELORES($a,$b) “@$a:$b”
#macro FRANKLIN($a,$b) “@$a:$b”

Text wrapping can get complex. but we need it this way to extract scripts for recording. If the game wasn’t voiced, we could get away with just a TEXT macro, or maybe just the character ones to help the translator, but since the game is not only voiced, but has five playable characters, all who might or might not be saying the same lines, it gets complex.

Now that everything has been extracted and numbers, the file is off to Boris and he’s started the German translation. In a couple of weeks, I’ll hand it off to the other translators. I wanted to use Boris as a test case, to make sure everything was working before we had five people doing translation.

Like content complete, text lock is an important milestone. It’s not only important in that it gives us a goal to push for, but it’s also important just from the point of discipline.  We could make art and text tweaks forever and each one would make the game -1% to 1% better.  There comes a point where you just need to stop and that is what these milestone are for. They are saying, it’s time to move on.

Now, occasionally, we will come across a line of text that NEEDS to change.  If it’s just a typo or spelling error, we just make it since it doesn’t affect the translators or the voice actors.

But if it changes the meaning of the line, or a new lines MUST be added, we have the following process.

The first step is to talk about it, make sure we really need to add or change the line. The second step is to see if there is an existing line that will work just as well, or at least 75% as well.  The final stage is to change or add the line, but we mark is as follows…

sayLine(delores, DELORES(0,“**These are in CRAPPY CONDITION! I should sell them.”))

If this is the only place in the game the line was used, we’ll leave the text id. If there are other places that still need the old line, we’ll reset the id to 0.

At some point a few weeks from now, I’ll rerun the extractor and pull all the lines that have “**” and send them to the translators. If voice recording has already happened, they get add to the lines for the pick-up session.

And that’s all there is. Making games is easy.

– Ron

Thimbleweed Park Down Under Mon, 24 Oct 2016 23:54:00 -0400

We’re heading to PAX Australia (with a stop over at GCAP) next week and we’ll be doing a small community event where you can have the opportunity to play a little Thimbleweed Park. It’s an adventure game, perhaps you’ve heard of it?

All the detail are on our Facebook page because that’s where all the cool kids are.

Hope to see you in Melbourne on the 5th.

We’re planning some more events in Europe, in the coming months.

– Ron

Thimbleweed Park Podcast #62 Sat, 22 Oct 2016 14:28:00 -0400

Join us for the amazing podcast where I forgot to press the record button.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

No Podcast This Week Sat, 15 Oct 2016 10:21:00 -0400

I hope everyone remembers where they kept their pitchforks, tar and feathers, because there is going to be no podcast this week.

As I mention in the last action-packed Thimbleweed Park dev blog update, we are heading for content complete today (in reality, we’ll have tomorrow), and everyone is completely slammed.

Content complete is looking good, I think we’ll make it, but not without a little fudging.  Some tasks are being pushed out because, “yeah, we could ship without that”, in reality, it would pain us to do so. We’ll quickly scramble to hit those post CC, because, yeah, we could ship without it.

As I mention in the last post, deadlines like content complete are important because it keep everyone laser focused.  If you hit 90% of the milestone, you’re doing good. If you didn’t have the milestone and the laser focus, you’d never get anything done.

If we had a publisher, there would be payments tied to the milestone. Until the milestone was met, we wouldn’t get the next check and couldn’t pay people. That’s always a big motivator.

We don’t have a publisher, so there are no payments tied to the milestone, but we have a very limited (and at this point, tight) budget. We can’t just keep going, because we’ll run out of money to pay people.  Same thing, really.

But honestly, even if we had a ton of money left, we’d still be pushing for these milestones. We want to get the game done as much as you want to play it.

Anyway… no podcast this week.

– Ron

Thimbleweed Park on the iPhone Tue, 11 Oct 2016 19:13:00 -0400

Thimbleweed Park is running on both the iPhone and Android. With no UI changes, it’s surprisingly playable, even on a small screen. We’re planning on several changes that make touch work better, but still retain the classic UI feel.

It’s still along ways off, but here is a sneak preview.

Joost, our Linux programmer did both the ports.

Content Complete Thu, 06 Oct 2016 12:38:00 -0400

It’s been a busy last few weeks.  The stress is really starting to get to me. I don’t handle stress well.  I tend to become hyper-focused on the cause of stress, which often makes it worse. There is nothing more or less stressful about finishing Thimbleweed Park than any other game I’ve done. It always happens.

When it gets to this point, I always say “I’ll never do this again”, then I do.

On October 15th, we’re scheduled to hit “content complete”. Every project and company has a different definition for content complete, mine is: every piece of art, animation, sound, music and puzzle is in the game. If not for bugs, you could ship the game.

Content complete is important, because up to that point, you’re probably creating more bugs then you’re fixing. After content complete, it should be about fixing bugs. The list should always be getting smaller, not bigger.

I also think content complete is an important milestone because it forces you to finish the damn game. I come across so many indie developers that don’t know how to finish, they keep adding and changing. Having a firm date you drive towards is important, you won’t ever finish without it.

We could work on Thimbleweed Park for two more years. It would make the game different, but probably not better. Just finish your damn game.

October 15th: Content complete. Oh shit, that’s 5 days away. We’re screwed.

No, we’re fine. We always are.

I extracted all the text a few weeks ago and was shocked.

There are over 16,000 recordable lines in the game. That’s twice what I expected. It was a “oh shit” moment.

Since then we’ve gone through the game and found a lot of places where all 5 characters are saying something, but realized that only one of them will ever actually say it. We’ve also found several places where it’s easy (and makes sense from a game/story standpoint) to block a character from a small section of the world. This has also saved a lot of dialog. We were also letting all 5 characters do stuff that is “official binsness” that only the agents should be doing. That has also saved dialog.

It’s still going to end up being 50% more dialog than I expected, and that’s going to put budget pressure on us, but it should be fine.

In hindsight, I should have realized this. In hindsight, I should have been extracting the dialog on a monthly basis and keeping a better eye on it.  Writing is fun. We used to say “dialog is free”, but that’s no longer the case.

– Ron

Thimbleweed Park Podcast #61 Fri, 30 Sep 2016 09:43:00 -0400


You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Podcast Delay Sun, 25 Sep 2016 15:23:00 -0400

I caught a bad cold last week that I am just now getting over.  Due to feeling like crap, and having a voice to match, we didn’t record the Friday Questions podcast. We’ll record it on Monday and I’ll have it edited and posted by Tuesday.

Sorry for the inconvenience.


I’m feeling better. We recorded the podcast yesterday. I need to fly to Argentina tomorrow, so I’ll edit it on the plane and upload it when I get there. Scrambling to get everything done before leave.

– Ron

Friday Questions Wed, 21 Sep 2016 12:09:00 -0400

It’s time for Friday questions!

Things are crazy around Team Thimbleweed right now, but we’ll take the time off to do a Friday Questions podcast.

Make the questions good and remember, only one question per comment.

– Ron


Final Phonebook Import Mon, 19 Sep 2016 13:57:00 -0400

Over the weekend, I did a final import of the phonebook and voicemails.

Here are the stats:

Total names in phonebook: 3457
Total voicemail messages: 1848

Never entered a name: 457 (not included in counts above)

Total size of all messages (uncompressed): 2.72G
Total size of all messages (processed, compressed): 166M

Of the 1848 VM files, 7 were uploaded corrupt and couldn’t be converted (or even listen to).  Since it was a small number, we’ll email those people to get us new files.

3 people have incomplete information. It looks like they started, but never finished.  They will also get an email.

27 backers went to the webpage, but never entered information. Over the course of the past 6 months, we’ve sent out a lot of reminders, so they will not be included.

We have not done a vetting of all the VM to see if any are obscene or violate the rules. Of the few hundred I’ve listen to so far, they all are fine. I’m optimistic that very very few (if any) will be culled.

There is a drastic range of recording quality (as you’d expect on a real VM), so some of them might be hard to understand.  They were all normalized to try and get a consistent volume. I’m sure we could spend a lot more time processing the recordings, but we also have a game to make.

Thanks to all the Kickstarter backers who submitting voicemail messages. There is an achievement for listening to all 1848 of them. Have fun with that.

– Ron

Title Cards Wed, 14 Sep 2016 16:24:00 -0400

Several months ago, there was a lot of chatter on the blog about if we were going to have title cards showing the acts or parts, like Monkey Island had.

I’ve been against them from the beginning. It just didn’t feel like it fit the game, but as time moved on and the scope of the game and story became apparent, I’ve changed my mind.

For those of you clamoring for title cards, I’m happy to report they are in the game. I started by using them to break up the acts, but soon realized that wasn’t enough.

Thimbleweed Park (for better or worse) is a big game. It’s not only big, but it’s a complex story that weaves around, pretending to be one thing, then veering off to be another, and then juts in an unexpected direction just when you think you’ve figured it out.

It’s a complex story.

One thing we noticed while playtesting is there are these big story beats, and while the story felt good at those locations, the game became a little unfocused.  The title cards help to return that focus without long expository cut-scenes. The cards are short and simple and say “Hey! This is where we’re going”.  It also gives players a sense of progress and completion, despite not knowing how many parts there are.

So, there you go.

– Ron

Thimbleweed Park Podcast #60 Wed, 07 Sep 2016 21:25:00 -0400

The Trump campaign is in complete disarray after a surprise Wednesday Thimbleweed Park podcast.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

More PAX West Tue, 06 Sep 2016 14:14:00 -0400

More exciting pictures from Thimbleweed Park at PAX West.  PAX West was four days and the forth day was grueling, but the excitement and energy around the booth kept us going.

Like PAX East, we had four stations that remained full right up to closing time when we had to kick people off.  At PAX East we had a long line of people waiting to play, but for west we created a signup list, so people could get their name on it and then go off for a bit and come back. Hard to tell for sure, but it seem to work a lot better.

It was great to meet so many backers and blog readers.  We also had a lot of people come up that had never heard of the game before, but they were big Monkey Island and Maniac Mansion fans. We also had people that had never really played adventure games before, so it was nice to see their reaction.  Much disappointment that the game wasn’t out yet.

But all good things must come to an end, and it was time to dismantle the booth. It took up a whole day to set up and a little more than an hour to tear down.

Everything packed into my Jeep ready for storage until next time.

Thanks to David and Chase for watching the booth and helping get people signed up and playing. Thanks to our friends Sophie and Owen who took some shifts and helped out.  Elise, who does the voice for Delores, even stopped by to help out for a few hours.  And huge thanks to ThimbleTeam member Jenn who designed and organized the booth and all our merch.

And most of all, thanks to everyone that stopped by to say hi and play the game.

We’re trying to figure out how to do something like this in Europe. The logistic are a lot harder and it’s quite a bit more expensive, but we’re thinking… we’ve got our smart-glasses on.

– Ron

PAX Setup Sat, 03 Sep 2016 11:09:00 -0400

I don’t have time to write a lengthy post today, so I thought I’d show some pictures of your PAX booth setup:

– Ron

PAX West 2016 Tue, 30 Aug 2016 13:45:00 -0400

The Library Is Closed Mon, 29 Aug 2016 12:26:00 -0400

BREAKING NEWS: The new book count is 1082. Amazing job everyone!

UPDATE UPDATE: The mansion mansion library is now closed. This time for realz.

UPDATE: Due to some (ok, a lot) of confusions about submissions be closed the 29th being the beginning of the day, not the end, I’m going to open them back up until Aug 30th at 6:00pm PDT.   No second chancies.

BONUS POINTS: If you write about Health or Sports.

– Ron

The Library is now closed!  (not really, see above)

You submitted a total of 926 entries. This number is probably a little high due to some people submitting the same book 2 or 3 times with corrections, but it’s close.

We currently have room for 261 books, but it’s pretty easy to increase the number of books, so we’ll do our best to get everyone in.

The sections aren’t the same physical size, some of are small and only have rooms for a few books, others are large, so we can fit the smaller book counts into the smaller sections.

The breakdown of sections is…

Adventure: 95
Mystery: 90
Sci-fi: 74
Non-fiction: 69
Self Help: 64
Romance: 50
Short Stories: 50
Crime: 43
Autobiographies: 40
Young Adult Fiction: 40
Cooking and Food: 35
Poetry: 35
Programming: 33
Physics and Astronomy: 26
Jokes and Humor: 25
Travel: 25
Arts and Entertainment: 22
Nature: 20
Math: 17
Robotics: 17
Biology: 15
Business: 15
Home and Garden: 13
Health: 7
Sports and Outdoors: 6

PAX is this week, so I won’t be able to get anything into the game until next week. Once I do, I might open it back up for selected sections.

If we need more books, we might open it back up with just the sections that need books.  It will be a few weeks before we know that information.

Thanks to everyone who submitted. It’s going to be a fun library.

– Ron

UI Changes Wed, 24 Aug 2016 16:38:00 -0400

Time for another fascinating and action packed Thimbleweed Park dev video.  This time we’re going to talk about our latest change to the ui…. removing the sentence line.

I resisted making this change for quite a while, but when I finally got around to doing it, and played the game for 10 minutes, it became clear this was the right thing to do. Everyone who’s played the game since likes the change a lot.

We’ve done some playtests since this change and it’s interesting because no one comments on it. When I bring it up at the end of the playtest, there is a little bit of shock that they didn’t even notice. It just felt right.

I guess that’s a good thing.

– Ron

P.S. Here is a bonus GIF to show what happens when the cursor gets to the edge of the screen, since a lot of people are asking about that.

Thimbleweed Park Podcast #59 Mon, 22 Aug 2016 13:49:00 -0400

Sorry for the delay in this week’s podcast, I was up hiking at Mount Rainier this weekend.

P.S. If you’re thinking about making a Zak McKracken joke, you’ll be the 537th person to do that.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Meet Delores Wed, 17 Aug 2016 13:02:00 -0400

It’s time for a new action packed Thimbleweed Park trailer to help celebrate that we’re at Gamescom and we’re going to be showing the game in the Indie MEGABOOTH at PAX West.

It’s time to meet everyone’s favorite aspiring 80’s game designer and heiress to the pillow factory fortune… Delores Edmund.

– Ron

Get Your Creative On Thu, 11 Aug 2016 14:52:00 -0400

With the amazing success of the Occult Bookstore book name crowdsourcing, we’ve decided to go back to the creative well again, but this time it’s going to be more interesting (and more work).

The library in the mansion mansion contains around 100 books and not only do we need to name them all, we need two pages of text.  When the player explores the mansion mansion library, they can look at any of the books and they’ll get a close up showing two side-by-side pages. Players can’t turn the pages, but the two pages can be from anywhere in the book. Imagine grabbing a book and just flipping it open.

Some of the books will be written by us and include background lore for the story and characters, but we also need books that are just fun to read and explore.

And that is where you come in.  Make up a book, give it a title, and an author (that can be you), and write two pages of text consisting of around 100 words each. It’s that simple.  If your book is accepted, you’ll also appear in the credits.

To submit your entries, you need to use this Google Form.  Feel free to also post your books in the comments for everyone to read (or not), but if you don’t submit them through the approved form, they won’t make it into the game.

The rules are pretty simple:

1) Two pages of text. Each page is around 100 words and less than 650 characters.
2) Must be your original work. No public domain works.
3) Must have a title (25 characters or less).
4) Optional author and that can be made up, someone from history, or you.
5) Don’t use copyrighted works or characters, including the author’s name.
6) Must be 1987 appropriate.
7) Keep the content G or PG-13.
8) Books must be in English, but they will be translated.

Once again, submit all book entries HERE.

So… put on your smart glasses, grab a pencil, and most of all, have fun and be as serious or funny as you want.

The deadline is August 29th, 2016.

– Ron

Gamescom and PAX 2016 Wed, 10 Aug 2016 17:45:00 -0400

Happy to announce we’ll be at Gamescom next week and PAX west in a few weeks.  The Thimbleweed Park demo will be fully playable at both events.

At Gamescom, Thimbleweed Park will be showing in the Microsoft consumer booth (hall 8) on the Xbox One. Our lead tester, Robert Megone, will be there to help and answer any questions you have about the game, like: “Rob? Are you worried about the game being too awesome?”

Microsoft inviting us to show Thimbleweed Park in their booth shows a lot of support for the game.

At PAX, Thimbleweed Park will be shown on PC and will have multiple stations for pointing and clicking.  As PAX gets closer, we’ll have more information.

OK, back to the salt mines.  Kickstarter backers demanded more salt.

– Ron

Last 24 Hours!!! Mon, 08 Aug 2016 12:34:00 -0400

These are your last 24 hours to back Thimbleweed Park and make an awesome game even awesomer.

In 24 hours we’re shutting down all backing. Last 24 hours to get in Ransome’s swear jar! Last 24 hours to get guilt absolution for pirating Monkey Island or Maniac Mansion! Last 24 hours to feel awesome about yourself!

If you want to upgrade your previous pledge, please contact

But please note… These are not pre-orders! If all you want to do is pre-order the game, wait until closer to release. We have not set the final price for the game and it could be less than our lowest tier.  What you’re doing is supporting and helping to make a great game.  You’re bringing joy and point-and-click adventures to the world. Can you really put a price on that?

You’re also getting guilt absolution, but that is between you and your god.

– Ron

Thimbleweed Park Podcast #58 Sat, 06 Aug 2016 15:29:00 -0400

So amateurish and poorly edited, you know it’s authentic.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Friday Questions Thu, 04 Aug 2016 09:17:00 -0400

It’s time for Friday questions!

Bla bla bla… I’m sure you’re as excited as we are… bla bla bla.

One question per entry.  Bla bla bla.

Bla bla bla bla. Bla bla. Bla bla bla, bla bla.

Bla bla bla.  🙂  Bla! Bla!

– Ron


Time-lapse of Agent Ray Mon, 01 Aug 2016 13:16:00 -0400

Here is a time-lapse video from master pixel animator Octavi Navarro showing how he animated Agent Ray waking up after SPOILER!

– Ron

Books Desktop Sat, 30 Jul 2016 22:16:00 -0400

There will be no podcast this week. We’re going to be recording them once every two weeks, rather than every week.  They take 2 or 3 hours to record, edit and post and as we near the end of the project, things are getting crazy and time becomes a precious commodity.

Next week will be our Friday Questions episode, so save your brilliantly insightful questions for next week.  I’ll do a post on Wednesday asking for questions, so don’t ask them here.

As a consolation prize for not having a podcast, here is a new desktop wallpaper.


– Ron

Last Week To Become A Backer Thu, 28 Jul 2016 12:51:00 -0400

We’re going to be cutting off the ability to back Thimbleweed Park on August 7th, so if you want to help support the game and (maybe) get some cool stuff (or just feel awesome about yourself), time is quickly running out.

A huge huge round of thanks to everyone who backed Thimbleweed Park during the Kickstarter and after. The extra money really has made the game better.

But, as we’re getting closer to shipping, it’s time to end the fun, wrap the game up, and release it for everyone to play in early 2017.  It seems like forever, but it’s only a few months of panic, fear, and stress away.

We want to reiterate, backing is not a pre-order. If all you want is to pre-order the game, then we suggest waiting. We have not set the final price for the game and it might be less than our lowest backing tier. What backer support does is help make the game be the best it can be, by giving us extra money to throw at art, music, animation and programming.

Thanks again to everyone who supported and made Thimbleweed Park possible. Even if you couldn’t or can’t afford to back the game, your enthusiasm has also been invaluable.

– Ron

Cemetery Wed, 27 Jul 2016 12:50:00 -0400

We added a cemetery to the game. The decision was made a few months ago, but we only just got the art.  I thought I’d talk about why we added it so late and the decisions that lead up to that.

I’m going to dance around a few spoilers here, so bare (or is it bear… English is stupid) with me.

There are a lot of dead people in Thimbleweed Park, it’s a twisty little mystery that begins with the body found in the river just outside of town.  A few days before our story gets started, the owner of the local pillow factory, beloved founding father of Thimbleweed Park, and Delores’s Uncle, died of a heart attack. It’s an important plot point, but just mentioning it in dialog wasn’t getting the it across.

There is an old adage: show don’t tell.  So what we decided to do was add a cemetery that you come across before entering the town that has a giant tomb, adorned with flowers from the recent funeral, for our beloved town leader.

Once we added the cemetery, other ideas started to pop up. There was a puzzle chain involving Franklin that always felt a little contrived, and now that we had a cemetery, we could adjust the puzzle to make it more interesting.

Franklin, being a ghost who’s stuck in the hotel always limited his usefulness. Adding the cemetery provided a (logical) place that he could go beyond the hotel. So, we add another puzzle to allow him to move between the two places.

Another benefit of the cemetery was it made the reading of Delores’s Uncle’s will a lot more interesting, since it could take place in his tomb and added a new puzzle to get into the tomb.

The cemetery started out as an idea to solve a story issue, but blossomed into a great room that added several new and interesting puzzles.

Also, cemeteries are cool.

– Ron

Thimbleweed Park Podcast #57 Sun, 24 Jul 2016 12:23:00 -0400

Capping a very busy week on Team Thimbleweed, it’s a podcast.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Thimbleweed Park Podcast #56 Sun, 17 Jul 2016 11:04:00 -0400

It’s a podcast. About Thimbleweed Park. It’s the 56th one. You don’t need to know anything more.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Eyes Tue, 12 Jul 2016 12:26:00 -0400

In the original Maniac Mansion, heads were large because pixels on the C64 were very huge. Due to the color mode we were using, they were not even square pixels, they were twice as wide as tall.  The hardware sprites each character had to fit in were 24 pixel wides, so Gary just made the heads as wide as he could to capture the personality of the characters.

There are huge parts of our brains that are dedicated to recognizing faces and subtle movements and expresses. How do I know this? Because I’m not only a game designer, I’m also an evolutionary neurological cognitive brain scientist. Look it up.

When Zak came out, the heads were shrunk to be “more realistic”. By the time Monkey Island was made, the heads had gotten even smaller.  True, it was more realistic, but I felt something was lost.

Guybrush didn’t blink and he didn’t move his eyes (except in some special case animations).  Razor, Bernard and Micheal didn’t blink either. Or move their eyes. Everyone stared straight ahead like zombies.

A month ago we added blinking to the Thimbleweed Park characters and it really changed how you feel about the game being alive. When someone is just standing, the blinking makes them feel real. If you were playing the game, you might not even notice it at a conscience level, but it’s something you’d feel.

Last week I added eye movement. Characters can now look left and right. It adds a lot to even idles, as the characters appear to be looking around, aware of the environment. It’s also really nice in conversations, because characters can actual look at who is talking to them. Before (and in previous games), characters would just stare forward. It’s surprising how used to this you get, and when blinking and eye movement goes in, it’s actually startling.

– Ron

Thimbleweed Park Podcast #55 Sun, 10 Jul 2016 12:07:00 -0400

Join us this week for a delayed podcast where David keeps dropping the M-bomb, so this one might not be family friendly. Have you talked to your kids about mazes?

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

My Mac Crashed Again Sat, 09 Jul 2016 12:54:00 -0400

My Mac crashed again and won’t fully boot, saying the drive is corrupt.  I now suspect it’s Photoshop that is causing this.  The last time this happened, the night before I was working on a huge file and Photoshop started to tell me the file was too big, and then it was reporting it was unable to save the file.  The next day, my machine wouldn’t fully boot due to the keychain being corrupt.

This morning, I was working on a large Photoshop file and I started to get the same errors, when I rebooted, my keychain was corrupt.

I’m going to head into the Apple store and see if they can fix it without a reformat this time.

Why am I telling you this?  Because I was going to put up the new podcast and that might not happen.


Back from the Apple store with a freshly reformatted machine and time machine pulled everything back.

I mentioned to the Genius Bar tech person that this is the second time it’s hard crashed from editing a large file in Photoshop and he said “oh…”, then we had a conversation that I can only assume was “off the record” by the way he spoke, tell me other people have reported drive corruption when extremely large files are process by fusion drives.

Yeah… no kidding.

I’ll do a little Googling and see if I can find anything. Like I said in my previous post, I don’t trust fusion drives and I guess with good reason.

I do need to re-edit the podcast, so that will go up tomorrow.

– Ron

Win! Win! Winners! Mon, 27 Jun 2016 16:21:00 -0400

It’s time for the phonebook winners.

From last week, then winners where:


And the answer to the number of R entires is…



We had several ties, so rather then rolling a dice and making some people cry, we’re going to do the nice thing, because that is who we are.

Francois Mercier
Michael Kohlhaas
Geoffrey Paulsen

– Ron

P.S. I still have the podcast to finalize, hopefully that will go up tomorrow.

The Wrench Puzzle Thu, 23 Jun 2016 11:40:00 -0400

A few blog posts back someone in the comments asked for some new art. I don’t think I’ve posted this before, so here it is….

I’d love to share more art and animation, but we’re getting to the point where most new art is riddled with spoilers. Not showing new art almost makes it look like we’re not moving forward, but nothing could be farther from the truth. The game is getting downright exciting. Exciting, I tell you.

OK, one more… then that’s it.

As we play the game and do more playtests, issues start to come up.  One of them we are now referring to as “The Wrench Puzzle”.  Don’t worry, it has nothing to do with monkeys and wrenches. Only a crazy person would design a puzzle like that. Crazy, I tell you.

There was a fairly long puzzle chain in Act 1 to get a wrench that unlocks a new area of the game. The puzzle had two problems.

The first was the moment you realize you need the wrench to progress, you had just solved another long puzzle chain that unlocked the room where the wrench puzzle is solved. At this point, you’ve been built up with anticipation, then you solve the first puzzle and bam! You now have to go solve the wrench puzzle and there is no forewarning.  Solving the first puzzle became a moment of disappointment rather than triumph.

The second issue is that Act 1 was getting really long and the wrench puzzle was contributing to that. It’s a long and complicated puzzle chain, but it’s an interesting puzzle and we didn’t want to lose it.

So the solution we came up with was to move the whole puzzle chain from Act 1 to Act 2.  You no longer need the wrench to progress which makes Act 1 smaller and the returns the moment from disappointment to triumph.

It’s what we in the biz call “win-win”. Or maybe the younger generation calls a “double-win”. But people in the know call it a “win-a-reno”.

We did needed to come up with a different use for the wrench, but that didn’t prove to be very hard, there was a puzzle just waiting for a wrench solution. And, as an added bonus, moving the puzzle chain from Act 1 to Act 2 involved very little work.

So now Act 1 is smaller and snappier and Act 2 is fuller and beefier.

– Ron

Win! Win! Win! Again! Wed, 22 Jun 2016 19:18:00 -0400

It’s time for our second and last Thimbleweed Park phonebook contest. We’re going to giving away another 5 entries into the Thimbleweed Park phone book, complete with (optional) voicemail message (but who wouldn’t want to do that).

The winners last week where:


This week, guess how many people are in the R section of the phonebook!

The contest is open to everyone, even people who already have an entry.

Five closest guesses get an entry in the phone book and the opportunity to upload a voicemail message. Ties will be resolved using officially sanctioned D&D combat rules (the D20).

Post your guess in the body of your message in the comments section. The number must be on a line by itself.

In order to win, you must fill in your email address in the email field. DO NOT put your email address in the body of the message.  If you post multiple guesses, only your last one will count.

I won’t be cross posting this on Twitter, since they have their own contest… so shhhhhhhhh…

We’ll pick a winner Monday morning, live from Spain!

– Ron






Thimbleweed Park Podcast #54 Sun, 19 Jun 2016 14:13:00 -0400

In today’s episode, we talk about redesigning a puzzle much later than we should, but that’s what makes it exciting! Right! Right?

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Win! Win! Win! Thu, 16 Jun 2016 09:02:00 -0400

As a thanks to everyone who has been following the Thimbleweed Park blog and helping out with the game, we’re going to giving away 5 entries into the Thimbleweed Park phone book, complete with (optional) voicemail message (but who wouldn’t want to do that).

Guess how many people in the phone book (as of right now) have uploaded a voicemail, from A

…to Z

The contest is open to everyone, even people who already have an entry.

Five closest guesses get an entry in the phone book and the opportunity to upload a voicemail message. Ties will be resolved using officially sanctioned D&D combat rules (the D20).

Post your guess in the body of your message in the comments section.

In order to win, you must fill in your email address in the email field. DO NOT put your email address in the body of the message.  If you post multiple guesses, only your last one will count.

I won’t be cross posting this on Twitter, since they have their own contest… so shhhhhhhhh…

We’ll pick a winner Monday morning.

– Ron

P. S. We’ll be giving away another five entries next week.



The answer was 1100

Congratulations to…


You will be getting an invite email in the next few hours.

The New T-Shirts Are Here! The New T-Shirts Are Here! Tue, 14 Jun 2016 17:09:00 -0400

Our fabulous mouse pads and t-shirts can now be purchased on Fangamer!  You’ll look twice as style’n while pointing and clicking on your new Thimbleweed Park mouse pad wearing your new Thimbleweed Park t-shirt.

It’s worth mentioning, these are not the backer t-shirts. Those will be twice as cool.  Or half as cool. We haven’t decided yet.

– Ron

Thimbleweed Park Podcast #53 Sat, 11 Jun 2016 19:53:00 -0400

Two blog posts in one day! It’s the end of times! Better listen to this podcast quickly before it’s too late!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

The TesterTron 3000™ Sat, 11 Jun 2016 17:37:00 -0400

While you’re waiting for me to get off my lazy beep and edit the podcast, please enjoy this bonus video of the TesterTron 3000™ finding bugs so you don’t have to.

– Ron

New Thimbleweed Park Teaser Video Mon, 06 Jun 2016 14:38:00 -0400

Someone is watching you…

Thimbleweed Park Podcast #52 Sun, 05 Jun 2016 19:47:00 -0400

All your Friday Questions answered!*

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

*for small values of all.

Friday Questions Wed, 01 Jun 2016 11:48:00 -0400

It’s time for Friday questions!

You know the drill…

Post your questions for Gary, David or I to answer on this week’s Thimbleweed Park™ Podcast and we’ll do our best to answer them, or at least read them to ourselves and mumble under our breath “there is no way I’m answering that”.

One questions per-comment and please try and keep them short. After two sentences, we just zone out and the chances of it being answered drop to zero. I hate to be a jerk (not really), but that’s the truth. It’s a cruel cruel world, best to learn that early.

YAY! Friday Questions!


– Ron

Thimbleweed Park Podcast #51 Sun, 29 May 2016 17:57:00 -0400


You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

SPOILER: There Is Not A Door On Top Of The Vista Thu, 26 May 2016 18:26:00 -0400

During one of the podcast I mentioned we were having some design issues about halfway through Act 1 and we were trying to find a good fix. I can excitedly proclaim our design demons slayed and here is what happened.

I’m going to try and be as spoiler free as I can, so excuse me if I mask some of the puzzles by calling them “doors”. I promise that Thimbleweed Park is more exciting than finding keys to open a bunch of doors, but at it’s core, that’s what adventure games are. Sometimes during early design we will just call a puzzle a key and door. All that really means is something is blocking the way (the door) and something is needed to get past (the key). We’ll figure out something more interesting later (like a rubber chicken with a pulley in the middle).

Of course, sometimes there is just a door and a key. Sometimes a cigar is just a cigar.

There is this point Thimbleweed Park where the world opens up. It happens about halfway though Act 1.  Imagine chartering Dread’s ship in Monkey 2 and you’ll get the idea.  The game starts out and players are pretty focused on the body and finding the killer, then they come to the vista and see the amazing panorama of locations they can travel to. Excitement takes over and they rush to the trail only to be stopped by a “door”.

Remember back in paragraph two when I said I would use “door” as metaphors for puzzles to avoid spoilers? This is one of those cases. There is not a door on top of the vista. SPOILER: There is not a door on top of the vista.

When you present the opportunity to visit so many lovely locations, you can hardly blame players for forgetting about the pesky body and turning all their attention to the door on top of the vista, and that is exactly what they do.

Hours of hilarious and riveting gameplay later…

Players find the key (which isn’t really a key) to the door (which isn’t really a door) and they head out into the vastness of Thimbleweed County.

And they are lost. Not lost in the sense of which way is north or how do I get back to town, but lost in the sense that they totally forgot about the body and all the clues that were being laid.

I struggled with a lot of solutions to this problem, including making the door less sexy or forcing attention to the body (but who can resist a sexy door). In the end, I decide to leave everything as it was and add a small cut-scene.

When players unlock the door that isn’t a door with the key that isn’t a key, the second agent will show up and they have a conversion (via a dialog tree) and chat about what they still need do to solve the crime.

It works well because it refocuses players and provides a small recap. I was even thinking of doing something similar if you start up the game and it’s been more than a few days since you played last.

Crisis number one averted, now on to crisis number two.

After getting past the vista, there is another door (that isn’t a door… do I need to keep saying this) you need to get through. The problem with this door is that it isn’t a very sexy door. Unlike the sexy vista door that you can see treasure behind, players have no idea what is behind this door. It’s just a door. And to make matters worse, it’s a door they saw very early in the game and probably forgot about. The key to this door is beyond the vista, so it couldn’t have been opened sooner.

Now that players are beyond the vista, they have access to the key, but they could care less. We don’t want to tell players what is behind the door because it’s a surprise. We don’t even want to nudge-nudge-wink-wink it. We really want it to be a surprise.

So players get past the vista, solve some more puzzles and then they just start wondering around.  Maybe they remember the door (that isn’t a door!) and maybe they start to looking for the key (that isn’t a key!) only because they are bored and it’s a puzzle to solve while they compose their angry “this game sucks” post on whatever adventure game forum they visit too many times a day.

How to make the purposely non-sexy door sexy?

The solution was to put something else behind the door and tell players about that, but not the surprise that is really behind the door. Now players think there is something else they want behind the door (IT’S NOT REALLY A DOOR!) and seek it’s key.

When they finally get in, they will stumble on the surprise, all the time thinking how clever they were, when in fact they were just being manipulated by game design.

“And that little Timmy is how you make a game.”
“That’s very interesting Uncle Ron, but can I go play Minecraft now?”
“Sure, whatever.”

– Ron

P.S. The use of doors as a puzzle metaphor was only to confuse you, there is nothing interesting behind any of the doors in Thimbleweed Park.

Thimbleweed Park Podcast #50 Sat, 21 May 2016 19:57:00 -0400

The Thimbleweed Park Podcast turns the big 5-0 and we talk about super delegates and why they don’t have their own comic books.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Schedule Wed, 18 May 2016 11:27:00 -0400

In the State Of The Game #3 post, I mentioned the schedule we were working on to ship the game in Jan, and someone in the comments asked if I would show the schedule.

So without further delay… our schedule…

I’m a visual person. I need to see a schedule as colored lines depicting time’s relentless march forward. I know some people like a list of dates and have no problem understanding that, but for me I need to see time. I want to sit back and squint and feel an overview of how long each task is going to take.  Seeing dates like “May 29 – June 3” gives me no sense of the time involved.

If I had some fancy gantt chart software, I’d do my schedules in that, but I also get sucked into fancy software and tend to waste too much time explore features and settings, so I prefer to do my visual schedule in a spreadsheet. It’s simple and does what I need.

OK, so let’s talk about the schedule…

First row is the ship date for the Mac, Windows, Linux and Xbox versions. Sometime in Jan 2017.  I start with this since it’s the the immovable date.

We’re going to start the Linux port this week and given we use SDL for Mac and Windows, I don’t expect it to be a huge problem. We have top people working on it. Top. People.  The iOS and Android versions won’t ship in mid-Jan, they will likely be delayed by a month or two. If things go well and I have more time than expected in Nov and Dec, they might ship sooner. If we had more money, we could hire people to do those, but we don’t and it will probably fall on Malcolm (shh… I haven’t asked him yet) or myself.

I tend to work backwards when doing a schedule, so the next thing we don’t have a lot of control over is the Microsoft cert process. It can take anywhere from one to two months, depending on how many issues are found. We decided to plan for the worst and put it down as two months. There is a small milestone on Oct 1 for pre-cert, to see if there are any issues, but we don’t have to submit a final build.  We might move that up a month or two and do it as soon as we have a stable xbox build with close to final ui.

Working back from there, text lock will be Oct 1. At this point, all the text needs to be final and a locked script can be given to the translators. We will also prep a recording script and we’ll begin recording.  I am delaying this as late as possible and honestly, it should really be happening one or two months before this, but I’ve be spending a lot of time on the dialog. I’m not completely happy with how the dialogs are working and we need time to play with them. We don’t have enough time for pickup lines and testing. This is going to be a stressful time.

In the middle of October we’ll start translation art. Our plan is to translate any art in the game that has text in it. We’ll compile a list and get them translated first, then make the art changes. I’ll soon have a system in place in our engine what makes this pretty simple and should require no code changes, assume it was all set up correctly.

Next we come to the areas of the game and when each of those needs to be done. The game is divided into Act 1, Act 2, Act 3 and Epilogues After those are done, we enter a stage of game-wide polish where we franticly try and fix all the little crap we find and or didn’t have time to fix during the sprints. This is the point where you look at something and say “no one will notice” and drop it off the fix list. 99% of the time, you’re right and no one notices.

All the art will be done by mid July and then we go back and polish.

Music should all be done by July 1 and seems on track. There will be small fixes after that, but nothing major.

The game should be 100% done by Oct 1. Anything that changes after that needs to be “critical.”

And it goes without saying that testing is a non-stop process.

So, that’s the plan. What are the chances everything will go as planned? Zero percent, but that’s what makes game dev so much fun.

– Ron

Thimbleweed Park Podcast #49 Sat, 14 May 2016 19:31:00 -0400

This week’s bonus material contains spoilers! Are you strong enough to resist?

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

No Podcast This Week Fri, 06 May 2016 09:24:00 -0400


State Of The Game #3 Wed, 04 May 2016 17:12:00 -0400

It’s been a while since I wrote a state of the game post. It was supposed to be done back in Jan, but then things happened.

I’m finding it harder and harder to write blog posts because the most interesting things happening right now on the project would be profound spoilers, but we shall forge forward, none-the-less, and-all-that.

On to the state-of-the-game.

How We Got Here

It’s been a long road. We started working on this little game we call Thimbleweed Park a year and three months ago and I feel we’ve grown to be a nice little family, not just the team, but also everyone on the blog. The project progressed pretty peachy until October, then the holidays showed up and it felt like we hit a snag.  We had a lot of drive coming out of our first sprint, but then we puttered along after that.

Not sure exactly the cause, maybe a little burn out, accompanied with feeling a little overwhelmed with the monster of a game we’d created, but persevere we will and did.

Just about the time were were getting over post-holiday focus back, GDC showed up. Our original plan was to have an open-to-the-public party where people would get to play the game, but as we started making plans, we realized we just weren’t to a place where we’d be happy with the game we had to show. On top of that, everyone was very busy, and organizing something like that was just too much work. We gave it a good try.

So we opted to do a press only showing of the game. When you’re demoing to the press, it’s a lot easier to do hand waving and divert attention from areas of the game that aren’t finished or even slightly broken. The press are used to seeing games in this state and generally know how to interpret and project what they are seeing. This is fine for a first look, but not for a preview or a review, but that’s all we were doing.

Prepping for the press demo took a lot more work than we anticipated. It hijacked the sprint we should have been doing as we instead entered a phase of polishing. None of it was lost work, it all had to be done anyway, it was just done out of order and distracted our focus.

Polishing included adding special case animations that we often leave until the end (in case the puzzle changes and it’s not needed anymore), touch-ups on art, making sure all the verbs that make sense don’t respond with “that doesn’t seem to work.”  We also added a lot of ambient background animation, like waving flags and twinkling stars, so the rooms had a static life to them.

For the demo, we decided to show an abbreviated opening to the game and then jump to the place where the Ransome flashback happens and began polishing and testing those areas.

Around this time, we also decided to switch our backer system to PledgeManager so backers could upgrade their pledges. What started out as a quick few-day project had spanned into weeks, all the while we were trying to get ready for GDC.

And… in the middle of all this, we decide to attend PAX East. Yet another distraction to endure. We briefly thought about showing one of the other flashbacks, but sanity prevailed and we took the GDC demo and continued to polish and harden it.

The GDC demos to the press were “guided” demos. They had the option of playing, but we were always by their side to help and warn. The PAX demos would be unguided. Players were left to their own devices to poke and prod wherever they pleased. We needed to make sure we plugged every hole. We needed to test as if it was a shipping project and this takes a lot more time. To the ThimbleTesting team’s credit, no major bugs were found at PAX East, everything was rock solid.

Jenn’s job on the project is the programming the Hotel and Franklin, since we weren’t going to be showing her area, she was free to help set up our PAX booth and all the merch. As the pictures show, she did an amazing job with a very small budget. One of the smartest things she did was put two stools at each station so a friend could play. Adventure game are always better when shared.

Getting the demo ready for PAX took another 3 weeks out of our schedule. Again, none of it was wasted work, it was just distracting and felt like we weren’t making any real forward progress on the game.

I was getting severely distracted with managing the project and struggled to find time to do programming that wasn’t just fire-fighting bugs.

The role I’ve always wished we had was a producer, someone to manage all the schedules and sprints, and keeping an eye on the big picture while we forge ahead with puzzles and art.  It’s a role I’d been taking on and the burden was starting to show. I was spending more time working on spreadsheets then doing programming, design and writing.

After some budget analysis, we decided to bring on Chase Martin as our producer, a role I wish we could have filled months ago. We didn’t really have the budget for a producer for the whole project, but coming on at this stage was doable.  With Chase on board, I’m hoping to have more time to focus on my other three jobs. Hopefully it will make things better for the rest of the team as well.

The UI was starting to bug me. I love the C64 font, but seeing it on the screen really pigeonholed the game as a retro-game, despite it being much more than that. As more and more people looked at the game, we realized the font was becoming a limiting factor, much more than the verb UI.

Our goal has always been to capture the charm of the classic adventure games, but also to introduce them to a new audience without compromising what the game was. The C64 font was a hard thing for people to get around.

In the weeks leading up to PAX we tried a lot of fonts. Our tester builds had a new font every few days and none of them were clicking. We tried nice smooth truetype fonts, we tried pixelated truetype fonts, we tried crazy bitmap fonts and boring fonts. Nothing felt right. With the help of an outside designer we came across the font you see below. It is a hand-drawn pixel font. It’s sharp and clear and you can see the pixels. It’s a font we could have used back at Lucasfilm and it felt right.

The plan was, and still is, to retain the C64 font and allow players to switch with the press of a key.  If you like it better, then please play with it. It’s a good font and we don’t treat it as second class.

For the opening scene of the demo, we wanted a full screen shot of the agents at the body. Mark extended the screen just around the body to full screen. Once the opening was over, we’d switch on the verbs and be back to the black cropped verbs.

While installing the new font, I accidentally left some code commented out and the verbs were drawn over the background, without a black background, and it was stunning to see.  The game had a whole different feel. It took me around 10 seconds of walking around to realize that the whole game needed to be like this.

We had one week until PAX and our demo included over 15 rooms, all of which needed to be extended.

Oh… and Mark was gone for two weeks!

Octavi to the rescue as he took on the job of extending all the rooms in record time. Nothing playable happens below the interface, so it didn’t need to be that interesting, and it actually wants to be uninteresting.

It really changes the feeling of the game significantly, but still retains the charm of the verb UI, something I didn’t want to lose.

For those of you who want a more retro experience, not only can you switch back to the C64 font, you can also turn on the black verb background. But that’s not all! Don’t order yet! You can set the opacity of the black background to anything you want.

PAX went well. We had a great booth (thanks Jenn) and had hundreds of people playing the game. Almost everyone who sat down to play finished the 20+ minute demo and no one rage quit. I’ll take this all as a good sign.

Where We’re Going

Now it’s back to work. We don’t have any shows coming up in the next few months, so we can get back to focusing on the game.

As our projected summer release date got closer, I was starting to get really worried. Back in Sept, we had a lot of steam and it felt like we’d be done the following Sept or Oct, just a few months out from the Kickstarter date.  But, as we hit April it just didn’t look like that was feasible.

Well, not feasible unless we all went into crunch mode.

I don’t like crunch mode. I’ve done a lot of crunch mode in my career and made people do crunch mode over the many years of running projects and it’s just not something we want to do. We don’t have an oppressive publisher looking over us and we have the flexibility to make the game anything we want (thank you backers!).

When Chase came on as producer, we did a complete relook of the schedule to see how much work we had left to do and how long it was going to take us. If we don’t crunch, the workload puts us out to mid October, but we also have to go through the Microsoft cert process for Xbox, which can take one to two months. That would put us out in Nov or Dec and that isn’t a time we want to launch. It’s important that the AAA games have their day in the sun, and we didn’t want to distract from that.

The other option was to start cutting. I feel good about the scope and size of the game, I don’t want to cut it down just to make a ship date.

In the course of making a game, you make a lot of cuts for design reasons, and those are good cuts that make the game better, but when you cut for schedule and budget, you run the risk of cutting meat and not fat. That said, it’s often hard to tell the difference, sometimes you think you’re cutting meat, when in fact you’re cutting fat and you’re better off. It’s often hard to tell the difference when you’re in the kitchen.

But in the end, I decided I didn’t want to hack large sections of the game away just to make an Oct date.  We continue to make small cuts and refinements, but all those are to make the game better.

So we’ve made the decision to move the release of the game to January, mostly likely the middle to end of the month.

The budget is looking OK. With the addition of a few new and needed people, plus the extra time, things are getting tight, but we should still be good.

We raised a little bit of extra money through some angel investors for marketing and PR, two things that can be as important as making a good game. I feel good about using the Kickstarter money exclusively to build the game and the additional money to market it. It feels like a nice line, but it’s also a little misleading. Marketing and PR is as much a part of building a successful game as music, art, and programming and they should be part of any budget.

In terms of the game, I think we’re all feeling pretty good about it. It really feels like a good solid adventure game, just like we would have built back at Lucasfilm.

The one area that I’m worried about happens halfway through the first act. You unlock a large portion of the world and it’s a great moment, filled with excitement and reward but players lose direction. It’s a problem we’ll probably solve with some good dialog and maybe a couple of new pinch points so there aren’t too many new places to go. It’s important to always give players focus. Player should always know what they need to be doing, but not always how they need do it. Being confused and lost is not a puzzle.

We started outside playtesting with testers culled from the readers of this blog. We did two people in Seattle and will now open it up to San Francisco and London. We have (literally) hundreds of people who signed up, so I don’t know if we’ll get to everyone.

As I’ve said many times on this very blog, doing playtesting is critical, but it can be time consuming. You have to organize people to come in, set up the location, spend several hours watching them, and on top of all that, you have to make sure the latest build works and is crash-bug free. It’s a lot of prep and it’s easy to keep putting it off, but resist the urge. Playtest! Playest! Playtest!

We have three bug testers on the project. Robert (lead tester) is full time and the other two are part time. We’re looking to hire a fourth and that should round out the bug testing team until the end of the project. Our testers are amazing, some of the best I’ve worked with. Bug testing a game isn’t fun and games. You’re not being paid to play a game, you’re being paid to break a game, then document it and figure out exactly how you broke it. It takes a special person to do this well, and they are gold when you find them.

What Scares Me

One thing that scares me at this point is the amount of work that needs to be done. It’s a big game, but it needs to be. It’s about the size of Monkey Island, 2 and to fulfill our promise of a “new classic adventure game”, I feel it needs to be that size. I don’t want to cut anything unless it makes the game better to do so.

At this point, it’s about making smart decisions about the little things we can cut or rework to save time without compromising the game.

I actually enjoy that process. It’s always been the fun part of a project for me. You need to make quick decisions about what is and isn’t important. It really focuses you.

But it’s also very stressful. It’s one of the reasons I don’t want to work crunch. Staying sharp can make all the difference.

Moving the game to January puts a lot of pressure on the budget. We had slop if anything went wrong, and although I wouldn’t call moving the date “going wrong”, it does eat up our budget slop.  There is no more runway.

That worries me, but I feel like we have it under control. I don’t think I’ve ever worked on a project that didn’t feel like this towards the end.

The last thing is the amount of playtesting the end game will get. We’ve done a lot of testing of the early game, but we’re still putting the end together and it’s not in a outside player playable state, plus it’s hard to jump new testers to the end of the game, so we need to pull groups back in for a 2nd or 3rd round.

Thank you to our backers and supporters for making all this possible.

– Ron

Thimbleweed Park Podcast #48 Sat, 30 Apr 2016 15:51:00 -0400

We talk about PAX, Star Trek conventions and nerd out about rotation attach points, to which Gary says “Psssssspppt”.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

PAX East 2016 Report Sat, 23 Apr 2016 08:06:00 -0400

We just finished the first day of PAX East and I thought I’d give a quick update.

Here is our Thimbleweed Park booth just before the gates were opened:

And here is a few hours later:

We had four stations to play Thimbleweed Park and they were full all day long, with a line several deep always waiting to play. The thing that excited me the most was – with the exception of a couple of people – everyone played through the entire 20 minute demo. That is always a good sign. You know you’re in trouble when they leave part-way through.

As I mention in the podcast, we’ve done some work on the UI.  The big change is that we’re taking all the rooms fullscreen, then floating the UI over the top. We also switch to a new pixel based font.

You can always switch back to the classic C64 font if you want.

The black bar under the ui was a holdover from the SCUMM days. Back then we didn’t have the memory to do full screen room, nor the ability to overlay the UI. It took me a long time to realize that none of this was a constraint anymore and needed to go.

The other advantage is that during cut-scenes, you no longer have the ugly black area at the bottom of the screen. You now get fullscreen goodness.

I write more about this when I get back… Off to another grueling day on the show floor.

– Ron

Thimbleweed Park Podcast #47 Sat, 16 Apr 2016 16:28:00 -0400

Your constant reminder of how boring game development really is.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

ThimbleCrash Mon, 11 Apr 2016 15:30:00 -0400

A few days ago, I stumbled into my home office, a bowl of oatmeal in hand, getting ready for a quick check of the Twitters before my morning run, but oddly, my computer was off. I leave my Mac running all the time and it was strange that it didn’t just wake up from sleep. I powered it on and everything seemed normal.

The machine will sometimes restart in the middle of the night, and when it reboots, there is a nice message box telling me that it crashed and kindly shows me the logs. This morning, no such message enthusiastically greeted me.


The next day I was editing a very large Photoshop files — touching on 4GB — when it kept popping up these errors when I tried to save saying I didn’t have the correct permissions to save.


The next morning, I headed into the home office again, pre-run oatmeal in hand, and sat down to read the emails.  Most of the new email that arrived during the night had no sender or subject.


A few seconds later, a message box pops up, asking me to enter my iCloud password, I hit cancel and switched to my browser and pulled up Twitter and then Chrome asked me for my Twitter password and had me logged out. I went to another site, and I had also been logged out and it was asking for my password again, then my email program asked me for my password, I entered it and hit OK, then a new message box come on saying the login group of keychain was missing and did I want to reset it.


Something was going wrong and I decide to just reboot and see if things were magically fixed, because, you know, that might happen. Right?

As the machine was shutting down, it dawned on me that rebooting my machine when it was telling me the login keychain was missing might not have been the smartest idea, and I was right.

Half way through the boot process, the machine just shut down. Three more attempts with the same results. I booted in verbose mode and watched the boot process, everything was normal until it got to the disk check, then it displayed a slew of errors and shutdown.


I booted in recovery mode and ran Disk Utility and checked the disk, sure enough, there were a crap-ton™ of missing block error messages. No problem, I’ll just hit “Repair Disk” and be up and running again.


Repair Disk informed me that it was unable to repair the disk. I was somewhat disappointed the Mac didn’t emit a mechanical mocking laugh at this point.

I didn’t have a Thunderbolt Cable, so I couldn’t connect my iMac to my laptop and see if the drive was still readable.

I’m pretty religious about backing stuff up. Time Machine runs every hours and skips only my large video and audio files. It doesn’t back up my projects and source code, but they are all in Git. I had made a few changes the previous day and I had not pushed, but it was just a few lines of code, easily retyped. The big thing I didn’t have was backup of was my Windows VM.

Without it I can’t do windows build for testing. Nothing of importance is on the VM except a install of Visual Studio. The VM could be rebuilt in an afternoon, so losing it wasn’t climatic, just a pain. The one thing I was going to lose by doing a reformat was the podcast we did on Friday. I hadn’t edit it yet, so it hadn’t been archived for future generations to enjoy.

After a little more thinking about what might be on the machine and not backed up, I decided to reformat and reinstall from my Time Machine backup.

There was a very real possibility that this was a hardware problem and reformatting wasn’t going to save the day. In that case, I was going to have to send the machine out to get the drive replaced and that would take several days, if not a week if I wanted Apple to do it under Apple Care. With PAX looming in a few weeks, that was not an event I welcomed.

I can do just about everything on my laptop, except make Windows builds, so it wasn’t a catastrophe, just a big pain as half of our testing staff is Windows only.

I went into Disk Utility again and selected the volume, paused for a few seconds to contemplate the destructive nature of my next move, then hit Erase. A few moments later, I was informed that my drive could not be reformatted.

My iMac has what’s called a fusion drive. There is a 128MB SSD drive and a 3TB spinning drive that are fused into one big drive. The OS is smart enough to move files you don’t access very often to the slow spinning disk, keeping the files you need on the spiffy fast SSD drive. It’s a great idea. The new macs have it, and it’s been embedded in a lot of standalone drives, and there is a version for Windows machines.

The problem with fusion drives is you now have now have two points of failure. If either drive goes bad, you lose the data on both drives, which is what happened to me.

Apparently, while the iMac is happy to have a fusion drive, Disk Utility has not caught up yet, and there is no way to reformat it.


At this point, I’m kind of stuck. All I want to do is reformat the drive and start over. Visions of days waiting to speak to Apple and weeks of waiting to get my machine back are dancing through my head, all while PAX stalks closer and closer.

I call up the local Apple store and see when I can get an appointment to visit the Genius Bar. I don’t have a lot of faith in the Genius Bar to help with this issue. Normally it is filled with people trying to figure out how to get email on their iPhones. I imagine I’ll bring the computer in and the “genius” behind the “bar” will shrug and tell me they need to send it in and there will be a two week wait, but if I’m having trouble getting email on my iPhone, they’d be happy to help.

I place the call and much to my surprise, they have a free slot at 4:45 that afternoon. Great. I pack the computer up and haul it in.

As expected, there are about 30 people being helped at the Genius Bar and other than a few laptops, they are all iPhones. I plop my giant iMac on the counter and wait, feeling quite out of place.

At 4:50 a nice person comes over and asks what the problem is. I tell him the machine won’t boot due to a disk error. He then proceeds to talk to me like I’m a 4 year old, explaining that a hard disk has this spinny thing in them and sometimes those can go bad.


I then tell him I’m a Mac developer (I probably rolled my eyes), at which point he actually seems relieved and switches to full on nerd mode. He plugs my machine into the store network and boots from there, then proceeds to run some fancy diagnostic stuff I don’t have access to. The good news is he doesn’t find anything physically wrong with the drive.

He connects the iMac to my laptop and we mount it as a external drive. Everything seems to still be there, so I spend the next half hour copying the Windows VM and the podcast to my laptop and we reformat the machine using a bunch of shell commands, while he’s happy to explain what is happening.

I ask why Disk Utility can’t just reformat the drive. He says the Apple Utilities haven’t caught up to the fusion drives and (politely) expresses some amount of frustration at this fact. I get the impression he’s done this a lot.

I pack up the newly reformatted machine and head home. Time Machine restored perfectly, I then pulled all the repos from git, and other than needing to reenter all my passwords, the machine is back like nothing happened.

I know you hear this a lot, but back up your shit. This story would not have had a happy ending if I didn’t back up everything obsessively.  I run Time Machine for local backups and use Arq to keep offsite archives on amazon’s S3 storage (Time Machine can’t help you if your house burns down).

I did manage to restore Friday’s podcast recording, so I’ll try and have that edited and up tomorrow.

I lost a day, but I got a nice clean desk out of it, so I’ll call that a win.

– Ron

Pledge FAQ Wed, 06 Apr 2016 14:59:00 -0400

Jenn here. It’s been a month since we launched our new upgrade and pledge system using PledgeManager.

Hopefully unbeknownst to you, I’ve been helping out with the customer support. Before we (re)launched I was totally dreading it. You hear all this stuff about customers always being right and demanding all kinds of outrageous things. I was also nervous because I know how many backers there are and I imagined thousands of customer support emails clogging up my inbox.

It turns out everyone’s been just lovely! For the most part the system has worked pretty well and hasn’t needed much work from me. So hugs all around and thanks for making my job easy.

That said… It looks like there’s been a few common questions. So I thought I’d dedicate a blog post to these….

Why do you need more money? Didn’t you get a bunch of money from the Kickstarter already?

Yes and we’re using that to make the basic version of the game and all the stretch goals. But we want to make Thimbleweed Park even better by adding more art, more animation, more sound, more music. We need your help to make Thimbleweed Park even more amazing.

But wait, will that mean the scope and development time are increasing significantly?

No way! Many of our team are only working part-time right now. Your money will allow us to pay them for more of their time, which means more great stuff gets put in the game. It’s not about adding new scenes, new puzzles or new features, it’s about polish, polish, polish! It’s about special case animations and more music variety. All the stuff that will make Thimbleweed Park blow you away.

I never got an email about all this PledgeManager stuff you’re talking about! I want to be part of the party!

At the start of March you should have got an email from If you didn’t get it, you can request it again from PledgeManager:

Click here if you’re a Kickstarter backer or backed during the campaign

Click here if you backed after the Kickstarter campaign

If you’re not sure which link to click or you’re still not seeing your rewards properly, email us at and we’ll get you sorted.

I paid with PayPal, but PledgeManager still says I owe money! What’s up with that?

It turned out that for a while PledgeManager and PayPal didn’t talk to each other properly. Something about email addresses or not having physical addresses. Thankfully the wonderful PledgeManager people assure me they tracked down the problem and so no one should have any issues from now on. However, if you were affected by this, get in touch via Let us know the email addresses you used with PledgeManager and PayPal and we’ll make sure your account reflects what you actually paid.

I backed the phone book during the Kickstarter, but I never got an email about how to enter my voicemail message. I want my reward!!

We sent out emails at the start of February. If that email’s been lost forever in spam or otherwise, let us know via and we’ll resend your email.

I’m a new backer/backed after the Kickstarter, can I get the phone book?

On our Kickstarter page, we said that the Phone Book was a Kickstarter exclusive. While we could say that what we meant was that the price was exclusive and allow new people to get the phone book, we don’t feel that’s in line with what our Kickstarter backers thought we meant. So in order to be true to our promise to those backers, we can’t let non-Kickstarter backers get the phone book. Sorry. We’ve learned our lesson.

I’m a Kickstarter backer and I upgraded to get the phone book now or I bought another phone book as an add on, where do I enter in my information and record my voicemail message?

You’ll receive an email from us with all the details on how to put in your information. We’ve had a delay sending out those emails, but they will be going out soon. That email will also tell you your unique phone number in the game, so you can leave a message to call a friend if you want. We’ll be extending the deadline on when the phone book voicemail messages need to be finished by. So don’t worry, you’ll have plenty of time to get it right. So keep your eyes peeled for an email us.

I pledged twice with the same email, but PledgeManager doesn’t show me all my stuff and I didn’t get a second Phone Book email. Give me my stuff!!!

You pledged twice?! First off, YOU’RE AMAZING!! Next… Neither PledgeManager nor our Phone Book system thought there would be people as generous as you. So most likely you’ll only have one email from PledgeManager (there are some edge cases where you might have been got two PledgeManager emails, but probably not) and one email about your Phone Book entry. We’re working on a solution to the Phone Book entries as we speak and will hopefully have that sorted soon. For PledgeManager, we’re going to try to go through and find the names of everyone who backed multiple times manually. But since we might miss you, please get in touch (via if your PledgeManager account doesn’t reflect what you actually bought. We’ll sort you out manually.

What is Ransome’s Swear Jar, what are these tiers and why should we give you money?

We’re still working out exactly how your name will be getting displayed in the game. If we do figure it out, we’ll post to the blog. In the meantime, know that any the money you give us will be used to help make the game better. The swear jar has 3 tiers, $10, $20 and $30. The more you give, the more prominently your name will appear in the swear jar listing & we’ll be able to make a better game for you too!

I added Ransome’s Swear Jar, but my name didn’t get linked to the add on OR I added my name, but I need to change it now. How can I do that?

As far as we can tell, there isn’t a way to change the name associated with your Swear Jar entry. Likewise, if you accidentally added the Swear Jar without a name associated with it, PledgeManager has no way to add one after the fact. The easiest thing for you to do, is “unlock” your order again, remove the Swear Jar from your cart and then add a new Swear Jar to your cart, making sure to put your name in and spell it the way you’d like. Note: you can add more than one Swear Jar to your cart and have different names associated with each entry if you wanted.

I saw you giving away T-shirts on Twitter and at GDC! Are these the backer T-shirts? Why are other people getting their shirts and I still haven’t got mine?

The shirts that Kickstarter Backers will get will be different. And the only way you’ll be able to get one of those exclusive shirts is if you’re a backer. We won’t be giving them away to press or selling them or anything else. We’re working on how and when to get the backer shirts out to you sooner without involving a lot of extra postage and so on. We’ll let you know when that’s getting finalised.

Backer T-shirts?! That sounds fun, I want one!

If you backed during the Kickstarter, you can upgrade to get a T-shirt via PledgeManager. If you’re a new backer, sorry. There’ll be other T-shirts you’ll be able to buy, but it won’t be the backer shirts.

I just want a T-shirt, any shirt!! Can I buy one/win one?

We’ll be periodically doing giveaways via our Twitter account (@thimbleweedpark), so if you’re lucky you might win something. If you’d like a more guaranteed way of getting a shirt… We’re going to be selling those same shirts at PAX East. So stop by our booth (number 5169) within the Indie Megabooth to buy one. We’re also investigating ways we can set up an online storefront to sell just these shirts, but that’ll take time. So patience, please!

If you have more questions, ask away! I’m happy to help out. Put your question below if it’s a general one and you don’t need direct action from us. If you need personalised help, reach out to us (me) at and we’ll do our best to get it all sorted. Please don’t post personal requests in the comments.

– Jenn

Thimbleweed Park Podcast #45 Sat, 02 Apr 2016 18:28:00 -0400

We spend over 30 minutes answering reader questions and David sings us a tune.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Play Thimbleweed Park at PAX East Thu, 31 Mar 2016 11:44:00 -0400

We’re not only going to be showing Thimbleweed Park at PAX East, we’re installing four state-of-the-art interactive stations so you can sit down and play Thimbleweed Park.

We’ll be part of the always awesome Indie MEGABOOTH and will be joined by some of the best indie game devs around. I look forward to hobnobbing and sharing war stories about game dev.

This will be the first time we’ve opened the game up to the public and it’s nerve wracking. What if everyone hates it? What if the MEGABOOTH is packed, except for the deserted Thimbleweed Park booth? What will we do with several hundred unclaimed mouse pads? Those are the thoughts that race through my head and keep me up at night.

Hopefully they also make us try harder and be better. You’re a tough crowd.

We’ll post more about our prep, showing what we’re going through to get everything ready.

– Ron

Friday Questions Wed, 30 Mar 2016 12:31:00 -0400

Not only is Friday April 1st (and we’ll be punking you with all sort of hilarious blog posts and tweets), it’s also the first podcast of the month and you all know what that means! Friday Questions! That’s right kids! Friday Questions!

Post your questions for us to answer on the podcast and we’ll do our best to answer the most interesting ones.

Remember, only one question per-comment and try to keep the questions short and succinct. We glaze over reading too much text. Please try and ask questions that haven’t been answered before. We’re giving style points for unique, but relevant questions.

– Ron

UPDATE We’ve cut off Friday Questions.

Thimbleweed Park Podcast #44 Mon, 28 Mar 2016 13:55:00 -0400

Join us as we talk about GDC and Gary professes his support for Donald Trump.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

GDC 2016 In The Can Tue, 22 Mar 2016 12:43:00 -0400

This was an odd GDC for me. I spent most of it in a hotel room giving demos of Thimbleweed Park to the press. Eight to ten each day for four days, with the fifth day being locked in a warehouse giving demos to the press on the Xbox One.

Ah… the glamour of the game business.

Here is a recap of some of the press:

Rock Paper Shotgun
US Gamer
Pocket Gamer
The Verge
XBox News
PC World

So how did all this happen?

Several months ago, we had the idea that we’d put on a party at GDC and invite industry friends and others and have an open house day where anyone could come by and play the game. It seemed like a great idea when GDC was several months away. It’s easy to dream when reality is too far to muck it all up.

As GDC got closer, we realized how massive this undertaking would be. Everyone was busy, you know, actually working on the game, and finding space and organizing this was slowly turning into a chore. This was further complicated by looking at the cost of everything.

We knew we wanted to show the game at GDC. It’s a great opportunity and a lot of press are there already, so it seemed perfect. What wasn’t going to work was a party with all-you-can-eat shrimp and an open bar. I also suck at throwing parties. No one ever shows up. I was losing sleep over this.

So we decided that doing private press demos was probably a more realistic idea, and we could get away with a platter of frozen shrimp from Costco.

We were planning on doing a new trailer and figured it would be the perfect lead up to GDC, so the first step was to get that moving. I’ll do a full blog post next week on what it took to get the trailer made, so let’s just enjoy some montage music for the next few seconds and assume a trailer got made.

Once the trailer was done and released, we started booking press appointments. I’ve known Emily Morganti for many years and worked with her on Scurvy Scallywags, and the good news is she’s amazingly good at PR. The bad news is she’s amazing good at PR. In just a few days, she had filled our five days at GDC with press appointments. It was clear to me I wasn’t going to be attending any of the talks at GDC.

We booked a slightly larger hotel room than planned and figured we’d do all the demos there. Demoing on the show floor is noisy and chaotic. If we were going to do this all day long, at least it would be quiet.

We got a room at the Marriott, which is across the street from GDC so press wouldn’t have to walk too far. Press are notorious for being late and missing appointments if they are hard to get to. In the end, only one appointment was missed and no one showed up more than 10 minutes late, so I guess the plan worked.

The next step was to figure out if we were going to make anything fun to give away. After batting a bunch of ideas around, we settled on t-shirts and mouse pads. These were also generic and fun enough to be able to give away in a lot of situations. We wanted these t-shirts to be different from the backer t-shirts. It was important the backer t-shirts felt unique and special.

We ordered these great vertical banners of Ray and Reyes to decorate the room. The banners were fairly cheap and a good investment since we can use them at PAX East, not to mention countless other events we’ll get sucked into.

But wait, the fun isn’t over yet.

The next grueling step is the demo itself. You can’t just boot up the game and start playing. We needed a section of the game that shows it off well and hits all the places and points we we want to highlight.

Demoing adventure games is hard. They are generally slow paced and much of the enjoyment comes from exploration and the enjoyment of a nice conversation. These are all things that are death in a demo environment.

When Emily came on, I got her a build of the game and she played it for a while, looking for sections that might show better than others. When you’re building something, you often aren’t the best person to pick out the good nuggets. We become too close to our creations and are often fixated on unimportant things for unrelated reasons. A neutral eye can be best.

Emily suggested showing the very beginning to get to know the UI and the agents, then skipping ahead and triggering the Ransome flashback. The demoer would play until the flashback, then the demoee would take over (if they wanted). This would provide a nice 30 minute demo, leaving time for questions and awkward shrimp eating.

That all sounded like a great plan, but we’d need to change the code to lock off sections we didn’t want prying eyes to peer into. This demo was going to be shown at the Microsoft event using only a controller, so we also needed a way to restart and end the demo without a keyboard. None of this is rocket science, but it all takes time to code and test. The demos in the hotel room were going to be done from my Mac, but the ones at the Microsoft event were going to be done from Windows and we needed to make sure the Windows build was solid.

There was a bunch of art tasks that had previously been moved to the polish phase and all that needed to be done sooner than expected, so Gary and the art team hurriedly polished that into shape. There was more than we could do, so we left some of it unfinished and we’d just talk around it.

Now imagine there is more montage music as we fly to San Francisco for GDC.

We got there on Saturday, which gave us a few days to set up and visit Smuggler’s Cove, the most amazing pirate bar in the world. I’m pretty sure pirates drank rum through long tiki straws.

Although we had a nice demo planned, we had never actually given it to anyone that didn’t already know the game inside and out.  We found a couple of ex-press friends and got them to show up on Sunday for trial-demos and shrimp tasting. We got some good feedback from both of them and felt ready to go.

One of the challenges of promoting Thimbleweed Park is going to be keeping it from being seen as just a “retro 8-bit point and click adventure.” It’s a lot more than that. We’re doing everything we promised on the Kickstarter, but also thinking about the design and how we tell stories using 30 years of learned experience. Not just within ourselves, but how much we all have learned about game design and storytelling. We’re doing a lot in the game to help players who might not have grown up with traditional adventure games, at the same time remaining true to the roots and never dumbing down the game or puzzles. It’s a tight rope to walk, but it’s a key message to get out. We really want Thimbleweed Park to not only quench the thirst of fans of the genre, but introduce new people to the charm of the point and click adventure. We were hoping to use these demos to help get that message out.

Monday morning arrives and we’re ready to start. Team Thimbleweed members Gary, David, Jenn and Mark were also going to be there, but we decided to rotate them through so only two team members are there at a time. When demoing it’s important not to overwhelm the person you’re demoing to. I’ve seen demos where six teams members and one press person are crammed around the screen. We wanted to keep one-on-one demos as small and intimate as possible, while still giving the press an opportunity to chat with different people.

My primary responsibility was going to be doing the demos with the other person doing color commentary and backup humor if things started to go south.

The demos would start out with a quick recap of the Kickstarter and the project. We’d then give an overview of the story of Ray and Reyes. The game would then start at the dead body by the bridge. We’d walk them through solving a simple puzzle involving taking a picture of the body. This involved some character switching, which provided a good place to talk about multiple playable characters.

With the body photographed, we head into town. At this point the screen went black and the words “Hours of hilarious and riveting gameplay later…” came on screen. We got some good chuckles and a few seconds later, we were in front of the Diner. We’d talk about the UI and some some of the lighting effects as Ray walked in and out of the streetlights.

We’d then headed into the Diner and have a conversation with Sandy, asking about the body. This would be the first time we’d see the dialog system and was a good point to talk about that.

During the conversation with Sandy, she would start talking about the crazy clown who lives out at the abandoned circus and never takes his makeup off. “He’s got serial killer written all over him.” The screen starts to go wavy as the harp music swells and we enter Ransome the Clown’s flashback. I briefly talk about flashbacks and how we use them to introduce the playable characters. I chat about Delores and Franklin and offer to let them play or watch while I play. Almost everyone opted to play.

It took around 15 or 20 minutes to make it through the Ransome flashback with varying degrees of hints along the way. One press person was quite clear they wanted no hints, and it took them longer.

When the flashback was over, the second Thimbleweed Park team member would take over the mouse and just walk around the town and up to the vista while all chatted about the game and answered questions. When the demo was over, they would leave and we’d enjoy 5 minutes of silence before there was another knock at the door.

It was five days of this. It was grueling and it’s easy to complain, but we really had nothing to complain about. We were blessed to have that much interest in Thimbleweed Park.

We also learned a lot. It was like watching 30 playtests. Every little crack in the Ransome flashback was now painful and obvious. We ended those five days with a list of small changes to make. A word of dialog here and there to make something clearer. Changing an object’s description. Removing the odd few pixels that made something look like something it wasn’t.

And now we do it all again for PAX East…

The PAX demo will be slightly different as we get to enjoy the added complexity of it being completely playable by the public. We need to harden the edges and polish the art since we won’t always be there to make excuses.

I always forget about how much time is spent when a game gets to this stage. Never underestimate the time you spend getting press or public demos ready to be shown.

I just want to work on the game.

– Ron

GDC or Bust! Fri, 11 Mar 2016 16:34:00 -0500

I once tweeted “GDC” and someone asked “what’s GDC?” No matter what your job is, it’s easy to start using lingo and acronyms that seem obvious, when they are far from that to others.

GDC stands for Game Developers Conference. It happens in San Francisco each year around this time and 25,000 developers get together and pontificate about stuff they think they understand. They rarely do, but it’s still very useful and entertaining.

Over the 30 years GDC’s been going on, I think I’ve missed only a handful of them. Back in 1991 Monkey Island won “Best Game Play”. That was back when the entire conference could fit in one room and have dinner together. How times change.

We’re going to be doing hands-on demos of Thimbleweed Park to the press and I’m going to be stuck in a hotel suite for 5 days, 8 hours a day showing the game with David, Gary, Jenn and Mark coming in for tag-team relief. It’s going to be grueling.

We’ve all spent the last few weeks polishing and getting the code and art ready. It will be a hands-on demo, meaning the press will get to play the game, but one of us will always be there so it doesn’t need to be a “hardened” demo. If we were showing to the public, we’d have to make sure you could never do anything bad or go anywhere you weren’t supposed to. There is still a lot of polish and loose ends left to be done.

It’s always amazing how much time you spend getting a “demo” build ready. It’s horribly distracting to, you know, getting the actual game done. I always forget about this when scheduling. If you find yourself in a similar position, never ever underestimate the amount of time and work this take.

In April, we’ll be showing the game to the public at PAX East, so if you’re going to that please stop by and say hi. That build will need to be a “hardened” and will take even more time, but it’s all important, almost as important as making the game, especially for indies. “Built it and they will come” is naive at best.

There will be no podcast today. I still have last weeks podcast to edit, but that will have to wait until after GDC.

As an apology/bribe, please accept this new, never seen before art from Mark.

Thimbleweed Park Trailer Thu, 03 Mar 2016 14:32:00 -0500

Behold the latest trailer for the game to be henceforth known as Thimbleweed Park in all the lands.

And to celebrate it’s release, our backer page is back up and in an astonishing feat of engineering and backroom deals and negotiation, you can now increase your pledge level.

I’ll wait for you to recover from your fainting spell and get up off the floor…

That’s right, increase your pledge level and get that reward you feared had slipped from your grasp forever. Or get brand new rewards like appearing in Ransome the Clown’s Swear Jar.

– Ron

Thimbleweed Park Podcast #43 Sat, 27 Feb 2016 17:47:00 -0500

Gary gets a new computer and we can’t stop talking about it.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Elevator Speedrun Sun, 21 Feb 2016 20:46:00 -0500

Hey everyone! Octavi here,

These past weeks I’ve been working on new rooms for the game, specifically those related to the Edmund Hotel. This imposing building was once a symbol of Thimbleweed Park’s heyday, but like everything else in this town, it has fallen into a state of decay and disuse.

Here’s a little timelapse video to show you the creation process of one of the backgrounds I’ve been working on for the hotel. The smallest one: the elevator.

This small device combines in a few square feet the freshness of Art Deco design, the cutting edge technology of the ’80s and the stinking mold dripping from the walls. Or is it blood? … or vomit? Anything is possible in Thimbleweed Park.

The preliminary sketch is the most important part of the whole process for me. I like to draw it as detailed as possible, so when I show it to the team they have a clear idea of how the final art will look like.

The next step is to create a simple grayscale pixel art version, or wireframe, which is ready to be provisionally imported into the game, while we keep working on the final color version. For this small room, the composition and perspective is not really problematic but it’s important that the player can easily view and interact with all the key elements such as buttons and lights, as this will be without a doubt the deepest simulation of an elevator that we’ve ever experienced in a point and click adventure game.

Finally, the most delicate part for me: the final color version. Delicate because it’s important that all the rooms I work on are as consistent as possible with Mark’s style. That’s why throughout the process of creating the hotel rooms, Mark has been helping me with ideas, advice and feedback to get my work closer to his. The truth is that working on this game is being an amazing learning process for me!

In fact, my first contact with pixel art was when I was a child and spent countless hours copying screenshots from videogame magazines in DPaint, pixel by pixel, from Maniac Mansion, Monkey Island, Loom … So, I owe Gary, Mark, and all the other great artists working on those classic games most of my pixel art knowledge.

Back to the elevator: most of the rooms we make have different lighting conditions to make them feel more dynamic (usually flickering bulbs or lights that the player can activate and deactivate using switches). In the case of the elevator, as you can see in the picture, it only has one light source from the ceiling, so it was easy to create the darkest state, simply turning down the lightness slider in Photoshop and adding some cool tones. Maybe it won’t be used in the final game, but it’s important that the art is as flexible as possible so it doesn’t interfere with the game design.

Once all the different elements are placed in their respective layers, comes the exciting moment of wiring the room into the game.

And that’s it! I hope you all enjoyed this little peek into the creation process of Thimbleweed Park backgrounds!

Thimbleweed Park Podcast #42 Sat, 20 Feb 2016 15:10:00 -0500

This week we talk about how damn sexy Lieutenant Commander William Riker is.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

WANTED: Playtesters Thu, 18 Feb 2016 18:08:00 -0500

What is the most anticipated game of 2016? No, not that one… No, not that one either… OK, pretend that one isn’t coming out… No, next? That’s right! Thimbleweed Park!

With the year drawing to a close… Yes, I know it’s only February, but one of the joys of working in the “game biz” is that you start panicking about the end of the year in February.

With the year drawing to a close, it’s time we ramp up the playtesting. We’ve done phase one, which is getting friends and family in to playtest, but now it’s time to open it up to a more hostile and unforgiving crowd, which is where you come in…

Phase two of our testing will still be in person. We will not be sending out copies of the game to play, so you will need to live in one of the fun filled locations of Seattle, San Francisco or London to participate.

You will sit down with a member of Team Thimbleweed and spend two or three hours playing the game while we quietly watch (lab coats and clipboards are TBD) and then ask you a lot of questions.

Our goal is to do one or more of these each week over the next few months.

If you’re interested, please fill out THIS FORM.

– Ron

Thimbleweed Park Podcast #41 Sat, 13 Feb 2016 18:05:00 -0500

Where we talk about crunch food and George Lucas giving us neck rubs.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Friday Questions Wed, 10 Feb 2016 19:34:00 -0500

We skipped Friday Questions in January because it was the beginning of the new year and we didn’t want to set a bad precedent by actually doing something on time. It’s better to expect failure and be surprised by success than expect success and be disappointed by mediocrity. Or something like that. I need to work on that quote a little.

Well, it’s time for Friday questions. Post your questions in the comments and David, Gary and I will do our best to answer them.  As always, only post one question per comment and don’t post too many questions, we tend to tune out when a single person is posting a ton of questions.

Ready. Set. Go!

– Ron

P.S Commenting is closed.

TextTron 3000™ Tue, 09 Feb 2016 14:07:00 -0500

Around a year ago, I posted some source code from Thimbleweed Park and was immediately demonized for including text in my source code. Cries of “How dare you!” quickly followed by readers covering the eyes of young ones.

Yes, text in source code is a really bad idea, but this isn’t my first trip to the rodeo. I have a plan, a very cunning plan, a plan I have used many times in the past, a plan that I will now share with you.

First I need to state that I like text in source code, especially when in comes to adventure games. Text is an integral part of the game and it is woven into just about everything coded, from funny object descriptions to charming comebacks and moving dialogs.

Coding an adventure game is a very creative process. It’s not cleanly divided into coders, designers and writers. I expect the people doing the game coding to be a little bit of all three of those things, it’s why I like the text intermixed with the code. You can read the code and get a feel for what is happening. You can tweak code and text at the same time, getting everything to play just perfectly. You can’t adjust one without the other.

But it does create a dilemma. If the game was in one language and never to be translated or voice recorded, you could blindly add text to your code without a care or worry, but that’s not the world modern games live in.

Let’s look at the process.  Here is some code from the Thimbleweed Nickel:

nickelMapWall =
    name = “empty frame”
    verbLookAt = function()
        sayLine(“Very abstract… not a great use of color.”,
                “…though I do like the subject matter.”)
    verbPull = function()
        sayLine(“It won’t budge.”)

We sit with the text and code like this for quite a while. There is no rush to exact it. Once exacted, you can still change it, inserting and deleting at will, but it’s a little harder.

I wrote a tool in python called that does all the extracting (more on that later).  I run the tool… –extract Nickel.nut

which transforms the above code into…

nickelMapWall =
    name = TEXT(0,“empty frame”)
    verbLookAt = function()
        sayLine(PLAYER(0,“Very abstract… not a great use of color.”),
                PLAYER(0,“…though I do like the subject matter.”))
    verbPull = function()
        sayLine(PLAYER(0,“It won’t budge.”))

The lines have been extracted, but they haven’t been assigned numbers or placed in the text database yet.

At some later point (days, not months), I’ll run this… –add Nickel.nut –tsv Text/ThimbleweedText.tsv

…and the code becomes…

nickelMapWall =
    name = TEXT(10087,“empty frame”)
    verbLookAt = function()
        sayLine(PLAYER(10088,“Very abstract… not a great use of color.”),
                PLAYER(10089,“…though I do like the subject matter.”))
    verbPull = function()
        sayLine(PLAYER(10090,“It won’t budge.”))

…and a .tsv file is written (or added) to…

TEXT 10087 empty frame Nickel 581
PLAYER 10088 Very abstract… not a great use of color. Nickel 588
PLAYER 10089 …though I do like the subject matter. Nickel 589
PLAYER 10090 It won’t budge. Nickel 593

The file the line came from, along with the line number is stored to make sorting and printing recording scripts easier. It’s good to know where the line came from.

TEXT and PLAYER are macros.

#macro TEXT($a,$b) “@$a:$b”
#macro AGENT($a,$b) “@$a:$b”
#macro PLAYER($a,$b) “@$a:$b”
#macro RAY($a,$b) “@$a:$b”
#macro REYES($a,$b) “@$a:$b”

#macro NATALIE($a,$b) “@$a:$b”
#macro POSTALWORKER($a,$b) “@$a:$b”
#macro CHET($a,$b) “@$a:$b”
#macro SHERIFF($a,$b) “@$a:$b”

They just transform each line of text from “Very abstract… not a great use of color.” to “@10088:Very abstract… not a great use of color.”

In the final build of the game, the #macros will get replaced with this…

#macro TEXT($a,$b) “@$a”
#macro AGENT($a,$b) “@$a”

…and the text will get stripped out, leaving only the line number.

when the game engine goes to display text, if it begins with ‘@’, it knows a number follows and that is looked up in the text database and the (possibly translated) text is used.  During development, we include the text in the string so it can be updated, changed and checked against the database.

Rule #1 of Translation Club: Never ever ever edit the text in the database. If there is a change, make it to the source, then you run… –update Nickel.nut –tsv Text/ThimbleweedText.tsv

…and any changes are moved from the source to the database.

Text is usually locked before sending it to the translators, so nothing should change after that. If it does, you make the changes in the source and run –update again. This will add the lines to the translation files as well.

Text databases can also be hotloaded, so a translator can edit the .tsv files, hit a key in the already running game and the new text is loaded and used. It should make translating easier.

I gave Boris the Nickel and he translated it and is still speaking to me, so I guess it went OK. Right Boris? Boris? Hello? Boris?

The extractor ( is pretty simple and driven by regex.  All of the regular expressions used are…

re_sayLineActor = re.compile(“sayLine\(\s*([a-zA-z]+)\s*,\s*((\”(\\.|[^”])+\”(\s*,\s*)?)+)\s*\)”, flags=re.DOTALL)
re_sayLine = re.compile(“sayLine\(\s*((\”(\\.|[^”])+\”(\s*,\s*)?)+)\s*\)”, flags=re.DOTALL)
re_quoteText = re.compile(“(“(\\.|[^”])*”)”, flags=re.DOTALL)
re_objectName = re.compile(“name\s*=\s*(“(\\.|[^”])+”)”)
re_addText = re.compile(“([A-Z][A-Z0-9_]+)\(\s*([0-9]+)\s*,\s*”((\\”|[^\”])*)”\s*\)”)
re_FindMacro = re.compile(“([A-Z][A-Z_0-9]+)\(([0-9]+)\s*,\s*\”((\\.|[^\”])+)\”\s*\)”)
re_yackOption = re.compile(“^\s*([0-9])\s+(?![A-Z]+\()”?(.*?)”?\s*->”, flags=re.MULTILINE)
re_yackSayLineCond = re.compile(“^\s*([a-zA-Z]+):\s+(?![A-Z]+\()”?(.*)”?(s+\[)”, flags=re.MULTILINE)
re_yackSayLine = re.compile(“^\s*([a-zA-Z]+):\s+(?![A-Z]+\()”?(.*)”?”, flags=re.MULTILINE)

These grab about 99% of the text. Every so often we doing something goofy and have to hand add the macros, but it would take me more than to write the extraction code than just change the game source. It’s a small edge case.

“Wait… what about dialog?”

Good question…

That is why we have different #macros for each of the actors.  You notice that the actor name was placed in the .tsv file…

PLAYER 10090 It won’t budge. Nickel 593
NATALIE 10091 Welcome to the Thimbleweed Nickel. Nickel 593

This serves no other useful purpose than to tag actors when exporting scripts.  Because there are five playable characters, some lines need to be read by five different actors.  When the script is exported, it sees PLAYER, and knows it need to emit scripts for RAY, REYES, RANSOME, and DELORES. When the audio is recorded, it will be saved into four files…


It’s the same line (hence the 10090), but it’s read by four different people.

“Hey, what about Franklin? Did you cut him from the game? I want my Kickstarter money back!”

No, he’s not cut from the game, but he’s a ghost and he has very different interactions, so we don’t need to record him for most of the lines.

– Ron

Thimbleweed Park Podcast #40 Sat, 06 Feb 2016 14:43:00 -0500

The Thimbleweed Park Podcast turns 40 and goes out and buys a sports car. Unrelated to it’s midlife crisis, our extra-special guest is Octavi “@pixelhuh” Navarro.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Controllers Tue, 02 Feb 2016 16:45:00 -0500

When you think “point & click”, the first thing that pops into your head is “game controller”. Am I right? Yeah, I thought so. The “I thought so” part should be read in your best sarcastic voice, because we all know that is not what pops into your head.

Control schemes are always hard and one of the least favorite parts of making a game for me. I know people who live for it – and power to them – but for me, I just want the control scheme to vanish. It’s an archaic connection between our bodies and our minds and it’s unnatural at best.  Maybe that is why I like a mouse and just pointing and clicking, but I know that is not natural for a non-inconsequential subset of humans, so in the end, there probably isn’t a perfect control set up. I’m sure Holodeck designers of the Star Trek future hate UI and control scheme as much as I do, they are just dealing with a different set of impossible constraints.

Thimbleweed Park was always conceived to be a true point & click adventure game. With a mouse. And pointing. And clicking. It’s the way god intended adventure game to be played. Look it up.

But there is part of me that enjoys laying on the couch, feet sprawled in unnatural ways across the cushions and playing a good console game with a controller. It’s a very different experience than sitting at a desk with a mouse. When I’m playing PC games at a desk, I expect to be thinking and pondering. When I’m playing a console game with a controller, I expect to be more viscerally attached to the game. I expect to be doing something all the time.

That was part of the impetus for The Cave: build an adventure game that was designed from the start to be played with a controller and feel energetic.

But that isn’t Thimbleweed Park. Thimbleweed Park was designed to be an adventure game played with a mouse. With pointing. And clicking.

That said, we’ve always wanted the game to be on consoles. It’s a different audience and one we want to reach. I look at it as a challenge. How to make a point & click adventure game that is true to the roots (and to the Kickstarter and our vision), but is playable with a controller. And not just “barely” playable, but fun with a controller. Every bit as fun as it is with a mouse.

I don’t think I’ve ever created a control scheme that didn’t go though round after round of tweaks and complete restarts. The point & click scheme for Maniac Mansion didn’t come out fully formed. It went though a lot of redesigns until we landed on what we did. Then it went through even more redesign for Last Crusade and even more for Monkey Island. Control schemes need to feel natural and sometimes that takes time. You know there is “something” wrong, but you don’t know what.

The deceptive part of building a control scheme is that you can only talk about it so much. You never know until you play it. The most talked through control scheme can fall apart a mere second after trying it. Your brain figures out every hole and contingency, but your fingers just want to do something else.

We have an opportunity to show Thimbleweed Park as part of a presentation with Microsoft in March. I was hoping to punt on the deep controller work until later, but they are requiring the game be shown with a controller, so time to rejigger the schedule and move controller head-banging (in the bad way) up.

Controller support has been in for months, but only very basically where you move the cursor around with the thumbstick. We knew we needed more.

So the first thing I did was think of every game I could on console that might have solved a similar problem and then didn’t look at any of them. I very purposely didn’t want to see how others had dealt with this thorny issue so I wouldn’t be tainted. I am not a console player so I thought maybe I could come at this from a fresh perspective. This isn’t born out of arrogance, but more of the “too stupid you don’t know it can’t be done” line of think. Ignorance can be wonderful sometimes.

I’m intimidated by buttons. I like that a mouse has two buttons. Three button mice freak me out. Controllers have a lot of buttons, but console players don’t seem to mind. My personal mission was to use as few buttons as possible and I feel like I failed in this regard. I’m using pretty much every button on the controller. My only saving is that many of them are optional, used only to speed the action up. You can still play the game with one thumbstick and the A button.

The game has two different controller modes you can switch between.  One I call Classic, where you drive the cursor around with the thumbstick, the other is Modern where you drive the character around with the thumbstick. They are basically the same except for what the thumbstick does. All the other buttons function the same.

This is completely untested on real players, so I expect a lot to change once I do that. I like it, but I’m not the “target audience”. I’m also sure I forgot something super important. I always do.

Now I’ll go look at how other games solved this problem and realize I did it all wrong. Or not.

I’ve put together a short video of it in use, but it’s hard to tell what happening without knowing what buttons I’m pressing on the controller. If I was fancy, I’d have a little controller insert showing you what buttons I’m pressing, but I’m not fancy, nor do I have a building full of people that run around and make slick videos for me, so you’re stuck with this.

I’ll update as the controller scheme gets refined.

– Ron

Thimbleweed Park Podcast #39 Sat, 30 Jan 2016 15:39:00 -0500

Proof that you don’t have to know what your doing to make a game.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

You can also get the podcast directly from iTunes.

– Ron

Thimbleweed Park Podcast #38 Wed, 27 Jan 2016 14:58:00 -0500

The new podcast is here! The new podcast is here! The new podcast is here! The new podcast is here!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Thimbleweed Park Podcast #37 Tue, 19 Jan 2016 19:01:00 -0500

Sorry we were late last week. David, Gary and I continue to chat about the development of Thimbleweed park and what movies we saw this week.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

No Podcast This Week Sat, 16 Jan 2016 14:19:00 -0500

There will be no podcast this week. We were all very busy yesterday and never found a time we could all meet. I suppose I could have done it alone and rambled on incoherently for a while, but as much as you think you’d like to listen to that, trust me, you wouldn’t.

Today I am in the process of rebuilding the websites, moving everything from the old and decrepit http:// to trendy and hip https://. If you encounter any issues, please let me know.

In the meantime, please enjoy a quick concept sketch from Octavi

The Newest Code Monkey’s Report Mon, 11 Jan 2016 16:00:35 -0500

Ever since I formally became part of the Thimbleweed Park team I’ve been half itching to write a blog post, half scared silly at the prospect and wanting to cower under my keyboard. But here I am. So, no regrets, right?

Maybe before I go on you’d like to know a bit about me so you can get where I’m coming from? I’m just going to assume you’re yelling “yes” at your screen right now, ‘cause that’s what you’re doing, right?

Ok, since you insist… I grew up playing point-and-click adventure games in their “Golden Era”. Ok, fine, Ms Picky-person, I grew up watching my siblings play point-and-click adventure games (being the youngest sucks sometimes). I never thought that I could be a game developer, since that wasn’t something they told us at school and I was always a super-duper square who handed in my homework on time and actually liked school.

Hopefully, I haven’t lost your interest with that, I promise I’ve improved and I’m now a much more well-rounded individual. Mostly because part-way through finishing my Masters thesis in Artificial Intelligence I realised that I’m a game designer who can code (rather than a pure coder) and my life has been much happier since that moment.

Over my 6+ years in game development, I’ve dabbled in making small adventure games using AGS and Unity. Working on these small projects gave me an appreciation for the amount of work that must be involved in the old games I loved so much. So I was and still am really excited and proud to be part of the Thimbleweed Park team, even if my official title in the budget is “Code Monkey #2”.

Most of the work I’m doing at the moment is understanding the engine and wiring up rooms, I mean sewer tunnels. That’s right, my first proper coding tasks have been in the sewers. It’s a bit unglamorous. But it’s actually perfect for my first tasks. Many of the sewer tunnels are purposely very similar so as to make players feel a bit lost and confused. This makes it much easier for me to implement stuff, because I can just copy-paste all over the place, I can just copy-paste all over the place, I can just copy-paste all over the place, I can just copy-paste all over the place.

As I was doing the copy-paste dance, I realised that there were a lot of valves in the background art for the sewers. Now the vast majority of these couldn’t be truly interacted with, but they kinda looked like something that you should be able to interact with (especially because there is at least one valve you can actually turn). The valves are in different rooms and I didn’t want to do more copy-paste for what to say for each valve. That is, I didn’t want the characters to just say “It’s a valve that doesn’t move” every single time the player tries to look at it. It’s boring for the player and also frustrating because the player wastes time looking at the object and hearing the same line over and over again.

I was reminded of an old GDC talk by Elan Ruskin about dynamic dialog using AI and fuzzy pattern matching. In that, they talked about having running jokes about objects so that you could build on what the player knew previously. I knew I didn’t want to set up something quite so complex, but I wanted to do a little something to make looking at valves and using valves a tiny bit more interesting.

To do this I needed to create code that would be run for each of the valve objects that would set up its name, whether this specific valve had been looked at and what to do when looked at. So, to create one of these generic valves, you need to create it within a room using:

sewerTunnel2Valve1 =
    name = “valve”
    enter = function() { sewerValveSetup(this) }

The object’s enter code gets called every time the player enters this room. We have to name the object with a placeholder name, but we’ll allow the setup function to overwrite that value so if we decide to call those things “excessively boring valve thingamabobs” we don’t need to go through every room to change their name.

The setup function is defined in a new file I created called SewerHelpers.nut, which contains all of the generic code I used for the sewers (including setting up a sewer light, spinning fans, dripping water and so on).

So here’s the code to create a valve:

function sewerValveSetup(currentValve) {
    // Creates a boring valve we can look at = “valve”
     if ( ! currentValve.hasvar(has_looked_at) ) {
        currentValve.has_looked_at <- false
    currentValve.verbLookAt <- function() {
    if ( ! currentValve.hasvar(has_used) ) {
        currentValve.has_used <- false
    currentValve.verbUse <- function() {


Note that if this is the first time we’re running this code, we’ll set that this particular valve hasn’t been looked at. It will also keep track of whether the player has attempted to use the valve.

So now if the player tries to look at a valve, they’ll get something different to say based on how many valves have been looked at globally.

function valveLookAt(currentValve) {
    // For if the player looks at a valve that they can’t use in the game
    if ( currentValve.has_looked_at == false ) {
        if (g.look_count_valve == 0) { sayLine(“Looks like this valve has been welded into position forever.”) }
        if (g.look_count_valve == 1) { sayLine(“This valve has also been welded into position.”) }
        if (g.look_count_valve == 2) { sayLine(“Why have so many of these valves been welded up?”) }
        if (g.look_count_valve == 3) { sayLine(“Another welded valve.”) }
        if (g.look_count_valve == 4) { sayLine(“Didn’t I just see this valve?”) }
        if (g.look_count_valve == 5) { sayLine(“Lots of valves, but no Steam.”) }
        if (g.look_count_valve == 6) { sayLine(“This one’s rusted, not welded!”) }
        if (g.look_count_valve >= 7) { sayLine(“Seen one valve in the sewers, seen them all.”) }
        // Set that we looked at THIS valve
        currentValve. has_looked_at = true
    } else {
        sayLine(“It’s still a boring valve.”)

So after looking at 7 different valves we’ll just keep saying the same line over and over again, but at least the player got to have a bit of value for all their hard point-and-click work.

Learning how to code in Ron’s engine has been lovely and much simpler than I would have assumed after hearing the words “custom engine”. It’s easy to use and anytime I get stuck, I just post on the Slacks and Ron or David jump right in to help out.

I’ve been a newbie on many projects and I’m always nervous of those first few days and weeks (yes, and months) as you get to learn the new systems. I hate that feeling of bugging those more experienced with questions that they’re probably rolling their eyes about. But it turns out Ron and David are both fantastically friendly and understanding and are really quick to help me out.

As I kept bugging Ron and David I realised one of the major flaws of a custom engine. I can’t just google answers and find how everyone else has tackled the problems I’m encountering.

What this custom engine needed was some documentation!! (It also needs a proper name. I suppose technically it’s called ThimbleScript, but I don’t think that counts, do you? Ron… get on it!)

So I got started on my next, equally unglamorous task. Documentation is one of the tasks most coders hate doing, and I’m no exception. Still, it turns out writing the documentation is really helpful to someone getting to understand the code base (yes, I’m talking about myself, shock!).

I found a list of the command names, then I had to search for them in code, work out what they did and write about it. I’d often try to include example code, yet because I had been warned that this documentation would get released to the public, I tried to find non-spoiler examples (something that was quite tough in some special cases).

I know you’re on the edges of your seats waiting to find out whether I survived these tasks, and … (wait for it)… I did! So now if anyone else is lucky enough to join the team, they’ll be able to look through all the documentation and bug me instead of Ron & David!

You can check out the documentation yourselves.

Might make some of that code I just posted above make a bit more sense too!

I’m sure that’s enough Jenn for today… or is it?

Someone at my co-working space brought in little pixel stickers and I got a tad overeager and put up my Thimble-Team avatar on the wall. When I’m not at my desk, it looks like Pixel-Jenn is still hard at work putting pixels in the game.

– Jenn

Thimbleweed Park Podcast #36 Fri, 08 Jan 2016 23:59:00 -0500

Listen to the Thimbleweed Park Podcast episode where we spend exactly zero seconds talking about Donald Trump.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Pseudo Rooms Tue, 05 Jan 2016 15:52:00 -0500

Welcome to 2016. It sounds so futuristic. The other day and was joking around with Clayton and I said “Yeah, maybe in the year 2016!”, just picking some random date that seemed like the far future, but ironically, it wasn’t. As a kid who grew up in the 70’s, the year 2000 was a future filled with marvels and space travel. It was the year we picked to say “a long time from now in a world we can’t even imagine.”

OK, in all honesty, I don’t think I could have imagined the Internet, Twitter or the iPhone, so maybe it wasn’t that far off. I write this on a computer that runs billions of times faster than what sent the astronauts to the moon and has so much memory that I will never run out.

Back as Lucasfilm, Chip Morningstar used to joke that the perfect computer would have an infinite amount of memory and an expansion slot for more.

For Thimbleweed Park, I have that. Maybe it is the year 2016 after all.

We’ve been blogging about the game for a year now. It’s been a lot of fun, but also a lot of work. Writing one or two blog posts a week, plus recording and editing a podcast takes an amazing amount of time. Oh, and I have a game to make.

“Yeah, yeah, cry me a river Mr. Gilbert! Get on with the blog post!”

The engine has remained pretty stable for the past few months, mostly bug fixes and small features here and there. David, Jenn and I are finally getting to the point where we understand the engine enough that we can code in it without a constant fight.

Last week I added a new feature to the engine called Pseudo Rooms and I thought I’d spend our time together this week telling you about them. Grab a stool and relax while I spin a tale of mystery and deceit. A tale of adversity overcome and triumph of the good. A tale of… oh who am I kidding, it’s a bunch of source code.

We used Pseudo Rooms in the SCUMM system to construct a group of rooms that were based on a single template.  We used them mostly for evil maze, but not always.

In Thimbleweed Park, the Edmund Hotel is 13 floors tall, which means 11 floors of rooms once you eliminate the penthouse, the lobby and the mezzanine (ThimbleCon ‘87).  Each of those 11 floors has 10 hotel rooms, so for the math impaired, that is 110 hotel rooms. We could have defined 110 hotel rooms in art and code, but that would be grueling and inflexible.

So once again, I dip back into the SCUMM pool and pull out Pseudo Rooms. Pseudo Rooms allow us to define one hotel room and then use it as a template to construct as many other rooms – all at run-time – that we need.

It’s important that they are truly separate rooms so any state changes that happen in the room (turning on the TV, the bathroom sink, etc) are remembered for each room. We could write special code to track that in a single room, but that’s a lot of extra work. It’s much better if they are truly separate rooms. The other issue is Ray standing in room 307 and Ransome standing in room 610. If it was a single room, you’d see them both, but we need them in separate rooms without a lot of hoop-jumping.

Pseudo Rooms to the rescue.

You define a Pseudo Rooms using the (spoiler) command…

definePseudoRoom(“HotelRoom101”, HotelRoom)

This create a new room called HotelRoom101 based on HotelRoom. You can put an actor in it and treat it like any other room.


The code to build the entire hotel is as follows…


for (local floor_id = 3; floor_id <= 12; floor_id++) {
    local floor = definePseudoRoom(“HotelHall”+floor_id, HotelHall)
    floor.floor_number = floor_id
    for (local room_id = 1; room_id <= HOTEL_ROOMS_PER_FLOOR; room_id++) {
        local room = definePseudoRoom(“HotelRoom”+((floor_id*100)+room_id), HotelRoom)
        local door = floor[“hotelHallDoor”+room_id] <- “Room “+((floor_id*100)+room_id)
        door.hotel_room <- room
        door.verbWalkTo <- function()  {
        room.hotelRoomHallDoor.hotel_floor_door <- door

And the template room code is…

HotelRoom <-
    background = “HotelRoom”
    enter = function()
        if (objectState(this.hotelRoomRadio) == ON) {
            startthread(playRadio, this.hotelRoomRadio)

    exit = function()

    initRoom() {
        // Change the color of the bed.
        objectState(this.hotelRoomBed, random(1,3))
       // TODO – Change other things.

    hotelRoomHallDoor =
        name = “door”
        flags = DOOR_BACK
        hotel_floor_door = null        // Door on hotel floor to come out of
        verbWalkTo = function()

    hotelRoomPhone =
        name = “telephone”
        verbLookAt = function()
            Phone.receiverOff = FALSE
            Phone.whichPhone = this
        verbUse = function()
            Phone.receiverOff = TRUE
            Phone.whichPhone = this
        verbPickUp = function()

    hotelRoomRadio =
        name = “radio”
        initState = OFF
        verbLookAt = function()
            if (objectState(this) == OFF) {
                sayLine(“It’s turned off.”)
            } else {
                sayLine(“It’s turned on, and tuned to 198.7 FM”)
        verbUse = function()
            if (objectState(this) == OFF) {
                startthread(playRadio, this)
            } else {

    hotelRoomBed =
        name = “bed”
        verbLookAt = function()
            sayLine(“It’s a bed.”)
        verbUse = function()
            sayLine(“Not sleepy.”)

We’ll probably use them for evil mazes as well.

– Ron

Thimbleweed Park Podcast #35 Fri, 01 Jan 2016 12:34:00 -0500

With special guest, lead tester Robert Megone. Happy New Year Everyone! Your new year’s resolution is to go back and listen to all the podcast in reverse order looking for secret clues.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Voicemail Testing Mon, 28 Dec 2015 19:34:00 -0500

One of the Kickstarter reward tiers was to appear in the Thimbleweed Park phonebook. During the Kickstarter, someone in the comments suggested that it would be neat if they could also record a voicemail message.

Not being above stealing a good idea, we quickly added that and pretended we thought of it all along.

We’ve delayed gather all the names and voicemail messages because we wanted to make sure we were getting all the right information. We’ve implemented the phonebook and puzzle with dummy information and now we’re ready to start gathering names and voicemail recordings.

If all we were gathering were names, it might be easier, but we also need to gather recordings and have a place for people to upload them, plus we wanted to build a system that lets people go back and change the recording if they want.

I built such a system over the past few weeks, and now we need to test it. Nothing would be more embarrassing than having to ask 3000+ people to re-upload their recordings.

Which brings us to YOU!

Are you willing to help test out the voicemail system? You don’t have to be a backer to help test.  If you’re willing to help, follow this link and give us your email.

Testing will start in a few days.

Actual voicemail site will go live mid-January.


Testing has ended. Huge thanks to everyone who helped out. We found a lot of bugs that can only be found by swarming masses!

Here is the breakdown of around 500 readers in response to their primary language.

Thanks again.

– Ron

No Podcast For You Thu, 24 Dec 2015 21:07:00 -0500

There will be no podcast this week because we’re celebrating the birth of our savior, vamped consumerism. “Yeah, yeah, yeah”, you’re saying, “But did you get me anything?”

Yes, yes we did.

Enjoy this 1920×1080 HD Thimbleweed Park desktop wallpaper…


– Ron

18 Minutes of Thimbleweed Park Tue, 22 Dec 2015 12:22:00 -0500

I recently sat down with Ryan McCaffrey of IGN and we played through the first 18 minutes of Thimbleweed Park.

There isn’t anything in here you won’t see in your first 20 minutes of playing the game. There are some mild puzzle spoilers, but no real plot spoilers. If you’re the kind of person that doesn’t want to see anything about the game before playing it, I highly recommended avoiding the video (and probably this entire blog).

If you want to see the video on IGN use the following link: FOLLOWING LINK

– Ron

Thimbleweed Park Podcast #34 Sat, 19 Dec 2015 15:28:00 -0500

Where we fulfill our legal obligation to talk about Star Wars on a podcast.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Special Case Animations II Mon, 14 Dec 2015 15:25:00 -0500

This is a very exciting time for the project. We’re about halfway done with all the rooms and it’s time to start putting in what we call Special Case Animations™.

Maniac Mansion had no special case animations. Each of the characters had a four direction walk and talking and that was it. You can famously see this when someone climbs a ladder or uses the weight machine in Ted’s room. No animation.

The Indiana and the Last Crusade adventure game was the first place we used special case animation. The first one that went in was where Indy jumps down into a large pit. Steve Purcell did the animation and it was stunning to see the characters do something that wasn’t walking and talking. It was also an extravagance. Disk space was very limited and these SCA’s (as the pros call them) took a lot of space, so we had to “choose carefully” (ha ha).  LOOM had quite a few of them and Monkey Island built on that, but they were still a luxury.

Fast forward to the year of 2015 and disk space is – for all intents and purposes – unlimited. We can have an many special case animations as we want.  Well, almost and not really.

They take time to animate, so we still have to be a little picky, but not overly.  Each character has three reach animations: reach low, reach med and reach high.  For a lot of cases, we can just use one of these to avoid hand animating someone picking each and every object off the floor or a shelve. Reaching for a door knob isn’t exactly an game defining animation, just the opposite, it’s likely to be forgotten as fast as it can play.

But for other animations that define moments in the game, it’s important to animate them. Special Case Animations can show a lot about a character’s personality and help set the tone for the game.

As the project comes to a close, we’ll use any available animation time to go back and add animations where a simple reach just won’t do.

– Ron

Thimbleweed Park Podcast #33 Sat, 12 Dec 2015 18:50:00 -0500

Listen this week as we completely forget Robert was going to join us. Sorry Robert.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Refining Ransome Wed, 09 Dec 2015 11:51:45 -0500

It’s an interesting process working on an adventure game like this from inception to finished form, for us it’s definitely a very character driven process. One of the first things we do, is establish our main player character(s), aside from each’s obvious visual traits and associated costuming etc., it’s really based on the major aspects of their personalities formed by a character’s motivations short and long term.

At its core, Thimbleweed Park is about each of the five playable characters specific story arcs: Who are they as a person at the beginning of the game? Where are they going? Typically, not just down a path from one side of  town to the other, it’s about each one’s personal journey of discovery and how they might tend to grow from the adventure’s start to finish.

At the start of the process you can easily get attached to who you think a character is (and in my case, how they look). As an artist/character designer I have a tendency to almost immediately imagine a character’s appearance from the get go. Once I have an image of that character in my head, it’s usually not long to go from paper sketches to an initial pixel art representation.

In the event of putting something like the kickstarter pitch together, we had to pretty quickly make up our minds about the character representations and just run with it. This was a double edged sword as it served to put an important stake in the ground, but didn’t really allow us the opportunity to fully refine any of the designs.

Ransome described as a ‘Creepy Clown’ out of the gate had a fairly well formed personality (we had quickly thought up the rude clown persona and that gave us a lot to work with). He had immediately came to life in my head as a standard white faced red nosed bozo-type. Although this was a good stepping off point, we realized it was definitely too stereotypical to be his final look.

As a result, the first thing we tried was giving him a somewhat more unique hairdo. Given the 80’s vibe I then went ahead and tried a Mohawk version of his hairdo, after all, what could be cooler than “Ransome the Mohawk Insult Clown’? Although we sorta liked this, we got over it and moved on to try a variety of other approaches. Ultimately Octavi came back with a brilliant range of Ransome variations.

One of the things we really liked about Octavi’s designs, is that he really didn’t have any of the pre-conceived notions about the character I had stuck in my head from living with his formative personality over the previous year. Keep in mind we’d had a pretty clear vision of his personality forming in our psyche and it can be hard to get past that when you think you know a character – especially one you’ve had a role in creating.

One of Ron’s best pieces of advice is always be ready to change and refine when it truly makes sense. I had also been keying off of our earlier character development for Maniac Mansion and we really wanted to push some degree beyond that in the evolution of this character. Once we had an opportunity to see Octavi’s fresh takes, while somewhat out of the box they absolutely complimented our artistic vision and really did click. After a little back and forth we unanimously gravitated towards this version…

Here is Octavi, describing his process of designing Ransome:

Ransome’s creation process was really interesting, because Ron and Gary deliberately gave me very little information on how they imagined the character’s look and personality, as they wanted me to have full creative freedom. Of course, I had in mind the first version that Gary made for the Kickstarter campaign, but my job here was to create five completely new takes on the character to see if any of them would be suitable.

All I knew was that Ransome had to be a mean, bitter clown, victim of a curse that prevented him from removing his makeup. With this information I started working on my five renditions. I tried to make them as distinct as possible, with different ages, body sizes, clothes and facial expressions. But in my head all of them had to look kind of gross and scruffy. In my opinion the version that came closest to my overall idea was the last one: his skinny look, messy hair and missing teeth worked very well with the initial description of the character, so I’m glad that it was chosen as the final Ransome.

However, we soon realized that using this version would be a challenge when working on the animation, due to the asymmetry of his body. We didn’t want to lose the balloon as it gives a kind, childish touch, to a character that represents exactly the opposite, increasing its sinister look.

But the extra work of animation is well worth it. Of all the characters I’ve had the pleasure to work on for the game, Ransome is clearly my favorite, as it’s probably the most personal.

– Octavi

So behold Ransome in all his clownfro glory!

Additionally, all these other designs are still very useful, as there could still be other clowns around…? Or who knows maybe instrumental for a sequel…. ‘Ransome’s Revenge’ or maybe ‘Attack of the Killer Clown Clones?…. After all anything’s possible…

– Gary

Thimbleweed Park Podcast #32 Sun, 06 Dec 2015 16:26:00 -0500

Our podcast is now 32, which means it’s starting to get depressed that it’s no longer asked for id in bars.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

The Podcast is Delayed Until Sunday Sat, 05 Dec 2015 11:39:00 -0500

Friday’s podcast will be delayed until Sunday. I used to edit it Friday afternoon, but it takes over two hours and it was cutting too much into my work, so I moved to Saturday morning.

But today I’m going to be talking about making adventure game engines at HandmadeCon and I need to be there by 10am. I don’t know if it will be streamed or available later online, but it would surprise me if it isn’t.

Thank you for your patience. Please let this new piece of Mark Ferrari art distract your rage.

– Ron.

Friday Questions Wed, 02 Dec 2015 18:28:00 -0500

Hey boys and girls, it’s time for our favorite part of the show!

Friday Questions!

If you have any questions you’d like David, Gary or I to answer on Friday’s podcast, post them in the comments!

Please keep the questions focused and only one question per comment!

– Ron


I’m Just Going to Write Tue, 01 Dec 2015 12:39:00 -0500

Not sure what to write about this week. So much is happening, but so much of it is spoilers. I think this week I’ll do a little free writing. As I type these very words, I have no idea what this post is going to be about.

We’ve done three playtests so far and all of them have produced great information. The most encouraging part is they are producing roughly the same results. Players are liking and getting stuck on the same things. Those are easy problems to fix.

We did a little redesigning of the first 15 minutes of the game and added a simple two character puzzle to help teach that you can switch characters and that it’s needed, not just a fancy back of the box bullet point. It also makes the very beginning of the game a little more interesting because you’re doing some simple puzzle solving before being plummeted into the story.

The other thing we learned is that some of  our dialogs are too long, so we’re going through a pruning phase. Players thought the dialogs were funny and interesting, but there was too much information in there and it became easy to tune out. It doesn’t matter how good, useful or funny your writing is if players are just skipping it faster then they can read it.

I half-expected this, but wanted to watch some players to make sure. I often know something is wrong, but I need to see it.

There is also a funny/creepy little gag that happens right at the beginning that everyone missed. If you miss it, the game becomes temporarily confusing, so we cut the gag. We’ll probably reuse it later when it’s not critical if players miss it.

David and I were chatting on Slack last night about keyboard controls. One of the questions raised during the playtest was if you’ll be able to hit keys to select verbs. It was always our intention, but we hadn’t figured out how to lay it out.

I as favoring a grid layout, where the top left verb was ‘Q’ and the next over was ‘W’, etc. David was arguing for Open being ‘O’, Close being ‘C’, use being ‘U”, etc. Whenever these types of discussions happen was always ask “What would Lucasfilm Games do?”, so we busted out the old Lucasfilm game manuals to take a look.  Turns out we did it both ways back then.

The first letter matching the verb has some issues, mainly Push, Pull and Pickup. It also has the translation problem. How did the translated versions of old Lucasfilm Games deal with that? Was it successful? What is your preferred approach to mapping keys to verbs? Do you care?

I’m the wrong person to ask, since I never use the keyboard. I was the only person in my World of Warcraft guild to do hardcore raiding and never use the keyboard. I am a mad mouse clicker. It’s both a curse and blessing and a burden I live with.

Of course, the keyboard will be fully remappable, so you will be able to assign them to anything you want, but the default settings should feel good for most players.


– Ron

Thimbleweed Park Podcast #nan Fri, 27 Nov 2015 18:57:00 -0500

There will be no Thimbleweed Park Podcast this week as David, Gary and I are off enjoying Thanksgiving, but we’ll be back next week with an episode guaranteed to be riveting as it will be the first podcast of the month and we’ll be taking reader questions again.

I get asked a lot about when backers who get their name in the phonebook need to supplies details, including the VM message. That should all be set up by the end of the year and come January 1st, we’ll be sending out an email with details. We look forward to our witty, insightful, boring or entertaining VM messages.

– Ron

Our First Playtest Tue, 24 Nov 2015 13:01:00 -0500

On Friday, we had our first playtest for Thimbleweed Park. My friend Sarah came over and I watched her play the game for close to three hours. Next week Gary, David, and Robert will host playtest sessions with friends and family. Our goal is to do one playtest session every week until the end of the project in our elusive quest to “make a good game”.

There are different flavors of testing, each with a different goal in mind.

Bug Testing: This done by testers who are focused on finding bugs in the game. While it is part of what they do, their main focus isn’t on if the game is fun or not. They are playing the game over and over for weeks and months at a time looking for bugs and then taking the most elusive ones and figuring out how to reproduce them. They write up very detailed bug reports detailing what the bug is and how it happened. It is grueling work and can leave you hating the game (if not games in general). Good bug testers are very special and hard to find.

Focus Testing: I hate focus testing and will never ever do it. Focus testing is where you bring potential customers in and see if they like something, and in most cases, before it has been built. Focus testing fails because people know what they like, but often don’t know what they want. Focus testing is primarily used by visionless marketing departments. I will concede that focus testing might have a place in some kinds of products, but for art – which games are – it has no place.   Rant: OFF.

Playtesting: Playtesting usually happens one-on-one or with very small groups of players. You’re often watching testers as they play, taking notes and generally being very quiet (if not behind one-way glass). Your main goal is to see how a player approaches the game, where they spend their time and where they are confused and get stuck. Back at Lucas, and I believe it started with Indy, we would have Pizza Orgies. After work, the whole Game’s group, plus friends and family would get together, eat pizza and everyone would pay the game for a few hours, then we’d have a large group debrief discussion. These were great because everyone got to chime in and build off other comments.

Alpha/Beta Testing: This is where you’re sending hundreds (or in some cases thousands) of copies of the game to players and you’re looking for big picture issues. The games often contain analytics so the developers can see how far people are getting and what they are doing. These tests usually involve a lot of people, so you don’t drill down for specifics on each player. You’re looking for global trends. Alpha/Beta testing is also good for finding bugs that only a fresh one thousand new players can find.

When I do playtesting, I have a set of rules and guidelines I like to follow:

Before the Playtest

◼︎ Tell players you’re just going to be watching and not talking to them. Don’t engage in friendly chit-chat. Pretend you are behind a one-way mirror watching them. You need to make sure their impression of the game is playing the game, not talking to you. This is very important when players are friends and family.
◼︎ Ask them to talk out loud about what they are doing and trying, but not to ask you questions.
◼︎ Tell them there are parts of the game that are not finished and you might occasionally tell them not to do something so it doesn’t break the game.
◼︎ Tell them this isn’t a test of their ability, it’s for looking at issues with the game. We expect them to be confused and have issues, that’s what we’re looking for.
◼︎ Try and be as invisible as possible during the playtest.
◼︎ Remember, we’re not doing this as a validation that we’re doing a good job (that will come later), we’re doing this to see all the places we aren’t doing a good job. Players not liking the game is a good thing because it’s all stuff we can fix.

During the Playtest

◼︎ Don’t make excuses for the game. If you see a bug or a glitch, don’t say “That’s isn’t supposed to happen” or “we’re going to fix that”. Most players won’t even have noticed it.
◼︎ If the player takes a break for more than a few seconds, pause the game so we get an accurate count of the amount of time they played.
◼︎ Take notes on what people tried, not just when stuck but also as they explored the game. Did they go off in directions we didn’t expect? Did they want to do something fun that we don’t support.
◼︎ It’s OK to ask people “What are you thinking?” or “What are you trying to do?” if they are not verbalizing, just try not to make it sound judgmental.
◼︎ Let players be stuck for long long periods of time. Don’t hint players until they have been beating their head against something for 30 minutes or more. It’s agonizing, but let them struggle, there is good information in watching how they struggle and what they try.
◼︎ The goal of the playtest isn’t for them to successfully finish the game, it’s to watch all the problems they have.
◼︎ If players are obviously stuck and are getting to the point of giving up, don’t give them direct hints, instead ask them questions like “What are you trying to do?” and they will often figure it out just by verbalizing their thoughts, this also helps us figure out why people are confused.
◼︎ If they don’t solve it, give them subtle hints like “Look carefully at your inventory” or “Make sure you’ve fully explored the City Hall”.
◼︎ Players have a tendency to say “Is this what I should be doing?” and “Is this right?” when being watched, it’s best to respond with silence.

After the Playtest

◼︎ Be very careful when playtesting with friends and family. People don’t want to hurt your feelings and will tell you nice things. Let them know it’s OK to be very harsh and critical, that it helps us make the game better.
◼︎ Every time a player tells you something they don’t like, the game gets a little better.
◼︎ You might have to draw the negative comments out of people. Try not to look pleased when players say nice things, this encourages them to just say nice things and not bad things.
◼︎ Don’t ask leading questions. For example, don’t ask if they liked the music, ask if they have any feedback on the music.
◼︎ Ask follow up questions to probe deeper.
◼︎ Ask them to describe the story.
◼︎ Ask them who Ray is and to describe her.
◼︎ Ask them who Reyes is and to describe him.
◼︎ Ask about the the other characters. We’re trying to understand if the right information was conveyed. Don’t respond to questions about the characters or story yet.
◼︎ Ask them if there was anything about the story that was confusing.
◼︎ Ask them if there was anything about the game that was confusing or they didn’t like.
◼︎ Ask them where they were most frustrated.
◼︎ Ask them if they have any general feedback on the game.
◼︎ Ask these next questions last.
◼︎ Ask them what about the story did they liked.
◼︎ Ask them what about the game did they liked.
◼︎ At this point, you can answer questions and tell them what they might missed, etc.

The playtest with Sarah went very well. She got stumped on a couple of puzzles that need better focus or clarification on our part. She got fixated on solving one puzzle that was leading her in the wrong direction, so we need to make it clear about it not solving the problem it appears to solve. There was one large backwards puzzle we need to fix. We were pretty sure it was going to be a problem and this confirms it. She wanted to call all the phone numbers she saw and we need to make sure they have satisfying responses. Having just played Maniac Mansion, she found all the references funny.

After the first of the year, we’ll post a call for playtesters who want to come in and play for a few hours and endure our icy stares, cold silence, and hip lab coats and clipboards.

– Ron

Thimbleweed Park Podcast #31 Sat, 21 Nov 2015 15:06:00 -0500

More bla bla bla about Thimbleweed Park. Just shut up and let us play the game already! Does it really take this long to make a game!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Happy Birthday Thimbleweed Park Wed, 18 Nov 2015 13:54:00 -0500

One year ago today Gary and I launched our Kickstarter for Thimbleweed Park!

So… Happy Birthday Thimbleweed Park!

In lieu of presents, please click on the Support Us link at the top of the page and buy yourself a collectors edition boxed copy. You’re worth it.

As our present to you, here is some new art. Nothing says Happy Birthday more than a gorgeous piece of adventure game art. Or in this case, a horribly disgusting bathroom.

This weeks post is a few days late because we’re all scrambling to get ready for the first playtest by a non-Thimbleweed Park team member. We’re all giddy with excitement. I’ll do a post next week talking about how it was conducted, how it went and what we learned (spoiler free, of course).

OK, back to the salt mines.

– Ron

Thimbleweed Park Podcast #30 Sat, 14 Nov 2015 14:08:00 -0500

Listen to me be unable to pronounce “walk box” and we’re also joined by special guest star Malcolm Stead.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Early Brainstorm Tue, 10 Nov 2015 13:06:00 -0500

During last weeks podcast, someone asked how we came up with the idea for Thimbleweed Park. Like all creative processes, it was messy and fought with twists, turns, false starts and really stupid ideas.

When Gary and I decided we should do a Kickstarter to try and rediscover the charm of the old classic point & click adventure games, we didn’t have a clue as to what the game or story would be.

So our first step was to brainstorm ideas. Any ideas, no matter how stupid, just get them down and see where they go.

We spent about a week adding to this document…

Once we had all the ideas down, we each picked five we liked. There was a lot of overlap, but none of them felt strong enough to carry the whole game.

That’s when I had the idea of taking a few of the ideas we liked and framing them in a larger story, that of the Detectives. Once we beat that idea around a bit and decided it was the right direction, we brainstormed some names for the game…

And then we did some art, wrote some stuff, launched a Kickstarted, did some more stuff, built an adventure game engine and started blogging about it in the desperate hopes that no one realizes we have no idea what we’re doing.


– Ron

Thimbleweed Park Podcast #29 Sat, 07 Nov 2015 18:42:00 -0500

Where we spend 30 minutes answering a bunch of great (and two stupid) questions from the blog.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Friday Questions Wed, 04 Nov 2015 11:14:00 -0500

This Friday is the first Podcast of the month, so you know what this means? That’s right! Friday Questions!

If you have any questions you’d like David, Gary, I, or the team to answer, post them in the comments.

Don’t post a slew of questions in one post, we tend to ignore those. Keep your questions focused and they will have a better chance of being picked.

– Ron


Sprintastic Tue, 03 Nov 2015 12:14:00 -0500

We just finished our first sprint. I know what you’re thinking: “Don’t you have a game to finish? Why are you out doing track and field? Worst Kickstarter ever!”

Oh sure, to the layman it might sound like we’re running around the track, sprinting for the elusive 4 minute mile.  But rest assured, all of us are firmly planted behind our desks, sitting for 8 to 10 hours a day slowly developing heart disease. You Kickstarter dollars are hard at work (and slowly killing us).

In the parlance of game development, a sprint is where the entire team focuses on one small area for a few weeks, or maybe a month, striving to being it to a finished (or some other) state.

Sprints are nice because they give focus. With a large project (yes, Thimbleweed Park is a large project), it’s easy to get lost in all the “stuff” that needs to be done. I find without that focus, I tend to flit around doing little tasks all over the place, and mostly tasks that I find interesting, not necessarily tasks that need to be done.

Sprints allow you to focus and also attended to details. It’s easy to push off the little things in favor of large tasks, but a sprint gives you permission to attack the details.

Ideally, sprints should last less than a month. Any more than that, and you’re back to being lost in the sea of tasks.  Sprints also help to give the team a sense of accomplishment. It’s easy to see one section of the game go from raw to polished and it feels good.

This was our first sprint and the goal was to get beginning of the game and the town done and polished, at least up to the first choke point. It’s a nice little section of the game and it served double duty in providing a nice demoable section of the game.

We’re getting to the point where we need to have a publicly showable section of the game, and the town is perfect because it’s also the intro and playing through it won’t unveil any truly spoilerific details.  Keep in mind, this is not a demo we’ll release, this is a demo we can show at events and start the long process of playtesting (as opposed to bugtesting, which has already begun).

We’re aways from a releasable demo because the demo isn’t hardened. Too many places it can go hopelessly awry. It’s fine for controlled demos and playtesting, but not for releasing into the wild.

Thimbleweed Park is being divided up into seven sprints.

1 – Intro/town – Nov 1

2 – Circus (Normal and flashbacks) – Nov 25th

3 – County (Radio station and other misc locations – Dec 14

4 – Mansion – Jan 15

5 – Hotel – Feb 15

6 – Factory –  March 15

7 – Panic!

Then from March until ship, it’s general polish, plus getting translations and voice recording done.

Steve Kirk just started on the music but his track isn’t following the sprints due to the music being more global.

As I mention above, we’re going to start playtesting in the next week and if you’re in Seattle or the Bay Area, there might be an opportunity to sit down and play Thimbleweed Park while one of us stands over you in a white lab coat and a clipboard.

Stay tuned.

– Ron

P.S. There will be a separate post when we are looking for playtesters, so please don’t post your information here, it will be ignored.

Thimbleweed Park Podcast #28 Sat, 31 Oct 2015 15:52:00 -0400

I don’t think anything exciting happens in this podcast. It’s probably not worth your time to listen to.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Translation Baby Steps Mon, 26 Oct 2015 17:48:00 -0400

Today’s post is going to be quick and small. So much to do. I feel like we’ve entered the brunt of the storm after a few months of light winds. Bugs pile up and more tasks get assigned each day than we attend to. The water is raising faster than we can bail it out.

But that’s not bad. The game changes everyday. Art from Mark, puzzles wired up by David, new animations from Gary and Octavi and dialogs from me and Lauren. It’s exciting times for Thimbleweed Park.

A few days ago I decided to fully dive into the translation system. Text is currently burnt into the code. It’s easier that way, but it’s something that needs to change once the first pass of writing is done.

The first step was to write a preprocessor for Squirrel, then load in the spreadsheets with (sample) text and dialog ids. The final game will allow you to switch languages with the press of a key or button, you won’t need to restart.

A few months after the game ships, our plan is to allow user translations into any language you want, even made up ones. We’ll release all the text in a spreadsheet, change it as you wish, put the new file in the right place, and it will show up as a language. I predict chaos.

Thanks to the teeming masses on Twitter I was able to get a few lines of German in.

The verbs aren’t translated, but this is a proof-of-concept for the engine and it worked great. I also give no warrants as to the accuracy of the translation or the appropriate use thereof.

I’ll do a full write-up on how translations work next week, or the week after.

– Ron

Thimbleweed Park Podcast #27 Sat, 24 Oct 2015 12:54:00 -0400

Today we talk about our play-through of the beginning of the game and Gary won’t stop slamming his desk drawer.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Save Game Mon, 19 Oct 2015 13:59:00 -0400

For the first 9 months of this project, Savegame was my evil nemesis. It taunted and poke at me, refusing to ever heed enough to grant me the slightest satisfaction of how well the engine was advancing. Savegame would would pop up and say “How are you going to save that?”, and I would shrink down and reply “I have no idea.” My only victory over Savegame was my ability to lock it up in a cage buried deep in the dark dungeon of my mind and pretend it wasn’t there, tricking myself into believing the incessant howling was just the wind on a stormy night.

I knew I needed to confront this demon. When the cage could no longer hold the beast, it was going to be a battle that one of us would leave either dead or tamed.

The morning of the battle was as any morning was. Nothing about it hinted the confrontation that could — only hours later — lay waste to everything within it’s reach.

It began as an idea: “Hey, wait… what if I…” and that slowly formed into a plan. Some might call the idea cheating, but honor in war is a myth; you do what you can to win and this was no different.

My idea was a weapon, a special weapon that not only could, but would, mean victory and the defeat of my nemesis, Savegame.

The problem with savegames in adventure games is a vast amount of information that needs to be saved. Adventure games aren’t divided up into “levels” and I deplore the concept of “check points”, especially in adventure games. Players should be able to save whenever they want and expect to be back exactly where they left off upon load.

The issue isn’t file format. It’s not about whether you store it in JSON, XML or raw binary. The file format is the easy part.

What is hard is iterating deep into the recesses of the game and gathering up every scrap of data that might need to be saved. It’s not just a matter of saving some global variables that depict the state of the game, it’s the much more complex matter of tripping through the animation system, remembering each frame an actor or object is displaying. Going through all the objects in the game and saving off their state and the state of every local variable they contain.

The way the Thimbleweed Park Engine works, is that each room in the game has a piece of code called the enter code:

Nickel <- {
    function enter() {
        // Code that inits the room when entering
    // More stuff

This code is called whenever a room is entered or given focus. It’s responsible for setting up the state of any objects or actors that might be dependent on an external state of the game, as well as starting any ambient animations or sounds.

The enter code goes back to the SCUMM system and I’ve always found it a convenient way to organize the state of a room. It keeps all the code about setting up the room in one place, rather than spreading it around various object and other rooms in the game.

When you enter the Nickel, the enter code looks at the state of the game and decides if Natalie is there and then places her in the right spot. It does the same thing for the photocopy machine and the stack of newspapers.

And this was my idea, my +5 to cleaving idea that would finally vanquish my persistent foe.

When a game loads, I just re-enter the room. It saved me (no pun intended) from having to save a huge minutiae of detail about the current room and, more importantly, the state of all the multi-tasking scripts that might be running. The enter code would just restart them as needed.

All I needed to do was save off five pieces of information. 1) Global variables, 2) Local variables for each room, 3) local variables for each actor, 4) Internal state of each actor and 5) Internal state of every object.

On load, I would just re-run the enter code for the room the player was currently in and everything would be set back the way it was.

Step one proved to be a tad difficult. There are a lot of global variables, most of which are internal to the Squirrel interpreter. I didn’t need to save any of these, I just needed to save the global variables related to the game and I had no way to tell the difference. So, I did what I probably should have done to begin with, I moved all the game global variables in to a table called “g”.  Rather than “talked_to_sheriff” it was now “g.talked_to_sheriff.”

All the rooms, objects and actors are also in the global namespace to make it easier for the gameplay programmer and I didn’t need want to iterate through them from here, that would come later.

The other issue I faced was the data contain in each variable. Saving ints and floats is easy, but saving variables that possible contained actors, objects or rooms was a lot more complex.

Actors are defined as follows:

ray <- {
        name = “Ray”
        fullname = “Agent Ray”
        detective = YES
        ate_hotdog = NO
        ordered_hotdog = NO
        picked_up_tape = NO
        flags = GIVEABLE|TALKABLE
        // more stuff


The actorCreate(ray) command takes the table ‘ray’ and creates an internal actor and associates the table with it.  Later on in the code, something like this might happen:

last_actor = ray

And here is the problem. Tables are saved as references, so the variables last_actor and ray really point to the same table, they are not copied on assignment.  But, if the savegame system serialize both of those variables, they would become two completely different tables on load, not what we want.

Internally, actors (plus objects and rooms) are given a unique int id when they are created that the system uses to reference them, this is automatically added to the actor’s table and called _id. This allows the engine to know the actor that a table is referring to. The problem is, I can’t save those _id’s out, because they are assigned at run time, and if the order of the actor assignment was changed during a patch, the numbers would all be wrong, not to mention that if a new variables were added during the patch, it would be erased on load. One of the main criteria for the savegame system is that it must survive patches and updates.

So what I really needed to save was the name of the table (ray), so when the savegame system de-serialized last_actor, it knew it was the actor ray and could just point to that master table again.  The same is true for objects and rooms.

Since the engine keeps a list of all the actors, rooms and object independent from the tables in the code, after saving the global variables, I iterated through each of them, saving off the variables found in each table and also some internal state information that is not saved in the tables, things like x,y position, touchable, facing direction, etc.

All this information is saved in a JSON savegame file that looks like this:

currentRoom: “Diner”
inputState: 16
savetime: 1445006566
selectedActor: “ray”
version: 0
actors: {
    bankmanager: {
        _dir: 2
        _pos: “{540,11}”
        _roomKey: “Bank”
        defaultVerb: 3
        detective: 0
        flags: 131072
        name: “Mr. Cruffman”
        sawRaysBadge: 0
        sawReyesBadge: 0
        dialog: NULL
        last_room: {
            _roomKey: “Bank”

The savegame system knows when it sees an entry like last_room, it should look up the master table for Bank and place it in the variable last_room.

When loading, it serialize all the data, merging it with existing variables or creating new ones if they don’t exist, then it re-enters the room specified in currentRoom.

I also created two global functions…

function preSave() {
function postLoad() {

That get called, just in case there ends up being a complex situation that that needs attention. So far, there has been none, but the hooks might be useful.

I don’t need to save the state of the sound system, because most sounds are restarted in the enter code and this reduced the complexity of the task immensely. When I implement the music system, I will need to save it’s state because music sits above the current room, but that is a task for another day and shouldn’t be too hard.

There are two types of multi-threaded functions in the game: local and global. Local multi-threaded functions are killed when you leave a room and restarted when you enter, so I didn’t need to save these. Global multi-threaded functions needed to be saved, and I didn’t (and still don’t) have a good way to save these. It’s not just a matter of saving a few local variables and the PC, there might be a complex nested call stack, each with it’s own set a local variables and enclosures and it all needs to be saved and then recreated on load. I looked at the Squirrel source code and I don’t see an easy way to serialize and recreate a running thread.

The good news is that we don’t use global scripts very often and in each of those cases, they can be done in a different way, so I opted to just not save global threads. Problem solved. I’m sure it could be solved if I wanted to bang my head against the problem for a few weeks, but it’s just not worth it.

There are two downsides to my “enter the room on loaded” scheme.

1. If an actor is walking across the room when you save, and then you load, they will stop walking. I don’t see this as a huge downside. Chances are you’re loading the game a few hours, it not days, later and I don’t think you’ll remember where they were headed. The enter code restarts any NPC, so they will behave normally.

2. You can’t really save in the middle of cut-scenes as that would require you know where actors were walking and the exact state of the entire animation system at that moment, precisely what I was trying to avoid.

My solution to that problem was to silently save the game right before a cut-scene, and then if you save during the cut-scene, it actually saves the game saved right before. The downside is you might loose a little progress, but we’re trying to keep all cut-scenes to less than 10 seconds, so you won’t really loose much, and once again, I don’t think most players will even notice and it saves a ton of time on my end that I’d rather be using for other things.

And that’s the save game system.


– Ron

Thimbleweed Park Podcast #26 Sat, 17 Oct 2015 14:02:00 -0400

In this episode we spend way too much time talking about our dogs.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Thimbleweed Park Gameplay Mon, 12 Oct 2015 13:58:00 -0400

There might be some small spoilers in this video. Nothing big. No puzzles or plot information revealed, but I know some people don’t like spoilers of any kind, so we’re disclaimering this one.

It’s a five minute walkthrough of the Thimbleweed Nickel Newspaper, a little of one of the streets and the Post Office, all featuring some new art from Mark and a couple of characters from Octavi.

As with anything we post here, this is not final art and animation. There are a lot of little issues we’ll be addressing during the various polish phases.

Please, sit back and enjoy my soft, emotionless narration as I take you through a bit of the game.

– Ron

Thimbleweed Park Podcast #25 Sat, 10 Oct 2015 15:12:00 -0400

Now, with 100% more Mark Ferrari!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

P.S. I promise I will buy a new mic this weekend so I’m easier to hear. All that Kickstarter money isn’t going to spend itself.

Team Thimbleweed Mon, 05 Oct 2015 14:52:40 -0400

We left pre-production at the end of July and entered the grueling process of production, turning the crank on the big machine labeled “GameTron 3000™”, feeding ideas and game design document in on one side as finished rooms rolled out the opposite end on a long conveyor belt.

Along with starting production comes carefully increasing the team size, because endlessly turning a crank is hard and tiring work.

So let’s start with the introductions… please hold your applause until the end.

Octavi Navarro, a self-taught pixel artist and former children’s books illustrator from Barcelona and the creator of the amazing ‘Pixels Huh’ , a love letter to pixel art and to all the classic videogames that marked his childhood since the day his parents bought him a second hand Commodore 64 bundled with a box full of games. His work has been featured on some of the world’s greatest art and design publications and feels very lucky to work with extremely creative people who share his passion for pixel art and acknowledge it as a legitimate art form. You can find him on Twitter at @pixelshuh and Facebook.

Octavi will be doing animation and helping out Mark with backgrounds.

Lauren founded Dropped Monocle Games with her friend Sox Brooker in 2012. While discussing their love of point and click adventure games after an evening of DnD, and probably too much cider, they decided they could totally make a game! How hard can it be? This led to the creation of a “charmingly crap” point and click called Witchy Woo. In spite of its “flaws” (although it still won the game jam), people seemed to like her writing, so they kept doing it and whipped up a couple more games, including another jam winner, Mess Goblins, and Goatherd and the Gods, nominated for several AGS awards. You can follow her on Twitter at @boosegoose.

Lauren joins the team as a writer.

Jenn hails from Australia and has been playing adventure games since she could work out how to kick her older brother and sister off the computer. With a background in artificial intelligence, Jenn has been working as a game designer for over 6 years. She’s made a number of point-and-click adventure games and twists on the genre. Her determination to challenge conventional gameplay mechanics led her to complete a personal challenge to finish 12 games in 12 continuous months; many of which were story-rich games. Her latest game, aglimpse: friends, is a photo challenge game that lets you re-connect with friends in a personal and visually unique way. You can follow her on Twitter at @jennsandercock.

Jenn comes on board as our second game play programmer.

Robert Megone is a Game Designer and QA Tester from Hampshire in the United Kingdom. Rob has worked as a tester for Clayton and I on Scurvy Scallywags and for David on his Rube Goldberg game. Rob understands point and click adventures from the perspective of a developer but more importantly from the perspective of a player. His first adventure game was Zak McKracken on the C64, a game that is almost entirely responsible for his obsession with point and click adventures. You can follow him on twitter at @robertmegone or on his website.

Robert joins Team Thimbleweed as its lead tester.

Malcolm was raised by pirates off the coasts of Bristol, England; Malcolm escaped to the circus, where through random fate encounters, he made a living cosplaying Muppets for underprivileged giants.  Malcolm had his first game published at the age of 14, and has been working as a tech programmer/game designer professionally for the last 20 years.  He now works as an independent contractor under the guise of “Confused Duck Entertainment” and promises one day to finish the website.  When he’s not working on Thimbleweed Park, Malcolm is trying to finish the iOS game “Naked War”.  In 2006, Malcolm happened upon the lovely Vancouver city in Canada-land where he and I met while working on Deathspank.

Malcolm has been on the project for about a month and is primarily responsible for the Xbox port.

Please welcome our latest team members!

– Ron

Thimbleweed Park Podcast #24 Sat, 03 Oct 2015 13:56:00 -0400

Listen to us mangle reader names as we answer Friday questions.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Friday Questions Wed, 30 Sep 2015 10:18:00 -0400

Friday’s podcast will be the first of the new month, so it’s time for Friday Questions™ (although, I don’t often get the podcast editing until Saturday morning while I’m eating my cereal and watching cartoons, but now we’re splitting hairs).

Anyway… moving on…

If you have any questions you’d like us to answer live on the air, please submit them in the comments before 9pm PDT on Thursday (or Mustard o’clock if use international color time like I do).

To increase the odds of us taking your call, please keep your questions to one sentence, otherwise it’s too hard for us to explain the question before we answer it. Also, if you begin your by question telling us how awesome we are, that also increases the odds.

– Ron


Occult Bookstore Mon, 28 Sep 2015 14:00:00 -0400

Behold the Thimbleweed Park Occult Bookstore, serving all your Occult book and Ouija Board needs since 1948. If you’re looking for a Rubber Chicken with Pulley in the Middle, please visit our sister location on Mêlée Island.

A few months ago, we asked readers to submit names of books for the Occult Bookstore, figuring we’d get a few hundred titles. Crap were we wrong! We got over 3000 submissions! What we didn’t plan on was having to copy all those names from the website and into the game.

Mark finished the first pass of the art last week and he built the room so it could be easily extended up since we didn’t know exactly how tall it needed to be.

All the book titles were put into a spreadsheet and were sorted and dups removed. The spreadsheet was then copied to a text file the game reads and builds all the book objects at run-time.

We haven’t gone through the list and pulled out titles that are too long, offensive, or objectionable for other (legal) reasons, but our first culling says that is less than 50 titles.

There is a puzzle where you need to find a specific book, but you don’t do it by trial and error and searching, there is another “object” that allows you to locate it quickly.

Huge thanks goes out to everyone who contributed a book title, this could mean the difference between a “Game of the Year” and “Bargain bin discount.”

– Ron

Thimbleweed Park Podcast #23 Sat, 26 Sep 2015 12:14:00 -0400

So boring, you know it’s not faked.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Slicy Mon, 21 Sep 2015 16:20:00 -0400

I’m a firm believer in automation. Humans screw things up and the more times a human needs to touch something, the more opportunities there are for something to get screwed up. This is very true of build processes. Building a game should be a single step and complete handled by scripts; less opportunity for humans to get in the way.

Build processes are boring and monotonous and anytime a task becomes boring and monotonous it’s ripe for humans to screw it up as our brains turn off and our mind drifts.

Automating the build process of code is relatively straightforward. You create a script (bash or .bat file) and execute all the steps. Automating art is a lot harder. Art is made up of a lot of little pieces and art tools are notorious bad at exporting as an automated process. There is a lot of clicking and naming files and each of these steps begs for humans to screw it up.

A few years ago, when I was working on Scurvy Scallywags, Clayton and I faced a very similar problem. We had a ton of little art assets all in Photoshop files and layers. If the art changed, I’d have to find the change and save it as a .png. Photoshop has a “Export Layers to Files” option that is all but useless since it requires typing in of filenames and exports as numbered sequences. It’s also painfully slow.

Then I stumbled across a program called Slicy that takes a Photoshop file and exports .png files based on how you name the layers. It was like magic and (quite literally) change my life. If anything in the Photoshop file changed, I’d drag the file into Slicy and it would spit out all the .png files, named exactly how we needed them.

I would then type ‘munge_art’ on the command line and everything would be run though TexturePacker and was in the game before you could say “robot overlords”.

I adopted this same practice for Thimbleweed Park. The amount of art in the game compared to Scurvy Scallywags is staggering. Close to one hundred rooms, each containing a gaggle of objects and parallax layers, all needing to be saved out and packed into sprite sheets.

The Photoshop files for rooms are organized into layers as follows:

You can download the actual Photoshop file that Mark created here). Please keep in mind that this file still has to pass through a polish phase and is not done yet. There is even some programmer art in there. Programmer art is when the programmer will quickly add something to get functionality working, then it will be replaced later by a “real” artist.

The @bounds layers you see tell Slicy what part of the image to export and the name of the layer is the .png file that’s created. TexturePacker then takes all the .png files and packs them together (with empty space remove) to produce a spritesheet that is used in the game.

I like this process because there is little chance of error. If Mark makes a change to the room art, we don’t need to hunt down the layer and save it, we just drag the .psd file into Slicy and we’re done.

– Ron

Thimbleweed Park Podcast #22 Sat, 19 Sep 2015 12:23:00 -0400

They say better late than never, but in the case, maybe never is better than late. We were plagued with technical issues, so apogees all around for choppy audio in places. It’s only a podcast about making a game, it’s not like we’re describing how to do brain surgery.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

A Pixel Here a Pixel There… Mon, 14 Sep 2015 15:09:00 -0400

One of the things you’ll find drawing in lower screen resolutions (individual non-scrolling screens in Thimbleweed Park are typically 128h x 320w or 172h x 428w) is that the placement of a single pixel here or there can make a real difference as to how an object, character or background may look.

In the good old days of pixel art working on C64 Maniac Mansion I first worked in character set, screens and objects made up of 4×8 pixel tiles where repetition was a necessity, brick walls were pretty easy, while organic animated characters were definitely more of a challenge.

Certainly, a reason for the larger heads in Maniac Mansion is that it allowed for much more nuance of personality. Working on the characters in Thimbleweed Park that are a throwback to that time presents us with a lot of the same basic problem solving.

For example if you’re trying to create a five frame talking mouth in a 8×4 or 5 pixel grid there’s only so many permutations that are going to look like they make sense. Aside from using various animation frame references it needs to look right to you when you actually plop down the closest bit pattern you can manage in that grid. Scanning doesn’t really work at really limited pixel and color resolutions, it just comes down to noodling that tiny grid by hand.

Believe it or not, when I first started working on adventure games at Lucasfilm we didn’t even have access to scanners. One of the the techniques I developed at the time was to first draw something, usually a character on regular bond paper, then I’d trace that onto a clear piece of plastic (acetate) with a sharpie, tape it to the front of my monitor and proceed to draw that in whatever paint program from behind the plastic overlay using that as a guide to plot each pixel into its somewhat appropriate position on the screen.

It was a haphazard way of getting the basic drawing done but actually worked pretty effectively for me at the time. Then of course, I’d touch everything up by hand, working on a face or even just the position of an eye I’d spend a good deal of time moving a single particular pixel around within a small grid trying to find the best possible location relative to its surroundings.

Although a lot has evolved relative to tools and platforms, it turns out not that much has changed relative to discerning the best bit pattern placement of individual pixels when working within a very limited pixel space.

Whether you’re dealing with a face or a font, it comes down to the artist or designer looking at the overall graphic and hand placing that dot (or rectangle). On a level this can become very abstract, magnifying, zooming in and out, etc.

A lot of folks have said to me, given what I’m doing, why do I work on a 15″ laptop screen instead of a bigger higher resolution display. In my case it’s reasonably simple, I want to see the graphics and animation the way most of our end users will- that way I know it things will likely look their best to the greatest number of players in the audience.

– Gary

Thimbleweed Park Podcast #21 Sat, 12 Sep 2015 01:32:00 -0400

The Thimbleweed Park Podcast can now legally drink in all 50 states.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Budget Mon, 07 Sep 2015 18:28:00 -0400

During last week’s podcast, I asked Gary and David what scares them the most about the project. I find this a useful exercise to do with the team to see what they are worried about. The answer always changes as the project progresses and new worries come and go.

The common theme from the three of us was the amount of work there is to do. It’s daunting. But as I’ve said several times on this blog, that’s normal. I’ve never not been daunted by the amount of work facing me on any game I’ve done. If you’re not daunted by the amount of work, there’s probably something wrong and you need to be pushing harder. Be daunted and push yourself right up to the point of being overwhelmed.

During the podcast I mentioned my concern about money and seeing the bank account go down each month. This was somehow turned into “we’re running out of money”, which is far from the truth. I am worried about money, anyone running a project should be.

The thing is: I worry about things so they don’t become problems, and worrying about money is one of those things. If we didn’t worry about money everyday, we would run out of money. It sneaks up on you.

Seeing $500,000 in your bank account can make you cocky. It can seem like an endless supply of cash and more money than most people (including me) have ever seen in their bank account. But you have to treat that $500,000 like it’s $5,000 or even $500. Every dollar matters.

It’s why I like to have a budget.

It is one of the advantages of having a publisher, they will poke your budget full of holes and challenge your assumptions. The downside is, they will also push your budget down and it’s not uncommon for developers to then fake the budget so they get the deal (which their studio is often dependent on to stay alive). It’s not malicious, they (and I have done this as well) just convince themselves they can make it for less, and that’s often not true.

I want to know where every dollar is being spent from here until the end of the project. You start putting line items into the budget and you instantly see your money starting vanish. A few line items later and you’re out of money. It’s sobering and a necessary process. It really makes you appreciate spending anything.

We had budgets back at Lucasfilm, but we were very isolated from the gory ramifications of those numbers. I could make a budget and if I went over by 20%, I might get a stern talking to, but it’s not like people weren’t going to be paid. When you’re running your own company and project with your own money and you run out, people don’t get paid and they don’t like that. In the real world, they stop working.

I do a first pass budget before I start designing. I often know how much money I have and I want to see how many people and how long I have before that money is gone. If I know I have 15 months and can afford 5 people, then that helps me in scoping the design. If I have 24 months and can have 100 people, that’s another scope.

Once I’ve done the preliminary budget, we’ll start designing and then enter pre-production, all the while, adjusting the budget as I know more.  When pre-production is done, we can look at the amount of work and do a final budget based on the schedule. Budget and Schedule are two different things that feed into and help refine each other. You can’t do one without the other, but they aren’t the same thing.

A schedule lists everything you have to make and who is going to make it and when. A budget takes all those people and how much they cost and tells you what the project is going to cost.

Below is the current budget for Thimbleweed Park.  It’s what I like to call a living budget. You’ll notice that the first monthly column is October, not the beginning of the project. Money spent is “water under the bridge” and is only relevant for historical and educational reasons. What I want to focus my attention on is how much we have and how much we need to spend going forward.

Anyone who has a real background in accounting is probably having spasm right now. There are much better ways to do this, but I’m not an accountant and neither are most indie devs. This is a much simplified way of budgeting and it works for me.

Each month I look at what we spend versus what we expect to spend then make any adjustments to future costs. I then remove the current month column, look at the projected total and the bank balance. If there is more in the bank then we’re projected to spend, then we’re OK, back to programming and designing.

Let’s go through the budget.

First up are the people. Gary and I are working for peanuts (honey roasted). Neither of us can afford to work for free for 18 months and we’re making about a quarter of what we could get with “real jobs” but we do need to eat and pay rent.

Everyone else is working below what they could get, but I do think it’s important to pay people. I don’t feel getting people to work for free ever works out and usually ends badly (and friendships) or you “get what you pay for.” The reality is that when someone works for you for free, you aren’t their top priority. They may say you are, they may want you to be, but you rarely are and you end up dealing with missed deadlines and hastily done work.

It’s important to have team members that can work as professionals and you pay people that are professionals. You should respect people’s time and talent and pay them for their work. It’s what the Kickstarter money was for after all.

Everyone is budgeted in at 5 days a week and 8 hours a day as we’re trying to keep normal hours. I have no doubt these hours will go up towards the end of the project, but I try to never budget crunch time, it’s a dangerous precedent. It’s a cost we will have to manage down the road, either by hiring someone new, spending for extra time, shifting resources or cutting content. There is enough slop built into the rest of the budget to cover some of this, but I never want ink to paper, because then crunch becomes real.

We do have two additional artists budgeted and yet to be hired. We don’t know if we’ll need both of them, but I’ve budgeted them just in case. We might need help with animation and there are also a lot of close-ups (telephones, control panels, bulletin boards, etc) and ancillary screens that aren’t on Mark’s schedule right now.

There is a line item for an additional writer. We made the decision to go with full Monkey Island style dialogs and I don’t feel confident I can get all those done with everything else I need to be doing (like budgeting).

Testers, testers, testers. One of the most important and often forgotten roles in a game. It’s money well spent because not testing will cost you down the road in emergency patches, dissatisfied players and crappy review scores. The original budget had 3 testers, but I added a 4th when we added the Xbox. I over budgeted for testing and it’s an area that will probably come in under budget (ass, prepare to be bitten).

It’s important to distinguish between testing and beta testing as they serve very different functions. The paid testers on a project are there to (primarily) find and help squash bugs. This is a paid role because it’s grueling work and, quite frankly, not a lot of people are really good at it. Testers don’t just “play the game”. They are “testing” the game and that often involves countless hours of playing the same 5 minutes over and over, trying to get an elusive bug to appear. Testers need to write clear and concise bug reports and endlessly regress bugs to make sure they are fixed. It’s a hard job. Good testers are worth every penny.

Beta testing is different. Beta testers (an unpaid role) are still finding bugs, but what you’re really looking for are big picture issues, like puzzle complexity, game flow and story clarity. You want beta testers to “play” the game like normal players will and get feedback (mostly through silently watching, analytics and debriefs). You want to turn 50 beta testers loose and see where they go and what they do.

Next we come to Music and SFX. Musicians usually charge by the minute, so if you’re going to have 15 minutes of unique music and they charge $1000 a minute (not uncommon), then your budget is $15,000. That $1,000/minute includes a lot of exploration and revisions and mixing. If you’re saying “Hey, I’ll do your music for free” you need to ask yourself if you’re willing to spend weeks exploring different styles and tracks while getting constant feedback, then spend months composing it all, then additional months of making little revisions and changes, then producing 3, 4 or 5 flawless mixes. It’s a lot of work and all the while, you have to hit deadline after deadline. And this is all for a relatively low budget game.

Next up on our journey through budget land is Translations, Voice Recording and Mobile. I’m kind of rolling the dice on these. I don’t have a good idea what these will cost so I’ve padded the hell out of them and I expect this is where a lot of the slop will come from to fill other leaks. I got bids for voice acting and translation then added 30%. I have no idea on iOS and Android. I just chose a big number. This is where the voodoo of budgeting really plays out. If we had a producer, they would be spending more time nailing these numbers down. I’ve added enough extra that I feel comfortable.

On to Events. This is for stuff like PAX, Indiecade, E3 and other events we might want to show the game at. All this is really marketing and PR. It’s also where we will pull extra money from if we get in trouble down the road. Not showing the game will screw its long term hopes, but not finishing the game is worse. Plus, it’s a number we can scale up and down as needed and it’s far enough down the road that we’ll have better idea of how we’re really doing.

Then it’s on to the really exciting part of the budget: Legal, Accounting, Software, and the always important Misc. Assuming we don’t get sued, these are fairly predictable and fixed expenses, but don’t forget them.

And finally, the Kickstarter physical rewards. We have a fixed budget that was based on our final Kickstarter pledge numbers. It’s probably around 25% too high, but that gives us some flexibility to make a better boxed copy or use the money elsewhere on the project. Or, we might have estimated wrong.

At the bottom is a total. I look at that each month and look at the bank balance. So far, we’re fine. But that’s because I worry.

One thing that is not on this spreadsheet is the money that is currently coming in from Humble Bundle and new backers. It’s not significant, but it’s not inconsequential either. I choose the leave it off the budget calculations because it provides this small margin of error.

We are planning on some new stretch goals in the next few months, and those are also not in the budget because if we don’t make the goals, they won’t become expenses. If we do, then all the numbers will be adjusted to account for the new work.

It’s also possible that we’ll move resources around, spend less on an artist and add a programmer. Budgets are living documents.

One thing to note, and I’m sure it will raise some eyebrows, is the monthly burn rate. That’s a lot of money to spend each month. No one line item is very large, but they add up and can catch you by surprise. This is a pretty barebones project (but not scrappy) and it still costs $20K-$30K a month. It why when I look at other Kickstarters asking for very little money and they have a three page long team list, I get skeptical.

I hope this was informative. There are a lot of ways to do budgeting and I’m sure there are better ways, but this has always worked for me.

Please be respectful that we’re sharing a lot of information with you, not only to be transparent, but also to educate and inform. This is how games are made, they take time, cost money and it’s a very messy process.

– Ron

Thimbleweed Park Podcast #20 Sat, 05 Sep 2015 14:17:00 -0400

Listen to Gary, David and I describe what scares us the most and curiously, thermal nuclear war didn’t make the list. In the 1980’s that’s all that would have scared us. That and the big hair.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

P.S. Sorry this is a day late.

The Secret of Monkey Island Turns 25! Thu, 03 Sep 2015 18:57:00 -0400

Read all about it on Grumpy Gamer.

Walking and Talking Mon, 31 Aug 2015 21:54:19 -0400

Quick blog post today.

Spent much of the weekend and today rewriting my engine’s animation system to give it more flexibility for doing walking, talking and other multi-layered animations.

The main issues is wanting to play a talking animation, which moves the mouth and head, but then wanting to play other animations, like walking, pointing, shrugs and other gestures.  If every animation has to have a version with talking, the permutations quickly makes you want to bang your head repeatedly against your desk.

SCUMM had a great animation system called Byle.  It could play several animations simultaneously, and as long as they used different layers it would play them all at once. It made doing things like playing a talking animation and then playing a shrug really easy.  It was also easy for the artist, because they would just have an attach point for the head and could move the body as needed.

This stuff is pretty routine for 3D animation systems or 2D animation systems like Spine, but for pure bitmap graphics, I have yet to find a good one.  So, as often happens, when I can’t find a tool that works, I just say fuck it, I’ll write my own.

Gary started by the chunking of Reyes’ animations into head, body and mouth layers and we went through several iterations of how to best layer them for maximum flexibility and (more importantly) ease of creation.

Our system also allows for the option of lip-syncing, if we decide to do that. The system understands the basic vowel positions and can set the mouth frame based on external input. Right now it’s just a weighted random number, but if we had lip syncing data, it would be fed in instead.

I don’t know if we’ll do lip syncing, it’s an amazing amount of work unless it’s automated and I haven’t looked into the current state of automated lip-syncing. Eight years ago it was crap, but we now live in a future of self-driving cars and staying in strangers houses instead of hotels, so who knows what other crazy things have been invented.

If you know of any software that can pre-process audio files and produce a lip-sync track, let me know. It doesn’t have to do it real-time, it can (and probably should) be a pre-processed staged.

Gary and I also decided to do head bobbing along with mouth movement, but reduced from what was in Monkey Island. Back at Lucasfilm, when we went from the large headed characters to more realistically proportionally sized heads, the mouth became a single pixel and it was hard to tell if Guybrush was even talking.

With the larger stylized heads in Thimbleweed Park, it’s easy to tell if they are talking, but having no movement of the head felt too static, so the plan we ultimately fell on was to have two head positions; normal and up.  80% of the time, the head is in the normal position and will randomly go to the up position 20% of the time.  I think it works well, but I’m sure we will endlessly tweak it in the coming months.

As with a lot of what we post, what you’re seeing is not final animation, just something we put together as a test, so don’t nitpick. There is still a lot of work to do.

– Ron


Thimbleweed Park Podcast #19 Fri, 28 Aug 2015 19:37:00 -0400

In a podcast that would be unthinkable 25 years ago, we answer reader questions from the Internet and David explains why if your not using a VAX 750 and Emacs to make games, you’re doing it all wrong.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Friday Questions Thu, 27 Aug 2015 13:42:00 -0400

In the interest of making the Friday podcast more exciting (for us and for you), we’ve decide to add a “Friday Questions” section where David, Gary and I answer and chat about your questions. I think it will be more fun to answer them on the podcast, than in the comments because we can talk about the answers and have more fun with it. If there is anything this project needs, it’s more fun.

OK, so this is how it works. In the comments, ask us a question and we’ll grab 10 or so that are interesting and/or informative and do our best to answer them.

You have until 10 am (PDT) Friday to post your questions and please keep them focused on Thimbleweed Park or the adventure games one of us was involved in.

– Ron

Questions are closed

State Of The Game #2 Mon, 24 Aug 2015 11:58:00 -0400

It’s time for another State of the Game post. The last one was in May, and it’s now the glorious month of August and a lot has happened. Part of our commitment to you when doing the Kickstarter was to keep everyone informed on our progress and adventures.

Making games is Fun. I can’t imagine doing anything else with my life, but it’s also stressful, exhausting and can be demoralizing. It can wake you up in the morning with vigor and excitement and send you to bed with a sense of doom and defeatism. If there was one emotion to describe my mental state at this stage of the project, it would be “overwhelmed.”

But that’s normal.

Pre-production is the exciting time of a project. Everything is possible and your only limit is imagination. You design and create and dream with reckless abandon. It’s the way it has to be.

Then you enter production, the stage we find ourselves in now. It’s the stage where the mind of a dreamer crashes into the mind of a realist. You budget and schedule and track every detail as it oozes its way through the process. You become terrified with what you’ve designed and fight the desire to just hack limbs from the body to cure a disease.

But that’s normal.

How We Got Here

Despite the doom and gloom of my opening, the project is in a really good state.

We’ve come a long way in the five months since I first got the scripting language working…

And where we are today…

A fully functional adventure game and adventure game engine with final art and puzzles and funny dialogs that are showing the promise of what we set out to create: an all new classic point & click adventure game.

The big news over the last three months was the addition of Mark Ferrari to the team. When Gary and I did our Kickstarter, we didn’t know how much money we were going to raise, so we described an art style we knew we could do with just Gary as the sole background artist and animator. It truly invoked the era of Maniac Mansion.

When Mark became available, we both knew we had an opportunity to move the art forward. We raised more money than we thought and Mark becoming available full time was an opportunity we couldn’t pass up. But it posed some challenges.

The animations needed to change. We’re happy with the overall style of the characters, and as we’ve stated several times, we’re keeping with the large bobble heads, but it’s been a challenge to figure out how to render them to fit with Mark’s art.

Mark is a master of lighting. If there is one thing that defines Mark’s art, it’s his lighting. I spent an hour on Skype with Mark, him asking questions about the direction each room faced and where the setting sun would be so he could capture the glow of the dimming evening just right. Mark wasn’t satisfied with “It’s early evening, the sun is setting somewhere over there.” He wanted to know exactly where the sun was so he could draw each room with the correct light coming from the right direction.

“I don’t think anyone will notice”, I said.  “Oh yes they will,” Mark replied and I think he’s right. Maybe not consciously, but the light being right makes things more real and believable. You don’t notice it, but you do notice it. Details, no matter what they are, are like that. You don’t notice, but you do.

The art is going to be a lot more work than originally planned.

Wiring of the rooms during pre-production went well. David is a machine with that stuff. He is amazingly detail focused and wiring the wire frame rooms up during pre-production went pretty fast.

We cut 25 rooms from the game and the game feels better for it. That wasn’t an easy job, but it was a necessary job.

We’ve added two major puzzles to the game as a result of playing and realizing we need to gate players into some key (and exciting) areas.  It will help significantly with the flow of the game.

When the project began, I was faced with a big decision. Do I use engine like Unity, or do I write my own engine?

Countless game devs will tell you to never write your own engine. It’s a fool’s journey, and I agree with them, except for two reasons:

1) I like building engines. I’ve been doing it my whole career (and before that) and it’s fun.

2) This will be the 4th adventure game engine I’ve built. There wasn’t a lot that was unknown to me, and it felt like a safe journey.

I also enjoy the power of being able to change the engine as I need; adding new features and optimizing (minimizing) repetitive game programmer tasks.

If David or I are writing the same code over and over, or a seemly simple task is taking three lines of code, rather than one, I just change it.

Where We’re Going

We’re into full production right now. The entire game has been wireframed and 90% of puzzles are functional. We’ve been able to play through the whole game and get a feel for the world and the puzzles. It’s good stuff. I am very happy with the design, story and characters. It feels like a true classic point & click adventure.

That’s both a good thing and a bad thing.

I’ve shown the game to a few people, and they immediately start trying to optimize the UI. “Do you really need verbs?” or “Can all the touchable objects in the room glow?” Or they worry about new players. “Some kind of pop-up help would be nice here.” or “How are you going to on-board the user?”

No, no, no. I keep saying. This is a classic point & click adventure game. It’s going to turn some people off. We know that, and we don’t care.

We’re not building a modern adventure game with all the rough edges sanded away and a safety net, ready to catch even the smallest misstep or endless rewarding of the player for the completion of mundane tasks. I know a lot of modern players want to constantly be told how great they are and how amazing they’re doing. This is not one of those games. Success is rewarded with the greatest reward of all: New art. Hints are given through well crafted dialog and feel like a natural part of the story. Players are introduced to the game by a slow escalation of puzzle difficulty and a well focused story.

I spend a lot of time doing budgets and schedules. One of the keys to a successful production is knowing everything you need to do. Lists. Lists. Lists. Get every task into a list and start marking them off. You become a machine. But not a machine without feeling. As you build something, you start to see where it’s not working, when that happens, don’t be afraid to change what you’re doing. Don’t slavishly follow the lists off a cliff. If something isn’t working, redesign it and then update the lists.

David and I are cranking away at game programming. It’s exciting to see final art, puzzles and dialog go in the game. At the end of each day, the game feels more done. David does most of the actual game programming with me doing the dialogs and tackling game programming where I know there will be engine changes or features added. It’s easy for me to do both at the same time.

We signed a deal with Microsoft to bring Thimbleweed park to the Xbox One. We’re very happy about that. We really wanted the game to be on console. It’s a whole different audience. Microsoft has a three month console exclusive and after that we’d like to port it to the other consoles, but our ability to do that will depend on getting the money to pay for it. Either by doing a deal (unlikely with the exclusive in place), or the game being successful enough that we can afford to pay for the ports ourselves, or by raising the additional investment. Porting to console isn’t something that can be crowdsourced, because none of the console makers have the ability for us give away keys to backers.

Next month we’ll start to delve into music. I wanted to get the world defined first, so we know what needs music. Music in adventure games tends to be about where you are, not what you’re doing. The area of the game gets scored, rather than events. There are obviously exception for big events or plot altering puzzles, but it’s mostly ambiance. I’m looking forward to working with Steve Kirk and defining the sound of Thimbleweed Park. (Note to self: Email Steve and let him know we’ll be starting next month).

Also thinking about testing. Thimbleweed park is going to be a big game to test, given three Kickstarter platforms, mobile, and now console. The plan is to bring on a lead tester who will create test plans and manage the other testers. We’ve budgeting for the lead, plus four paid testers. We’d like to get the lead started (part time) early October, get them acquainted with the game and start building test plans. I don’t think any meaningful testing will happen until Jan. There is also the danger of starting testing too soon and overwhelming the programmers and artist with bugs while they are still adding pass one content.

What Scares Me

As mentioned above, the animation is taking longer than we thought to lock into the right style to fit Mark’s backgrounds.  We have yet to put any final animation into the game and this scares me. Once we figure out the style, I’m sure it will turn into a well oiled pixel cranking machine, but we’re already one month behind and that could stretch into two. In animation, most of the Kickstart rewards are falling on Gary to do or coordinate. Those won’t ship for a while, but they are taking time right now.

The backgrounds are taking longer than expected. We were hoping Mark would have everything done first pass by January 1, and would then enter a polish/fix stage, but realistically I don’t think he’ll be done until March. The backgrounds are stunning, so in a odd way, I’m OK with them taking longer, but I do worry about budget and it affecting the ship date. So far, those two issues aren’t a problem, but we need to keep an eye on them so they don’t become one.

Saving games still scare me.This is something I should have figured out months ago. The issue isn’t a matter of how to store the data, it’s way more complex than that. There is a lot of data to iterate through and save off in a way that can be reconstructed. Doing save games is harder today than it was back in the SCUMM years. Back then we didn’t have to worry about patching. These days, the save game has to survive the game being patched and that can mean resources being added or removed.

Managing all the translations and the English voice recording is going to suck up a lot of my time when that rolls around. It also means that we need a script lock sooner than I like. The entire script needs to be locked on April 1. That scares me.

My biggest fear these days is how much time I spend NOT making the game. Writing these blog posts takes hours each week, plus it takes me around two hours to record, edit and post the podcast. These things aren’t free. I think they are worth it and I enjoy doing them, but it cuts into the hours I spend programming and designing.

Budgeting and scheduling also takes several hours each week. I’d love to have a full time producer that could handle this part of the project, but it’s all falling on me right now. It’s tempting to just skip budgeting and scheduling as they often don’t feel like “real” work, but the sense of accomplishment is short lived. You need to know where you are and how long it’s going to take to get there. If you don’t, you’re surprised to find yourself out of time and money. Game schools should require proficiency in scheduling and budgeting just as much as level design or 3D modeling.

I feel good about the design and the progress we’re making on the tech side. Of course, all that could change in three months.

Stay tuned for next quarter’s nail biting episode of “State Of The Game”.

– Ron

Thimbleweed Park Podcast #18 Fri, 21 Aug 2015 20:05:00 -0400

Yet another thrilling episode where we talk about billing all the expenses for my new puppy to the Kickstarter project.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Radio Station Mon, 17 Aug 2015 12:22:00 -0400

Here are a couple of new pieces of art from the Gamescom Microsoft trailer. These are 1-to-1 pixel images, just as they appear in the game. Neither of these are completely done, they both need to go though a polish stage.

I also wanted to thank Craig Derrick for putting together the deal with Microsoft and generally helping out at Gamescom. Craig worked at LucasArts and was responsible for the Monkey Island Special Editions. He was the executive producer and the driving force behind the re-releases getting made. Many thanks for that and for the help with Thimbleweed.

Also enjoy the glory of vertical scrolling rooms.

And as an added bonus…

The fine folks at Style64 (Elwix/Style) offered to extend their TrueType C64 font, adding the international characters we’d need for French, German, Italian and Spanish, plus the ™ and a few other symbols. Many thanks to them.

It’s kind of a short post today, using art and visual images to distract you from the dearth of actual content and information. It’s been two weeks since I got back from Germany and I don’t feel like I’m completely back in the swing of things.

– Ron

Thimbleweed Park Podcast #17 Fri, 14 Aug 2015 20:40:00 -0400

Bla bla bla making an adventure game bla bla bla*

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

*This is why I’m not in sales.

Inventory Icons Thu, 13 Aug 2015 11:28:00 -0400

So in case you hadn’t heard….”The current icons in the game are not final… ignore them!”

In putting together a functional pre-production wireframe I had to knock out a group of about 125 quickie icons™ that could be used to simulate real inventory icons necessary for game play.

Ron pretty much always says to both myself and Mark “This is temporary, don’t spend more than 5 or 10 minutes on it!”  Of course, as an artist I sometimes have a hard time with that (and don’t get started on Mark doing something in 5 or 10 minutes – but I’m sure he’ll weigh in on that when he writes an art post – sometime soon we promise).

In any case, I tried to bomb through the first pass of these keeping them as flat two dimensional versions although we’d decided to make the finals more three-dimensionally rendered the way the icons appear in Monkey Island.

Here’s a smattering of a few of the before and after versions wireframe on the left, newly revised on the right.

Creating the first pass 2 dimensional wireframe icons has been a very helpful exercise in their design process, as creating icons tends to be more about being able to select an item or visual reference that clearly communicates the idea of what the icon represents.

In the case of the inventory icons, since they do represent some manner of physical item that exists in the world it still requires quickly designing the look of that item- in most cases before it exists in the game world. When brainstorming designing story and puzzles is usually when we realize we need a particular item and then backtrack to where it physically exists in the game world. This can become a bit of a hodgepodge as we weave together story, locations, characters and puzzles. FYI, the following example is made up for the purpose of this post, it’s not really in the game (at least not yet) so is spoiler free.

“Maybe Ransome likes ham sandwiches, let’s have a dried up rotten one under his bed…. How about getting him one in the Diner, or maybe you need to get all the ingredients to make one….”

Additionally, it’s pretty likely that when we create ‘The ham sandwich puzzle’ that asset does not exist anywhere visually in the production game art at that point or if it does it’s generally at lower pixel resolution and a different angle then the icon needs to be.

Typically the first place we’re going to create a visual representation of that ham sandwich will be in its inventory icon form, then retrofit the design of that item back into it’s game world counterpart so the two somewhat match- after all, the player needs to be able to make the visual connection between them asap.

The first thing I’ll do to create that icon is research it online by searching ‘ham sandwich’ or ‘ham sandwich icon’, additionally, if I find a good iconic representation of the item online, it really only serves as a starting point to get the idea underway, you have to be careful about copying anything you find too literally as the ‘Ham Sandwich Icon Designers Union’ (local 517) could end up be fairly litigious about their intellectual property.

Once you have your own good representation of that ham sandwich simplified and sketched out at the proper orientation you’ll need to make sure it’s rendered in the same style and color space as your existing icons as they belong as a group together and needs to share the same harmony and continuity.

Finally, given the nature of needing to translate the game into multiple languages, icons need to be pretty universally recognizable (at least as much as possible) so we try to keep them as as representationally visual as we can.

This can be somewhat problematic when it comes to an icon that mainly exists with printed text as it’s primary identification, I.E. ‘Last Will and Testament or Lab Report”. In those cases you do your best to create an icon that’s different looking enough from other similar items and depend mainly on the player mousing over it to get a text description to do the trick.

Great icon design is an art form unto itself and requires a particular type of shorthand visual designer. In many cases the evolution of iconic communication is based in our collective societal consciousness when creating that items’ representation during a particular time in history.

Take the classic phone handset as an example, today, most people I know use a cell phone that looks like a flat rectangle, but every kid still recognizes the representation of a 1940’s style rotary phone handset when it appears on their screen, it’s become a pop culture representation to communicate an idea, the same will go for the graphical icon of an envelope representing email that will still be around long after the day we stop using paper post.

Additionally, a lot of game inventory icons are designed by the lowest common denominator, few projects (our’s included) tend to have the budget to hire a dedicated icon designer, it falls to the most logical available resource, in our case that would be myself, and I’m really a comic book artist and character animator, so bear with me, I’ll do the best I can.

– Gary

P.S. The icons are not final until the game ships…

Gamescom Debrief Tue, 11 Aug 2015 15:31:00 -0400

I’m back from Gamescom and just about caught up on my sleeps.

It was fun being part of the Microsoft show. I’ve never been involved in one of those big presentations before and it was fun to see from behind the scenes.

I was part of the indie section and for the most part they didn’t let us watch the rehearsals for the rest of the show (they know what a blabbermouth I am). I showed up at 10am and we did two rehearsals and it was deemed by higher powers that we didn’t need another one in the afternoon. The whole thing was a little nerve-racking. I don’t like giving talks or presentations and I thought this one would be easier since I only had three sentences to say, but I was wrong.

When I give a normal 40 minute talk, if I screw up a line, it’s one of 1000 sentences, but with this, if I screwed up a line, it was like I’d screwed up ⅓ of my entire presentation. It’s odd how much little thoughts like that can worm their way into your head. I became obsessed with not screwing up ⅓ of my talk, and that, of course, made it a lot worse.

They also had teleprompters, which I’ve never used before and you’d think that would make things easier, but it actually worked against me. I had my little speech memorized, but my eyes kept darting to the teleprompters and my brain would panic that I wasn’t saying what was being displayed.

The first rehearsal went flawlessly. I really screwed up the second one and was hoping we’d get to do another run-through, but it was deemed unnecessary. The second day I got the next two rehearsals right, but I still felt like I was fighting what my brain had memorize and what was being displayed. This was complicated by one of the lines I wrote being changed slightly. I had the world “Lucasfilm” in the second sentence and they removed that for legal reasons, so I was fighting what I had memorized with what was being displayed.

Everything worked out in the end and I had a great time. Everyone at Microsoft was great and fun to work with.

It’s worth noting that none of the Kickstarter money is being used for the Xbox port. The money we got from Microsoft covers the port and there is a little extra to make the main game better.

Also worth noting that there isn’t a good way for backers to get the Xbox version instead of (or in addition to) the Windows/Mac/Linux Kickstarter platforms. I asked about this to the point of being annoying and Microsoft has no way to mass distribute keys and deal with the accounting of it all. It’s something they’d like to do, but they are a huge company and getting (seemly easy) things like this implemented is not easy. It might change in the next year, but it’s unlikely. We will keep looking at options, but don’t get your hopes up. We just want to be upfront about this.

Gamescom was huge. I’m used to E3, but this dwarfed it.

The main show was overwhelming, so I hung out in the retro area and played a brand new point & click adventure on the C64 and did a live on-stage interview.

I spent an hour talking to some students and tried to scare them out of getting into games (no luck).

I had a great time at the Adventure-Treff™ party signing Maniac Mansion and Monkey Island boxes, handing out pins and refrigerator magnets, and chatting with everyone. Good times and really good people. I didn’t take any pictures except the one of a three head monkey t-shirt. I’m really crappy at taking pictures when I’m traveling so I just stole some from twitter.

It’s good to be home and working on the game again.

– Ron

P.S. Cologne has a really big church. Not sure if anyone else noticed.

Thimbleweed Park Is Coming to Xbox Tue, 04 Aug 2015 17:05:13 -0400

Cat’s out of the bag (USE KNIFE WITH BAG, PICK UP CAT). The reason I was at Gamescom to was help Microsoft announce that the award winning (Awards TBD) Thimbleweed Park (game TBD) will be coming to Xbox and Windows 10 the same day it release for Windows, Mac and Linux on Steam, GOG and other places (other places TBD).

Please enjoy this new video…

– Ron


Thimbleweed Park Podcast #16 Fri, 31 Jul 2015 09:37:00 -0400

Mark Ferrari joins us and talks about his personal quest for the happy pixel.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Occult Books Mon, 27 Jul 2015 11:01:00 -0400

Here is the wireframe for the Occult Bookstore. I know what you’re saying: “Whoa, that’s a lot of books, how are you going to come up with names for all those books when the player scans their cursor across the screen?”

Funny you should ask that.

I’m a big fan of the Tom Sawyer school of game design. Why paint that fence if you can get all your friends to paint it for you, or in this case, name all those books.

There are close to 300 books in the book store. They are too small to be individually touchable, so 2 or 3 books will probably make up the hotspot, which should be fine. There is a puzzle involving finding a book, but the player won’t be tasked with the monotony of scanning all the books to find the one they need. There will be an object that locates the book, and that is the real puzzle. All the books having funny names is to make the store fun to explore.

And this is where you come in… We need names for all those books. The rules are:

1) The name has to be less than 35 characters.
2) It should be a book you’d find in an occult bookstore.
3) Ignore #2 if it’s really funny that the book is found in an occult bookstore.
4) The title can include a “by …” if the total length is less than 35 characters.
5) Include a “by …” only if it is part of the humor.
6) Pay attention to #2, we’re not just looking for funny book titles, but ones that would be found in an occult bookstore.
7) #6 is really important.

Post your submissions in the comments.

– Ron


I’m closing the comments. There are well over 1000 comments and probably 2000+ useable book titles. What great fun! Thanks to everyone for contributing! There are some really funny titles that I LOL’d at. And if you know me, I don’t use LOL very lightly. When I LOL, I really mean it. LOL.

The next step will be to copy all the book titles from the comments and drop them into a spreadsheet, remove the bad ones (sorry if I hurt your feelings) and wire them in. Given the number of books, Mark is going to have to adjust the room, probably by making it comically tall. The only skyscraper in Thimbleweed Park is the Occult Bookstore.

Love it.

Please don’t leave book titles in the comments of other posts, I’ll delete them. Don’t screw with me!


Best. Backers. Ever.

Thimbleweed Park Podcast #15 Sat, 25 Jul 2015 11:46:00 -0400

Our most boring podcast yet… or is it? Yes… yes it is.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Gamescom 2015 Fri, 24 Jul 2015 01:01:00 -0400

It’s after 10 pm and I haven’t written the 2nd blog entry for this week. In my defense, I spent most of the day writing the dialog that happens when you visit the Diner. It’s the first dialog I’ve written that introduces one of the other playable character flashbacks, so I spent some time trying to figure out the best way to unveil some information.

It’s also a dialog I don’t want you to exit out of early and that can be tricky without the player feeling trapped.

For most (and I mean most) dialogs, you should always be able to choose the last option and end the dialog. We call it the “goodbye” line.

 Don’t leave town, I’m watching you. -> done [ray] [heard_about_ransome]
 Thanks for your help, we’ll be back if we have anymore questions. -> done [reyes] [heard_about_ransome]

It should always be there and make the player feel safe: there is no penalty to getting into a dialog, you can always exit.

The one general exception to this rule is if the dialog dumps you into a small node that is just for comedic purposes. four joke answers. That’s OK because it should send you back into the main node with the goodbye line.

For this dialog, I couldn’t let that happen, not without making the dialog obscenely complex and probably overly confusing in the process. The trick is to make the dialog so interesting that players don’t want to exit, but that borders on being pretentious.

Anyway. Bla bla bla. Enough about my problems.

The good news is that I’m going to Gamescom! I’ve never been before and I’m really exited. We’re not showing Thimbleweed Park (at least not while I’m sober… hint hint), but it should be a lot of fun!

I’m going to be at the Adventure-Treff party, so if you want to hang out and talk Monkey Island, Maniac Mansion, Thimbleweed Park or adventure games in general, come on by.

– Ron

Cutting Mon, 20 Jul 2015 20:05:00 -0400

We cut 25 rooms from the game last week. No one panic, it’s not a bad thing, it’s actually a good thing.

Put. Down. The pitchfork.

Editing is one of the most crucial stage of any creative endeavor. I know it seems like you’re losing something when stuff is cut, but the old saying “less is more” is actually very true.

You cut stuff to focus the story and the puzzles. Pointless rooms don’t make the game bigger and better, they become useless traversal and dilute attention from what really matters.

The great purge of 2015 started with a mental exercise.

I asked Gary and David to make a list of 15 rooms they would cut. After each of us had compiled our lists in isolation, we sat down and talked through our choices.

The breakdown of the cut rooms is as follows:

We cut 5 rooms because we decided to have the circus flashback happen at night instead of during the day. This allows us to use the same rooms for the main game and the flashback (with some object overlay changes). CUT!

We cut two rooms from the circus because we never came up with a singe puzzle or purpose for those rooms. CRUFT! CUT!

We cut two rooms that were just the sides of the pillow factory. They seemed like a good idea four months ago, but felt like baggage after playing. CUT! CUT! CUT!

We cut three rooms from the Delores family manor. Again, we never really found a use for these rooms. One of them might come back as we still have a couple of dangling puzzle chains in the mansion and might find a good use for them. CUT! MAYBE! BUT CUT!

We cut two rooms from the hotel because they were just variations of the generic hotel room that are better done with object variations. CUT! CUT! CUT!

We cut another room because the puzzle was better done as long shot and not going into a new room. CUT!

We cut one room because we came up with a funny gag instead of having the room. CUT!

We cut three rooms in town because we never found a good use for them. The town of Thimbleweed is supposed to be a little old and decaying, so they got turned into abandon buildings. It works better that way. CUT DAMN YOU! CUT!

You might detect a small amount of glee is my ALL CAP outbursts, and that wouldn’t be misplaced. I enjoy cutting. It means the game is getting leaner.  A lot of rooms in Monkey Island were cut and no one noticed. I don’t think I miss a single one of them and none of them would have made the game better, possible just to opposite.

That’s not to say we cut solely for creative reasons. The rooms count was getting up there. We had over 100 rooms, far more then either of the Monkey Island games, which were much bigger than Maniac Mansion. Coming out of pre-production, we started to do a final schedule and budget and realized we couldn’t get everything done in time or for the money we had. Something had to give.

But we knew that going in. I like to over design and then cut and that’s what we did. Nothing we cut sacrificed the game.

It’s also why we do a completely playable game during pre-production. In some way, these cuts are free. No one invested time, energy or ego into any of these rooms. CUT!

Whenever I’ve done post about cutting stuff, people inevitably ask if we can leave it the game as a “director’s cut”.

That’s not easy to do. There is so much “connective tissue” that holds the rooms together and we’re cutting early in production, so it never gets fully wired up or programmed. There are a couple of places that we’ll leave some cut content in as easter eggs, but for the most part, the game moves forward too fast to make it worth keeping cut content in a useable form.

Or maybe during the end credits, paying tribute to the fallen heroes that made the game possible.

“We’ll miss you bank vault.”

– Ron

Thimbleweed Park Podcast #14 Fri, 17 Jul 2015 19:57:00 -0400

We talk about earthquakes and actors in brackets, whatever the hell that means.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

QuickiePal Thu, 16 Jul 2015 18:21:00 -0400

W00t! Time for a video. It’s been a while and I enjoy making them just about as much as your enjoy watching them.

We got one of the first final rooms from Mark Ferrari™ in the game a few days ago and we’re dying to show people. We’ve also been doing some work on lighting using shaders and magic. It’s first pass, so there will be a lot of tweaks and changes, but it’s looking really promising.

All the inventory icons are still temp art, so ignore them. I SAID IGNORE THEM!

We started out with a quick wireframe version of the QuickiePal, just so we could get a sense of how the room fit into the overall game, how wide it should be and other very basic layout issues. It’s not worth spending too much time on the wireframes since we want to have the freedom to cut or completely redo the room without any loss of work. As soon as you’ve invested time in something, it’s hard to throw it out, even if it’s the right thing to do.

One of the changes we made as the move the building over the right so when you entered from the left, you weren’t immediately at the building. It feels less cramped with a small parking lot.

After it had been in the game for a couple of months, Mark took a quick pass at a tight layout in black and white. He likes to work in black and white so he doesn’t spend valuable time on trying to figure out colors. Hopefully we can get Mark to do a post on his process. It’s all bla-bla-pixel-bla-bla-vanishing point-bla-bla to me.

After the black and white had been in the game for around a month, Mark went on to the final stage seen in the video. We take these small steps so we’re sure of everything before too much time in invested. Mark spends a lot of time on color and light, so making changes to the black and white version is quicker.

There will be a polish pass on all of the final rooms, but that won’t happen until everything is in the game, probably around January.

– Ron

Why are you still looking at the temp inventory icons?

The Drinking Fountain Whisperer Mon, 13 Jul 2015 12:13:00 -0400

Here is your chance to have actual dialog you wrote appear in Thimbleweed Park. ” Wow!” you’re saying, “Does this mean I get to write the climatic scene with the killer?” Not exactly. “OK, then the pivotal interrogation scene where Detective Ray finally breaks him down?”  No, not that either. “Oh, so I get to write a scene with the Quickie Pal clerk where he spills an important clue about the case?” Nope “Well what do I get to write!” you respond with equal parts confusion and frustration.

You get to help write the Drinking Fountain dialog.

In the City Hall (as seen in Mark’s wireframe), there is a drinking fountain and we need something to happen when you take a drink. The boring choice is:

drinkingFountain = {
    verbUse = function() {
        sayline(“Ahhhh… that hits the spot.”)

But that would be boring and since I was in the middle of implementing the new dialog system, I though this would be a great opportunity to do a fun dialog with the drinking fountain. Not actually a dialog WITH the drinking fountain, but some fun dialog choices while you were drinking.

I spent 5 mins and hammered this out:

 gulp gulp gulp gulp -> main [random]
 gulp sip sip sip gulp -> main [random]
 slurrrrrrp slurp slurp  -> main [random]
 sip sip sip sip  -> main [random]
 lap lap siiiip siiiiip gluuuup -> main [random]
 sip sip sip sip gulp gulp -> main [random]
 slurp gulp gulp slurp -> main [random]
 gulp ooowk gulp ooowk gulp ooowk -> main [random]
 smulp slurp smulp gulp slurp -> main [random]
 glub swish swish swish pewee -> main [random]
 gulp sip sip slurp glub -> main [random]
 slurrrrrrrrrrrrrrrp slurrrrrrrrrrrrrrp -> main [random]
 Ahhhhhhhh -> exit

It’s a fun little dialog to play with, but it could use a lot more funny slurping noise lines, so this is where you come in.

If you have any suggestions for lines, put them in the comments and the best ones will go in the game. The dialog could be even better if the choices branched off to other nodes and there was some escalation or even mini-story told through slurping. Feel free to go nuts. If it’s funny, I’ll add it to the game. The only thing I ask is there aren’t actual spoken lines, it’s all slurping (or other bodily function) noises.

The format for the dialogs is pretty simple. There can be only one 1 and one 2, etc choice, so the first one chosen is used and the others discarded. the [random] condition makes the odds of it bing chosen random. the -> label just tells the system where you go if the choice was selected by the player. You can refer back to this post for more examples.

I love playing with stuff like this. It’s completely meaningless to the game, but they are quick and fun to implement and play. I’ve always felt odd detours is what gives a game it’s real charm. It’s also why I like making adventure games in an almost improv fashion. When I see ideas like this in a game, I know the team had a great time making the game.

It’s also why I like creating using file formats like these .yack files. The drinking fountain puzzle might be really funny, but it also needs to be fast to implement. If you’re writing a bunch of code and involving three other departments to make it happen, not a lot of ideas like this will go in the game. The time from idea to implementation should be measured in minutes.

Drinking fountain dialog puzzles also don’t make it into design documents and if it did, they’d likely be questioned and challenged by the publisher/producer: “Do we really need the drinking found dialog?” It’s a hard one to defend, but yes, we do need it. When you’re adding quick little gags like this, you never know which ones will work or not, so you add as much as you can.

Done well, it’s the kind of stuff you remember twenty years later.

– Ron

Thimbleweed Park Podcast #13 Fri, 10 Jul 2015 19:50:00 -0400

Our cursed 13th episode of the Thimbleweed Park Podcast. Odds are one of us will be dead by the end of it, but on the bright side, we talk about some spoiler free issues with one of our puzzles and my new puppy. But one of us will probably die.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Exploring Delores IIIII Wed, 08 Jul 2015 19:57:00 -0400

Although I hate following ‘the cutest dog in the world picture’, it’s time for the next art related post.

Ok, so based on the last round of feedback to the previous Delores design post, we thought we’d go through one last round of pixel art before Ron and I make our decision (yes, the decision of the judges will be final).

It’s been very interesting to see everyone’s reaction to what’s approaching her final character art for the game. Now that somewhat recognizable pixel versions are in play there’s been a lot of requests to try ‘this head’ with ‘that body’, etc. as sort of a ‘colorforms’ style exercise. Just a quick aside, #2 (the middle one) seemed to get the most positive overall response.

Certainly, one of the aspects of working digitally I really like is an almost endless ability to tweak and noodle pixel art the approach allows. Tear this head off, replace it with that one, change the skin color, put those shoes on that one over there. It’s very fluid in nature which allows for an amazingly dynamic process.

However, one of the dangers of this is that you really can almost noodle something forever. I’ve worked on a lot of projects, with a lot of other folks, Project Leaders, Art Directors, Writers, etc. One of the things I really strive for is to present a coherent range of choices. If you’re responsible for getting a job done, you really need to be able to focus in and decide. In the case of Thimbleweed Park, I’m doubly fortunate to be part of the design team, so my opinion carries a fair amount of weight and I happen to be working with extremely talented people whose opinions I respect and have a no-nonsense way of getting things done. As Ron tends to say from time to time “I don’t know art, but I know what I like”. (Actually he really does know art- but don’t tell him I said that :-)).

This philosophy has served us in good stead during our time at Lucasfilm from Maniac Mansion to Monkey Island, and you have to know when it’s time to fish or cut bait and in the case of Delores it’s definitely time to fish and we certainly appreciate all the feedback we’ve gotten throughout the process.

So here’s to the last round of noodling Delores. From here we’ll decide her actual design, then complete this series with a final blog post showcasing that in various poses and orientations.

Additionally, due to popular demand we will be planning on Delores having some ‘themed’ costume changes for ThimbleCon, after all she is kind of a geek….

– Gary

Pep Mon, 06 Jul 2015 13:00:00 -0400

Monday’s blog entry has been usurped by a cute picture of my new puppy.

“Please play with me instead of writing a blog entry”

– Ron

Thimbleweed Park Podcast #12 Fri, 03 Jul 2015 23:45:00 -0400

A very special 4th of July episode.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Exploring Delores IIII Thu, 02 Jul 2015 20:22:00 -0400

Ok, so we’re getting into the home stretch of designing the Delores Edmund character development process. If you haven’t read the previous installments on the blog you might want to check them out before proceeding. We started with a text description for the character, then went through the process of gathering reference material, our thanks to everyone who participated, then went on to the character sketching stage.

Now we’ve proceeded to take three of the most likely sketches to the current in-game character style pixel render stage. These three were chosen through a combination of backer feedback, friend and team preference and because Ron and I said so.

When I was originally designing the characters for Maniac Mansion I went through this same basic process, sketching the characters as felt pen renders and then trying to take those over  to pixelcentric game characters. In those days, a lot of technical issues drove how I’d render them on the C64. They could only be a limited width and palette. The main thing that drove their big-headed-ness was Ron and I really wanted unique/recognizable characters, trying to make a unique looking face 5 or 6 pixels wide using 3 colors (one of which needed to be black) really drove their now iconic appearance. Today, basing Thimbleweed Park’s characters on this approach is definitely a choice. We still want to evoke that iconic feel, however updated with additional palette and a broader range of animations.

Conversely, adapting Thimbleweed Park characters into big headed pixel versions at this stage is now fairly straight forward for me, as I’m pretty familiar with how most of the characters need to look in that style, it’s mainly an exercise in taking one stereotypical set of parameters and shoehorning them into the next. What I mean by that is having simplified a set of characters into felt pen sketches- it’s relatively straight forward to adapt those characteristics into a similar set of pixel constraints. Additionally, there’s a simplicity and iconic nature to this step. The characters need to be mainly composed of basic color components with some rendering and be easy to tell apart and identify.

One of the things about these pixel rendered characters that’s deceptive at this stage, is we’re still looking at them in a very stiff cardboard cutout style stance. This is so we can see what they look like from purely an almost graphic design perspective, are the colors and shapes of a character aesthetically pleasing, does it mesh with the others? Once a character is actually in the game and animating, you’re never really going to (hopefully) see them in this boring of a stance, there will be a ponderation and attitude to they way they stand and balance their non-existent weight (even for this style of character) which should make them seem much more interesting and alive.

The next and pretty much final step will be to take our selected pixel version and do a little bit of additional fine tuning of colors, skin tone, shading, and a few other details. Once we’ve decided on a final we’ll create a number of reference angles (front, side, back, three-quarters) and a variety of poses. This will be the guide we’ll use to create her final animations in the game bringing her to life as yet another memorable Thimbleweed character.

– Gary

Dialog Puzzles Tue, 30 Jun 2015 10:44:00 -0400

I don’t know why we started calling them “dialog puzzles”, they aren’t really puzzles, they are more “dialog trees”, but “dialog trees” just doesn’t have the same flair that “dialog puzzles” does, or maybe it’s just me, but I’m going to call them “dialog puzzles”.

Maniac Mansion didn’t have dialog puzzles. I often getting quizzical looks when I say that, followed by “Yes it did!” and I follow with “No it didn’t.” and they retort with “Are you sure?” and I come back with “Yeah, I think I would have remembered that.”

Zak didn’t have dialog puzzles either, nor did LOOM™. Dialog puzzles at Lucasfilm first appeared in Last Crusade and I like to think of them as version 1.0.

For readers that aren’t sure that I’m talking about, you might want to check your browser’s url. If you came here looking for information on the invasive plant called Thimbleweed, you’ve probably come to the wrong place, but bear with me, this might be interesting…

Dialog puzzles are really nothing more than a list of choices in the form of dialog for the player to say, or more specifically, for the player to make the main character say. You begin a conversation by doing a TALK TO. The main character usually starts off with a line of dialog, then the other character says something, then the player presented with three to five choice of things they can say.

You choose one of them and that takes the conversation in a new and you end up with some more dialog choices. The dialog trees are typically only a few levels deep and often return to a top node. Choices you’ve already made often disappear (but not always).

Dialog puzzles in the Lucasfilm adventures were invented to break up long cut-scenes. If you have two minutes of information to get across and you break it up with the occasional choices from the player, it can turn a long slog through dialog into a joy.

The dialogs in Indy were 1.0 because we were really just feeling our way around, trying to understand the rules. Noah Falstein wrote most of the dialog in that game and I thought he did a great job of starting to figure all this out.

But it was Monkey Island where the dialog puzzle really started to shine. A lot of that credit goes to Dave and Tim for being such good and funny writers, but also because we were starting to figure out the rules of what made a good dialog based on the experience with Indy.

I always felt that a dialog should make retrospective sense. Meaning, when you got done with the tree, you should be able to print out the dialog, read it and it should feel like a real conversation, which gets me to one of the most controversial issues with dialog puzzles: You are having a conversation.

The choices in the dialog tree should be lines of conversion, you select them and the main character says them and this moves the conversation forward. It is through the act of having that conversation that you make the choices, the choices do not elicit conversation.

“It would be swell if you could loan me some gas for my chainsaw, fine sir?”


Ask about getting gas.

In the first example, you’re having a conversation with the goal of getting the gas for your chainsaw. In the second, you’re telling the game you want the gas and it builds a conversation around that. I inherently dislike the second. It’s boring and it takes away the single greatest thing about dialog puzzles: being able to tell four jokes at once.

Someone can say something to Guybrush and then the player sees four funny responses and they read down them and (hopefully) laugh at each one. They don’t need to select it, they just need to read it. You can do a lot more character building that way and tell a lot more jokes.

I could go on and on about dialog puzzles. I have a whole list of rules for structuring them that I’ll try and dig up at some point and post, but I know what you’re thinking: “What the hell does this have to do with Thimbleweed and how do I get it out of my backyard?”

Patience, Grasshopper

I still haven’t decided if we’re doing dialog puzzles in Thimbleweed Park. It’s not that I don’t want to – I really want to – but they are massively time consuming to write and implement. Having them increases the dialog in the game by a factor of ten. You’re no longer writing one conversation, you’re writing ten of them and that doesn’t even include that we have five playable characters.

If we do them, the dialog could end up being somewhat generic, with only special lines here and there for the different characters. It doesn’t take much to make them feel special, but it’s completely unrealistic to expect that all five characters will have completely different conversations without the dialog trees becoming very thin, which might be OK. It’s an odd creative problem.

What I do know is that I don’t have the time to write the dialog AND do the system programming. One of those will have to give and that starts to run into budget issues. We don’t have the budget to hire an additional writer or a system programmer. Making games is all about trade-offs.

In SCUMM all the dialog puzzles were hand coded and it was a pain. For DeathSpank I came up with a script format called Sassy that helped a great deal, but was just a little too wordy and programmery.

Last year, I went to a great talk at GDC by Jon Ingold about 80 Days and was impressed and inspired by the simplicity of their scripting format.

Last week I played around with our dialog system and spent some time figuring out a format for the scripts and implemented it in the engine.

Here is a sample I crapped out as a test:

!talked_to_sheriff = YES
sheriff:  Howdee. The name’s Sheriff Crook, local sheriff of Thimbleweed Park.
    I don’t remember calling the feds-a-renos.
    That’s what you are? Feds?
    Hard to miss the goverment issue suits.

 Damn straight we’re the feds. -> crap [showonce]
 Cut the Mayberry crap, we’re taking over this case. -> crap
 How long were you going to let that body rot in the river? -> rot
 I’m agent Ray and this is… uh… my partner. -> hi
 Know any place that serves good pie? -> eat [once]
 Know any place that serves good meatloaf? -> eat [once]
 Know any place that serves good hamburgers? -> eat [once]
 Know any place that serves good hotdogs. -> eat [once]
 Why don’t you shut the place down? -> shutdown [once]

sheriff:  You could try the Diner down the street, but no one eats there…
pause 0.5
sheriff:  *whispering* Botalisium. [asked_about_food == 1]
sheriff:  *whispering* E. coli. [asked_about_food == 2]
sheriff:  *whispering* Plague. [asked_about_food == 3]
sheriff:  *whispering* Butylated Hydroxytoluene. [asked_about_food == 4]
-> main

sheriff:  Why would I do that? I get a 5% law enforcement discount.
-> main

sheriff:  The river is so chocked full of chemicals from the old pillow factory…
    …it’s better off there than in a tub of formaldehyde.
sheriff:  {chuckle}
-> next

sheriff:  Whoa… hold your horse-a-renos, no need to get snippy.
-> next

sheriff:  Nice to meet you, agent-a-renos.
-> next

sheriff:  Looks like you heard about our little murder-reno out by the bridge.
reyes:  There nothing ‘little’ about murder, sir.
pause 0.5
ray:  *sigh*
    Ignore him… he’s new.
pause 0.5
sheriff:  No sense in wasting everyone’s time-a-reno.
    This cut-scene is starting to get long and it’s only going to get longer.
    Let’s find the coroner and get you on your way.
    Wrestling starts at eight.
reyes:  I hope he’s talking about on TV

I like writing in pure text, I don’t like fancy tools or clicking a bunch of UI to add nodes. I like to copy/paste and reflow large chunks of dialog with ease.

So, there are two things I don’t know.

1) I don’t know if there are going to be dialog puzzles in Thimbleweed Park.
2) I have no idea how to get Thimbleweed out of your backyard.

– Ron

Monday Post Delayed Mon, 29 Jun 2015 13:45:00 -0400

The normal Monday morning Thimbleweed Park blog post has been delayed until Tuesday because I’M BUSY WORKING ON THE F’ING GAME!

– Ron

Thimbleweed Park Podcast #11 Fri, 26 Jun 2015 18:10:00 -0400

Over 2 mins of bonus material because I forgot to stop recording!

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Office Areas Thu, 25 Jun 2015 17:41:00 -0400

Gary, David (and now Mark) and I don’t have offices in the sense that we get up and drive or take the subway to work each morning. It’s the year 2015 for crying out loud! It’s all about the virtual office now! Skype and Slack! To hell with human contact. That’s so 2014.

A couple of people in the comments have asked to see our work areas so we’d thought we post them. It’s easier than writing an actual blog post.


Gary is the only one of us that doesn’t work at home, but we still make sure he’s deprived of human contact.


David’s office looks suspiciously clean.


Mark wins for having the coolest office.


My excuse is I just got done moving and all my cool stuff is still packed. Yeah. That’s what I’m going with.

Yeah, I know. Not that exciting. Not sure what you were expecting.

– Ron

Special Case Animations Mon, 22 Jun 2015 19:43:00 -0400

It’s Monday so it’s time for another Monday Thimbleweed Park blog post. For me, the past two weeks have mostly been taken up by my big move back to Seattle from the Bay Area. I first moved here in 1992 to start Humongous Entertainment, then moved back to the Bay Area in 2004 and now I’m returning to Seattle. I really love Seattle and missed it quite a bit.  It’s great to be back, but I don’t feel like I’ve gotten a lot done on Thimbleweed park in the last few weeks.

I did do another pass on the budget. Gary and I did a pretty detailed budget pre-Kickstarter, but now that things have gotten rolling, we have a much better idea of the actual costs and the work involved. When you’re doing a preliminary budget, it’s all about guessing based on past experience. It’s 99% hand-waving and 1% actual data.

As you leave preproduction, you have a much better idea of what you’re building and how much time it’s going to take and the resources involved. Some expenses were moved from one line to another, some grew and other shrunk, but the end result is we’re actually spending a little less than we planned, which gives us a tiny bit of flexibility to bring on an additional artist to help with some of the animation.

In Maniac Mansion, the character animation consisted of what we called walk-talks. Four frame walks in three directions (left and right were flipped) and then talking. There isn’t any other animation in Maniac Mansion. When someone uses the weight machine, the machine move up and down (two states) and the character just stands there.

When we started working on Indiana Jones and the Last Crusade, we decided to add “special case animations”. These were animations that would be used in one place.

Having or not having them wasn’t a work issue as much as it was a disk-space issue. Adding a single disk to the game would increase the “cost of goods”. Add too many “cost of goods” and the “return on investment” (ROI for those without a MBA) would plummet.

At the beginning of a project were were given a budget of floppy disks. Monkey Island would get 5 floppies. As the cost of floppy disks would fluctuate like they were pork bellies being traded at the stock exchange, we would sometimes get “an extra floppy” added to our “cost of goods” budget and it was like Christmas. Sometimes we’d get an extra floppy added because we just whined and complained or maybe the game was looking really good and promising. Throughout production you’d have to keep a close eye on your floppy-count™.

Steve Purcell did the first “special case animation” where Indy jumps down into a pit. It was impressive to see a character do something that wasn’t walking or talking. Seems quaint and silly these days, but it was pure magic back then.

The other thing added around that time were reach animations. Indy and Guybrush had animations to “reach high”, “reach med” and “reach low”. They were played whenever the character interacted with an object in the world. Each object was tag with HIGH, MED or LOW and the system would play the appropriate animation.


The advent of the CD-ROM and later DVDs and now internet downloads have crushed most of the joy out of the floppy-count™, but there is still budget to contend with. Given the fidelity of our graphics, Thimbleweed Park has an unlimited floppy-count™, but someone still has to draw, animate and program it all, so we still need to be careful.

For Thimbleweed Park, we budgeted for a good amount of generic reach and special case animations, but doing larger cut-scene animations stayed on our wish-list. We don’t have a lot of cut-scenes in the game, mostly because I think cut-scenes kind of suck. They are great for big infrequent emotional rewards or quick little scenes, but, let’s face it, you’re playing a game because you like “playing” and that involves interacting. I like to follow the “10 second rule”. Don’t go more than 10 seconds without some kind of meaningful interaction (pro-tip: pressing OK is not a meaningful interaction).

Besides budget, the other issue in doing special case animations is a tech one. How do we do them? If they are just special animations the character is doing (like using the weight machine), then it’s easy, we do them in the same tool we’re doing walk-talks in.

But if they are larger and more complex and require coordinating several elements, it’s not as easy as just playing a canned animation. The animations might take place across several screens involving many separate images. I know some game devs use After Effects and then have exporters that export data used for playback, but that seems overly complex to me.

I’ve been playing around with Spine and quite like it. The problem with Spine is neither Gary nor I have used it before. I’m sure if we sat down and spent a week we could become proficient at it, but we’re both swamped with work.

Which brings me to the real point of this blog post (is anyone still reading?).

We’re looking for someone that is very proficient in Spine who could spend a few hours doing some (paid) tests for us. If Spine does what we need, it might translate into some more work compositing and choreographing our cut-scenes and larger animations.

If you already know Spine (I mean really know it and have produced a lot of work using it), please contact us.

I’m also open to other tools readers may have used. Probably the most important issue is being able to tween animation movement over time and easy to parse file format.

Anyway. Long post. Thanks for reading.

– Ron

Thimbleweed Park Podcast #10 Fri, 19 Jun 2015 18:23:00 -0400

Join this week’s hilarious podcast where I talk about losing $30,000 of the Kickstarter money.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

P.S. I apologize for the volume of my voice being so low, damn it Jim, I’m a game designer not an audio engineer.

Exploring Delores III Thu, 18 Jun 2015 17:47:00 -0400

Recapping the visual design process for the Delores character, we started off by defining the character as a text description. Once we had a reasonable criteria for who she needed to be, we proceeded to gather a broad range of visual reference to provide a good framework for a character’s basic look, appropriate wardrobe, hairstyle, props etc. The next step, at least for me is to proceed with color sketches.

This is when you need to take all the information you’ve gathered and boil it down to a reasonable number of visual choices. Personally, I like to present somewhere in the neighborhood of 6-10 character concept sketches to a development team. Many more than that tends become confusing, these should be all in the same general scale, orientation and render style so people can look at them and easily mix and match their most prominent features: “I like the hair from that one and the jacket from this”.

Additionally, in the case of this style of character development (I.E. for simpler game graphics or Saturday morning cartoons), for the sake of economy they lend themselves to components primarily rendered of solid colors. This allows for easier adaptation from design to an actual animated sprite. Some asymmetry Is acceptable, but we try to keep that minimal, as every detail you add, increases time needed to render the final character when you’re potentially animating hundreds or even thousands of frames. That’s why Saturday morning cartoons simplify things like comic book characters, unless you happen to be Disney, there’s usually not enough time or budget.

I’ll start this stage by printing out all the reference materials and arranging the pages out around the edges of my drawing table and pinned up on the walls, etc. so I can easily see everything at a glance. Then start roughing out individual standing figures in blue pencil. I began using non-photo blue pencils a long time ago (I personally like Staedtler brand)  as a holdover from working in comics, but mainly because they don’t reproduce on a copy machine, so if I make any photocopies the only thing that copies is my black ink lines.

Once I’ve sketched out my rough drawing typically on regular 8.5 x 11″ white copy bond, I’ll ink line it with a black flair pen. I usually don’t get that exactly to my liking the first time, but once I have a somewhat usable first version I’ll put it on my light table and retrace until I’m happy with the drawing. I’ll then scan and open it photoshop to color.

In the good old days at Lucasfilm, I’d just make a stack of copies of the lineart and color different variations with ad markers (those were expensive sets of alcohol based colored felt markers. We used to go through those markers by the dozens at a price of about $3/per pen, but Star Wars could pay for a hell of a lot of pens).

Once I have the colored rendered versions of a character properly arranged on a page, we’ll sit down with the team to review and hopefully choose one or two candidates to take to the last step in this process: namely rendering final versions of the character appropriately as pixel art for the game.

In this case our team’s pretty small and has worked together enough so it doesn’t need to be sent off to marketing department or upper management, Ron and I will figure that out on our own. So remember who you have to blame for any of our design decisions….

A Bus And An Elevator Walk Into A Bar… Mon, 15 Jun 2015 11:26:11 -0400

Every graphic adventure I’ve worked on has at least one puzzle or interaction that seemed really simple when we designed it, but ended up becoming enormously complex and the source of countless bugs. This inevitably resulted in countless fixes, patches, and smiling sadistic playtesters eager to report yet another issue.

We call these Whack-a-Mole bugs. Fix one and another pops up right next to it. They usually happen when you don’t think through all the possible side effects of your design choice, and from needlessly complicating what could be a simple interaction.

In Zak McKracken and the Alien Mindbenders, the “WaM” puzzle involved getting on the bus in San Francisco. Sounds simple, right? You just give the bus driver your CashCard™ and he lets you on. But I wanted to make this interaction flexible… more like real life. What if there were two characters (Zak and Annie) waiting for the bus? What if one didn’t have enough money on their CashCard™? Could one pay for the other? What if one was at the bus stop but didn’t board the bus before it left? What if the bus driver went back to sleep after you already boarded the bus and paid? What if the bus just left with Zak and Annie walks up—should another bus be there, or should we wait a suitable period? Because of countless weird permutations, the image of our lead playtester evilly smiling at my office door is burned into my memory.

After I’d spent days, nah, weeks, fixing these WaM bugs, I wondered about the overall coding and debugging time investment vs. gameplay payoff ratio. Was I really making the game more fun or would my time have been better spent on a game interaction with a higher Funitivity Quotient™?  For example, if the boarding-the-bus bit had been a cut-scene, it wouldn’t have made much difference to the overall playability of the game. (So what if the driver was rude and left Annie standing at the bus stop?!) You could have just walked up to the bus and automatically ended up at the airport, CashCard™ appropriately debited.

It’s been over 25 years since Zak, but the bus puzzle still keeps me up at night. No, not really… it’s the stewardess-bathroom-egg-in-microwave puzzle! Anyway, because I’ve got all these extra waking hours I am always on the lookout for similar interaction problems where we could put in way too much time for the payoff. In Thimbleweed Park, one potential candidate is… The Elevator.

There’s a single elevator in Thimbleweed Park’s Edmond Hotel. You can board it, select your floor, and ride up or down, just like in a real elevator. What I haven’t addressed yet are all the complexities. What if Agent Ray is riding the elevator and you switch to Agent Reyes who pushes the call button from a different floor? Must we make the elevator behave like a real one and stop at the floor to let the other character on? What if two characters both press the elevator button at about the same time? What happens if both characters board and press buttons for different floors? (That’s what we expect on a real elevator, but do we need to implement this on our virtual one?)

See how things can get real complicated real fast? But on the other extreme, if the implementation is too simple, it could frustrate the player who expects Thimbleweed Park Hotel’s elevator to interact like real ones. “Hey! What’s wrong with this game? Why can’t I press every button and stop at each floor?! And where’s the emergency STOP button?”

For a first pass, I programmed the elevator so we can move around the hotel. I’m still looking for that balance between time invested in modeling reality and fun for the player.

Similar potential craziness involves what to do when you can see from one room into the next. For example, if Ray walks down the street and stands at the doorway to the bank, and then you switch to Reyes inside the bank. If Reyes opens the door to leave, should we see Ray standing there (on the other side of the door,) even though that’s really a different room? Should we design all our rooms so you can never see through to another room? In our old adventure games we never worried about this. Probably won’t now. Sometimes reality is just not worth programming.

– David

Thimbleweed Park Podcast #9 Fri, 12 Jun 2015 14:37:00 -0400

This weeks podcast is marked NSFW and Parental Guidance Suggested as David throws the M-word around.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Design Dilemma Wed, 10 Jun 2015 14:22:00 -0400

Editors Note: There are NO spoilers in this post.

Every adventure game I’ve worked on has had the “one puzzle”. The one that drives you crazy because you know the end result, but you don’t know how to get there. You try everything and it all seems too obscure, or worse, too arbitrary. You like the core puzzle, you like the objects it uses, but you just can’t seem to make it work.

In Monkey Island, the rubber chicken with the pulley in the middle was one such puzzle. The player needed to get to Hook Island and the zipline felt like a good solution. There was something nice about that, but we just couldn’t figure out a clever way for it to work. Maybe you could use a small piece of rope or cloth to slide along the line, but that was boring. We had the idea of a small pulley or something round like a pulley, but that was also boring.

I’m don’t remember who came up with the rubber chicken with a pulley in the middle, it sounds very Steve Purcell, but it might have been Dave or Tim or Noah or any number of people we brainstormed with. I just don’t remember. But, it was born out of pure frustration: “Screw it, just make it a rubber chicken with a pulley in the middle” and then we’d all laugh and there was a moment of silence where we all realized that was the solution. It was a puzzle solved with humor.

Humor is a great puzzle solver, but you have to be careful. Your solution might be funny, but the objects involved might be too useful in other situations. I felt we were pretty safe with the chicken with a pulley in the middle. Not too many other puzzles that could be solved in unintended ways.

Axes are alway bad. The moment you put an ax in your game to solve a puzzle, you’re asking for trouble.

Maybe the ax is needed to chop down a tree (a legitimate but slightly boring puzzle), but the problem is an ax is a universally useful tool for everything from smashing locked doors (Jack Torrance style) or pounding nails or cutting a piece of string.

You can have the characters say “I don’t want to do that” if they try and smash in a door but that feels cheap and players know it. There are legitimate reasons for the main character to say they won’t do something but they can’t do it every time the player tries to (legitimately) solve a puzzle in a way the designer doesn’t want.

Which brings us to Thimbleweed Park, the whole reason you’re bothering to take a few minutes from you busy day and read this website.

We are confronted with such a puzzle and we’d like to open it up to all of you to help figure out an interesting and possibly funny solution. We’re not doing this as a “PR stunt” to make the backers feel engaged, we’re truly doing this because we’re stumped.

If you follow the link below, there will be spoilers, but not major ones. This is a relatively small puzzle and it happens in the first 30 minutes of playing the game.


Please do not post comments on this page talking about the puzzle or any other spoilers. I will delete them and not feel even the slightest pang of guilt (possibly even some glee).

– Ron

Exploring Delores II Mon, 08 Jun 2015 11:30:18 -0400

So, effectively Step 1, would be defining your character, typically in text as we did in the previous post. This can be as loose or complicated as necessary depending on the character and their place in the story. Once again, keep in mind this is an evolutionary process, and should grow and refine itself over the course of the project (at least this is how we like to work) as you develop from your first outline, through final design and implementation.

It used to be in the good old days when we had a character to design, we’d head off to the library or the newsstand to see what kind of visual reference we could manage to find. Magazines and books were the cornerstone of the materials we used.

When I first worked at Continuity Associates  (Neal Adam’s studio) we kept a big file cabinet dubbed ‘The Morguefile’ where in alphabetical order file folders were painstakingly (by hand) filled with magazine clippings, photocopies and sketches on every subject from Armadillos to Zebras and everything in between. We’d also hit the streets with a sketch pad to draw and take notes of anything in the real world that could be useful.

When we started at Lucasfilm, one of the truly amazing resources was the Main House Library, on site we discovered one of the world’s premier visual resource libraries; which completely made sense when you had folks over at ILM needing to figure out how to make convincing replicas of something like a rickshaw from 1940’s ShangHAi. That amazing Library complete with spiral staircase and stained glass ceiling dome (somewhat immortalized in Maniac Mansion) was pretty much the go to place for all our visual needs during our time there.

Today, obviously the internet has effectively changed this process forever, although there was something to be said for the visceral experience of going out into the real world to gather  visual reference, it was a costly and time consuming experience.

Using google image search I can just type in “women’s fashion 1980’s”.  Additionally, how else could I reach out to a group of enthusiastic backers to get all these great thoughts images and links. Please keep in mind that this is a snapshot of all the materials gathered to date, and may not include everyone’s comments at the time of this post, however we will continue to review and add anything new to the Delores Database.

Once we have everything assembled, we’ll go through and review and prioritize all the descriptions and images, boiling that down to (hopefully) a number of key character traits and visual components we feel best portray Delores- which will lead us to the next logical step to sketch a number of more refined character drawings. This next stage will need to be much more directed, possibly yielding a half dozen examples, that the final version will be refined from.

– Gary

More Mark Ferrari Wed, 03 Jun 2015 15:36:05 -0400

Here is a interview with Mark about his work and Thimbleweed Park:

Click On Me! Please!

And another one of Mark’s test images for Ransome’s circus…

We’ll be posting for of Marks stuff over the next few weeks. I’ll also be posting a bunch of pictures from my drive up to Seattle and you will need to sit quietly and look at them all with me. Every single one!

– Ron

Mark Ferrari™ Joins Team Thimbleweed™ Mon, 01 Jun 2015 11:53:00 -0400

So my dream team on the art development side of Thimbleweed Park is a reasonably short list, consisting mainly of people we’ve worked with in the past on a number of our graphic adventures, in particular artists who were instrumental in making the SCUMM games around the time we created Maniac Mansion, Loom and Monkey Island.

At the very top of the list is Mark Ferrari and we’re amazingly excited to announce that he is now part of Team Thimbleweed and will be doing most of the backgrounds. Mark was the background artist for the incomparable Loom and was also responsible for the stunning backgrounds on Monkey Island 1. Mark might truly be the most talented background artist I’ve ever worked with.

It’s hard to contain our excitement of having Mark on board.

Here is one of the tests he did for the entrance to the circus Ransome lives in. It’s a long way from being done, but you can see where he is going with it.

Keep in mind that this is just a initial samples he did for us and (although they might not look like it) are still wireframes. Ron and I are still working to determine the final nuances of the graphics and although we’ll be showing off a number of examples, most are still placeholder art, we’ll let you know when something’s actually final, we promise!

As one of the premier environmental artists in the gaming industry, during our tenure at Lucasfilm/Lucasarts Mark’s early work with us is considered legendary. In the 80’s he managed to stretch the look of 8 bit color palettes with innovative dither techniques, lighting and layout. Mark also developed a truly unique approach to color cycling/palette shifting unlike anything seen before or since.

Remember, this isn’t animation in the traditional sense, rather it’s all being done by just organizing and changing palette registers in sequence. At that time we didn’t have the computing power necessary to just make it an animated .gif… This was mind blowing stuff!

I first met Mark at, of all things, a science fiction and fantasy convention being held at the San Jose Red Lion Inn (shades of ThimbleCon). Everyone was talking about some guy in the art show who drew amazing stuff in colored pencils… I took a look at Mark’s work and was amazed, they practically looked like oil paintings done in prismacolor pencil.

Being the art director of Lucasfilm Games at the time had its perks and I was immediately introduced to Mark. My memory’s a bit fuzzy, but I don’t think Mark really had any computer experience at the time. In those days I invited candidates out to Skywalker Ranch for lunch and an art test working on an IBM PC in dpaint.

To say Mark was a natural at computer graphics would be an understatement, he was constantly breaking new ground, first on Loom and then on Monkey Island. As with most of the art staff from those days, Mark remained friends with Ron and I over the years.

Having Mark on the team will move the art more in the direction that will end up being half way between Maniac Mansion and Monkey island as he’ll be taking over finalizing most of Thimbleweed Park’s background art development. We haven’t completely finalized the look, and this is a little different from the Kickstarter art, but we like where this is going.

In any case… welcome to the team Mark, it’s great to be working with you again!

Head on over to Geekscape for interview with Ron and I.

– Gary

Thimbleweed Park Podcast #8 Fri, 29 May 2015 14:32:00 -0400

Hear Gary and I talk about bug databases and how sexy Razor was. It’s another painful episode of the Thimbleweed Park stand-up meeting podcast.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Exploring Delores Mon, 25 May 2015 12:32:38 -0400

I know what you’re thinking: Ron and Gary obviously have everything completely figured out, especially when it comes to being hip and knowing everything about the style of what all the cool kids are doing and wearing in the 80s. If only… I doubt Ron or I were ever called one of the cool kids.

There comes a time in any project where you realize something isn’t working, so we’ve decided to make a design change to the background story regarding one of our major playable characters; Delores Edmund who has returned to Thimbleweed Park for the reading of her uncle’s will.

Originally, Delores was conceived as likely being a middle-aged character, possibly a professional woman. Here’s how she appeared in the original kickstarter:

As we got down to the detail of designing the backstory for each of the playable characters, we quickly settled on their appropriate appearance and attire.

Ray and Reyes are federal agents who wear pretty straight laced suits, Ransome’s a somewhat creepy clown, so he pretty much designs himself and Franklin…. well Franklin’s a ghost, so however he’s dressed it’ll be in shades of blue and semi-transparent like the rest of him.

Dolores however, as a character, underwent the most significant change during the design process and we decided to make her younger, in her early twenties, on top of that she would become an aspiring game designer and programmer, likely working for a well known computer games company.

Here is her new character description:

Delores – Delores is in her early 20s and had been programming and taking apart computers since she was 10. She was self-taught with the help and encouragement of her uncle who has a (somewhat dated) technology background from building his fully automated Pillow Factory in the 1950s. Delores spent much of her free time hanging around the Thimbleweed Park Arcade and even got a part time job fixing the game machines. A year ago she got an internship at the prestigious and well known game company, MucusFlem Games, which turned into a full time job programming and designing games. Delores is a nerd, but she is far from the stereotypical anti-social geek. She has a lot of friends and isn’t afraid to have fun on a Saturday night. She has attended every ThimbleCon since it started 4 years ago. Her favorite TV shows are classic Star Trek (she has a small crush on Kirk), Remington Steele and MacGyver. Like many people her age, Star Wars was very influential. Contrary to the wishes of her uncle, she has no desire to live in Thimbleweed Park and take over the family Pillow Factory business. She was happy to move away last year and enjoy the life of the big city. This has always been a sore spot for the rest of the family. Delores has an older sister, Margie, that is also in town for the reading of the will. Delores and Margie don’t get along, but are polite to each other.

So at this point we want to develop a relevant (to the mid 1980’s) and interesting look for her, her outfit and overall style and we’d like your help.

When creating characters, the way we usually work is to gather a lot of reference material from the internet and do quick sketches, exploring a lot of different directions at once. We just go wide and don’t do a lot of self-censorship. There are no bad ideas during brainstorming.

We started to explore the new Delores, but thought it would be fun to open it up to all of you and have a little fun with it and step through the whole creative process.

So, please lend us a hand in figuring out the look of the new Delores. Your contributions could be through a written description, links to photos and other visual reference or even your own sketches.

Once we’ve gathered everything, we’ll do another post putting it all together and then start exploring some tighter concepts. We’ll go through the whole messy process step by step.

At the end, half of you will love her and the other half will hate her. Welcome to the world of game design.

Our lawyer (actually, he’s just Ron’s know-it-all barber) wants us to remind you that you are granting us complete rights to use, in any way we see fit, any original art, materials, works, or ideas you submit for this undertaking. Imagine this paragraph written in completely unintelligible legalese for the full effect.

– Gary

Thimbleweed Park Podcast #7 Fri, 22 May 2015 15:44:00 -0400

Listen to me use math terms like “epsilon” with no real understanding of what they mean.  It’s time for another dynamic Thimbleweed Park stand-up meeting.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Almost Final Puzzle Dependency Charts Mon, 18 May 2015 10:39:00 -0400

Late last week, Gary, David, Jenn and I got together for what will probably be the last big brainstorm for Thimbleweed Park puzzles. Prior to our meeting, the main story puzzles had all been designed and placed into a glorious puzzle dependency chart, but what we didn’t have were the puzzles for the character specific arcs.

These are the side stories that follow Delores, Franklin and Ransome, and, for the most part, these stories were conceived to be optional. If all you care about is finding the murder and uncovering the mystery behind Thimbleweed Park, you can ignore most of the side stories.

As I mentioned in one of the first posts, you won’t have to complete these side stories by the end of the game, you can go back and do them later, and the way it worked out, you can (but aren’t required to) do about 90% of the side stores before completing the game, but the last few puzzles require the main story to be completed.

This ended up working well from a storytelling perspective because the conclusion to the each of their side stores is tied to the end of the main story, so they should feel like nice epilogues to what has just happened and provide more insight and understanding.

The chart below is color coded to show the character stories. Ransom is in pink, Franklin is blue, and Delores is green. Most of these nodes are optional, but not all and it varies by character. Most of Franklin’s puzzles are optional except for the first few. The first half of Ransome’s puzzles are required, then the second half become optional. Delores is somewhere in between.

As I mentioned in last week’s podcast, this is the most complex dependency chart I’ve ever done, and for the time being, I’m going to assume that is a good thing.

As a designer, I tend to over-design then cut stuff as it becomes superfluous. I find it easier to cut stuff than to hastily add stuff at the end.

Another goal of the last brainstorm was to find good (emphasis on the good part) puzzles for the rooms that have no use in the game. I feel were were half-successful in that. There are a handful of rooms that serve no purpose and we’ll probably cut them.

The arcade has no use in the game, but we’d rather not cut that because being able to play some of the games that appeared in Maniac Mansion would be fun. It’s going to drop to a C task and if we have time, we’ll wire them up. Don’t expect much, they will be more like WarioWare games than proper arcade games.

At this point in a project I like to group everything into A, B and C tasks. A tasks are necessary for the game, they can not be cut. B tasks are pretty necessary, but can be cut or at least redesigned to be much simpler. C tasks are fun stuff that would be fun to have in, but can be cut (and mostly likely will). I don’t want to cut them too soon because they might end up being simple to implement and just get done. The ranking of A, B and C tasks are completely fluid, ever changing as the game progresses. Today’s A task is tomorrow’s B or C task.

I am feeling a little overwhelmed by the scope of the design. If we had another game programmer and another artist, I’d feel fine, but I’m not going to panic yet.

Now for what you’ve all been waiting for… the puzzle dependency chart. Feast upon it’s glory.

The caveats from the last post still apply. Act 1 seems much larger than it really is due to many of the puzzles not needing to be solved until act 2, it’s just the way OmniGraffle positions the node.

The modes with red outlines are node we still need to figure out the puzzle. We know the object/outcome, but not how you get here. These nodes will expand into 2 or 3 nodes.

Everything is blurred out, so there are no spoilers. Unless you didn’t want to know the game had puzzles, in that case, it’s been spoiled.


Thimbleweed Park Podcast #6 Fri, 15 May 2015 13:59:00 -0400

David phones in from his car mechanic’s waiting room and Gary gets a text message! What craziness will happen next on the Thimbleweed Park stand-up meeting podcast.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Quick Sketching Wed, 13 May 2015 11:41:00 -0400

One of the things you discover working on a good sized adventure game from the perspective of creating the art assets, at least for me, is that there’s a lot of first pass visual design that needs to be done to get a feeling of where you’re actually going.

Typically when I start a project I’m full of all kinds of grandiose visions of what the game might look like. The temptation associated with this is to spend way too much time – certainly in the beginning trying to realize every little detail and nuance of a scene. This can easily lead to too much time and effort for a given concept or preliminary  image, although some of this can be great (and helpful to set the overall tone), is it really necessary to know how many rivets are on the side of a computer panel, or arrange all the flowers growing next to a stream into truly aesthetically pleasing shapes. On top of that, we’re only human, and the more time you spend on something, the more you’re loath to give up on it and start over.

Sometimes for the sake of understanding where you’re going you just need to dive in and limit yourself to a quick 15 minute sketch to understand basic layout, perspective and shading. It’s amazing how freeing this can be, especially when you might be stuck.

At this point we have a pretty clear idea of the direction we’re going with the story and the basic look, and the current task for the art department (namely me) is to get Ron and David as much wireframe art as possible so we can get a good working walkthrough before we really get into the swing of full scale production.

I learned early on in my career, mainly through working as an assistant to the likes of Neal Adams, to just grab a pencil and a piece of bond paper and rough out as many approaches to a scene as quickly as you could in an hour, it gets your juices flowing and helps identify problems early on.

When you’re working on a long term (a year or better) creative graphics heavy project, whether it’s a game, comic or movie, you never want to get too attached to anything- at least on the visual detail side. You need to build a framework that allows you to easily iterate and change for the better.

Additionally, if you’re working as part of a team. hopefully it’s a group of people whose opinions and ideas you respect- obviously I’m very lucky in that area, and wouldn’t rather be doing anything else. Anytime you’re responsible for the visuals of a project, especially a commercial endeavor you’re not creating that in a vacuum (at least I hope not), you need to be in a synergistic team relationship that helps make your vision stronger as a result of collective brainstorming and evolve as you go. As Chip Morningstar once put it “You need to feel like your team is running along ahead of you with a steam roller, instead of chasing you with one”.

Creating a game as complicated as Thimbleweed Park, and make no mistake, although we’re working with an 8 bit art look- this is a complicated game from the perspective of the amount of 2D screens, the feelings we want them to convey, the number of characters, stories, puzzles and situations means you have to be able to easily change and adapt the visuals as you go. With limited resources, the quicker you can get on the right track, the more time you’ll have to polish the final result.

State Of The Game Mon, 11 May 2015 14:49:00 -0400

I think it’s time for a quick state of the game post.

Thimbleweed Park began in earnest on Jan 2 and it’s now May 11, that’s a little over 4 months and our planned ship date is July 2016, so we have around 13 months left. It’s safe to say the easy part is over.

How We Got Here

We got off to a slow start in January, mostly due to the amazing minutia involved in actually getting a company set up, getting contracts written, filing paperwork, setting up websites, and getting bank accounts established. If you’re ever going to do a Kickstarter, don’t underestimate the time this takes, especially if the burden is falling upon the same people that are actually going to be making the game.

I know it’s not completely true, but it feels like nothing happened on the game during the entire maiden month of the year. I know this isn’t true because we did a lot of design work and had some great brainstorm sessions and set the story firmly on it’s current track. A lot happened, it just didn’t feel like it at the time. You can go from feeling you have all the time in the world to feeling like you’re hopelessly late in the blink of an eye. That event horizon always sneaks up on me and it surely shares many of the same qualities of falling into a black hole.

February and March were two great months. The engine made astounding progress and the solid first of the wire frame art started to show up.

Of all the important features of a game engine, none ranks second to a good art pipeline. The art assets of any game, especially an adventure game, can be staggering and it’s important, nay required, that you have a fast and efficient way to track the art and get it into the game.  I’m a huge fan of automation. Humans are shitty at boring, repetitively detailed tasks. Our robot-computer friends excel at this and I am more than happy to put them to work.

Part of the success of February was getting a good art pipeline in place. When new art comes in, and more importantly, when old art changes, it’s a couple pushes of a button and the typing of a command line and the new art is crunched, munged, processed and put into the game. The goal is a razor thin zone of possible human error. I like to have confidence art changes are quick, safe and painless to drop into the game.

March saw some good design progress. A lot of disjointed ideas came together in a nice cohesive story and puzzle structure. Based on this, the art moved forward driven by a nice concrete list of rooms and objects.

The engine sprinted along in April and David Fox came on part-time to help wire up rooms and stress test the scripting language and tools.  I spent a good deal of my early spring fixing bugs and adding features. I consider the engine to be minimal feature complete.

The art started to hit some bumps as we wrestled with issues with layout and re-did some of the early rooms. The rooms were starting to feel a little too boxy and flat so we spent a some more time experimenting with the look and some snazzy tech like parallaxing. The art needs to invoke the feel and authenticity of the classic adventure games, most notably Maniac Mansion, but it can’t feel dated and long in the tooth, nor can it be hipster-pixel-chic.

It’s fine line to walk and it’s taken us a little longer than we hope to navigate the blocky waters of 1987 vs 2015.  We don’t think this will impact the final date because once the style is finalized, the lost time can be made up through focus, persistence plus a little sweat.

Where We’re Going

The plan was to start full production on June 1st, but realistically that won’t happen until June 15 or more likely July 1st.  Production is defined as knowing everything you need to build and how your going to build it, so it’s now just a matter of building it. It’s not as easy as just starting a machine, it is a creative endeavor, so there is always a lot of adjustment and turning, plus you have new great ideas that beg to be implemented. There is a dance between implementing new great ideas and feature creep, a dance whose steps you never quite know or learn and it’s mastery is defined by recovering from mistakes with grace and stealth.

I’ve never been a fan or admirer of giant design documents that are followed with a religious fervor, nor am I a fan of touchy-feely I’m done when I’m done production. I like to know where I’m going, when I’m going to get there, but also not be afraid to take a detour to make the journey and destination a little more exciting or interesting. I have a lot of respect for creative people who also get shit done.

So, production will start around a month late, but we don’t see that moving the final date.

One aspect of the art that is still a little unknown is animation. We want to do a lot of what we called “special case animation”, animations beyond the reusable walk/talk/reach animations. The original Maniac Mansion had none of these, most noticeably when anyone used the weight machine and flaccidly stands there while the machine magically moves up and down. Memory was tight. C64 Maniac Mansion had 19K of memory caching of game assets. K. K!

This is a low-risk issue, so we always knew we would wait until production started before exploring it fully.

We just started talking to some of the console manufacturers about bringing Thimbleweed Park to the consoles and handhelds, but those are long roads to travel. That’s exciting.

We’ll start thinking about music in September or October.

In the long term, Alpha is scheduled to start on Jan 1st. Alpha (for us) is defined as the whole game playable, but with a some amount of place holding unfinished art, a first pass at all the dialog and music.

Testing will also start in January where we’re bring on a lead Tester, then slowing ramping up on 3 or 4 more paid testers. Beta testing will begin in May, although we don’t know the extent of that yet.

Voice recording and translations will also happen May-ish. I know that’s later than a lot of projects do voice, but I want to want until the last minute to maximize the time to edit, change and polish the text.

Things that scare me

The writing scares me in that I don’t know if I’m going to do full dialog trees yet. They are a staggering amount of work and I won’t be able to do that by myself, not with the bulk of the engine work falling on me as well. I would also like to hire a part-time engine programmer to help with DX, shaders and some lower level OpenGL tasks. It’s going to be a balance of writing and engine work all dictated by if we can find the money in the budget.

Animation is worrisome, in that it can be a slippery slope (of awesome). We have a plan for a good amount of animation, but we also know how amazing it is to see once it goes in the game and scoping ourselves will be hard.

The Android port scares me. My engine already runs and cross compiles to iOS, but not Android and the little work I did on Android for Scurvy Scallywags was a hair-pulling experience. It’s an area that I am going to need help on (please don’t offer to help, that’s a ways down the road). The mobile ports will be a few months out from the PC/Mac/Linux main Kickstarter versions so I have a little time before full-on panic sets in.

Managing the translations scares me. We don’t have a “producer”, so wrangling translators is going to fall to Gary, David or I and it’s going to come at a stressful time in the project. We did budget for an audio/voice director/producer so at least we don’t have to worry about that.  In retrospect, we should have budgeted for a part-time producer, although budgeting for and having the money for are different things.

And the last thing that scares me is all the stuff we probably haven’t thought off yet and the weird stuff that always goes wrong.

But, that’s part of what makes making games fun. They are a game unto themselves.

What does all this mean for the final ship date? Are we on track? What is our confidence level? It’s hard to say, we feel good about it, but we’ll know better a couple of months into production. We would love to have the money to hire another art and tech person to give us a little breathing room, but everything still feels good.

Well, that’s the State of the Game and we’ll do these once every 3 or 4 months.

– Ron

Thimbleweed Park Podcast #5 Fri, 08 May 2015 14:23:00 -0400

I’m in Seattle for the next few days, and I don’t have my amazing World of Warcraft Raiding Headset with me, so I apologize for the sound quality and mic scratching noise. Look, I said I was sorry, so can we just drop this?

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

TesterTron3000 Sat, 02 May 2015 11:13:00 -0400

In Friday’s podcast, I mentioned that I’d implemented an autoplay mode for Thimbleweed Park, where the game could play itself.

I can’t remember if it was for Last Crusade or Monkey Island when Aric Wilmunder and I wrote the first autoplay scripts for the SCUMM games and they were invaluable.

Aric and I were in Chicago at CES (the Consumer Electronics Show) where Lucasfilm Games was showing their latest wears. CES was a loud, noisy, crowded spectacle of a show that would – at least for games – be replaced by E3, a new loud, noisy, crowded spectacle of a show.

Lucasfilm Games had a booth with several PCs connected to monitors, keyboards and mice, and we would stand around and ask passers-by, “Would you like to see Maniac Mansion or Monkey Island?” Lucasfilm Games was small back then and everyone pitched in. Designers, Programmers, Artists, we were all expect to stand around for 8 hours and demo the latest games.

It was grueling.

Demoing adventure games is especially hard. They’re about thinking and pondering and enjoying a good conversation. They don’t demo well.

So, Aric and I got to talking about implementing a self-play mode, where we could just stand around at the booth and the game would play itself and you could take over if someone wanted a demo. Most people are happy to just watch a game being played, even if completely randomly, so this would take a lot of pressure off the poor person on booth duty. Some movement, even random movement, was better than a idle screen with a completely still and slowly pulsing crosshair cursor. The arcade games called this attract mode.

Aric and I spent the evening in our hotel room banging out SCUMM’s first autoplay mode. It wasn’t sophisticated. It randomly picked an object in the room and then randomly picked a verb and then did that. It didn’t need to be smart, it just need to do something that looked interesting.

We would later expand on the autoplay scripts, and they would use inventory items with other items and even do rudimentary dialog choices. All with the unblinking precision and determination of rand().

During Monkey Island, I would leave autoplay running overnight and the next morning I’d come in and see where it crashed, or got stuck in a walk box gap, or be amazed at how far it got just picking random objects.

Autoplay was great for finding “one frame bugs”, where you’d click on something and then something else one frame later. They are the kind of bugs human testers don’t find, but robots do.

So last week I implemented testerTron3000, the autoplay script for Thimbleweed Park. Much like the fist SCUMM autoplay scripts, it just randomly picks stuff and does stuff to that stuff.

It’s already found several bugs and it’s amazing how far it gets when I check it in the morning.  It keeps a log of every action it preforms and the time it did it.

At the 30 second mark, I pressed the ‘f’ key and put the game into fast mode. Please keep in mind this is all wire frame art and no where close to final.

Still a lot of changes to make, like limiting the amount of time spent in each room, not always leaving a room and next click after entering. These should still happen, just not as often as they do. What I’ve always found important in these autoplays is not to guide them too much. The inclination is to have them run a test plan, but the whole point of these is to just randomly do shit we haven’t thought of. You can guild the autoplay in the right direction, but let it do it’s thing.

Here is the code:

function testerTron3000() {


    while(YES) {
        // Find on object in the Room
        foreach (obj in currentRoom) {
            // Is this an object
            if (isObject(obj)) {
                // If there is no valid usePos, it’s probably an inventory object.
                if (objectValidUsePos(obj)) {
                    // Might be dependent on another object, or just untouchable
                    if (objectTouchable(obj)) {
                        if (randomOdds(0.20) && objectValidVerb(obj, VERB_WALKTO)) {
                            logInfo(“Walk to “
                            pushSentence(VERB_WALKTO, obj)
                        if (randomOdds(0.20) && objectValidVerb(obj, VERB_LOOKAT)) {
                            logInfo(“Look at “
                            pushSentence(VERB_LOOKAT, obj)
                        if (randomOdds(0.20) && objectValidVerb(obj, VERB_PICKUP)) {
                            logInfo(“Pick up “
                            pushSentence(VERB_PICKUP, obj)
                        if (randomOdds(0.20) && objectValidVerb(obj, VERB_OPEN)) {
                            logInfo(“Open “
                            pushSentence(VERB_OPEN, obj)
                        if (randomOdds(0.20) && objectValidVerb(obj, VERB_CLOSE)) {
                            logInfo(“Close “
                            pushSentence(VERB_CLOSE, obj)
        local time = gameTime()
        while(YES) {
            if (!actorWalking() && !actorTalking()) {
            if (gameTime() > time + 30.0) {
                logWarning(“Time Out”)

– Ron

Thimbleweed Park Podcast #4 Fri, 01 May 2015 13:42:00 -0400

A nice and short stand-up meeting this week…

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Now With More Email Signup! Tue, 28 Apr 2015 23:14:00 -0400

Are you tried of hitting refresh every hour to see if there is an update to the Thimbleweed Park development blog? I know we are! Not sure what RSS is or how to pronounce it? I know we don’t!

Fear not brave adventure game aficionado, we’ve got you covered with ThimbleMail™!

Enter your email address below and we’ll add you to an exclusive list of people who automatically get emailed when we have a new blog post.

Enter your email:

Don’t worry. We will never sell, give away or part with your email address. We will never send you any marketing spam, e-pons, special offers, or clutter up your inbox in any way (other than sending you an email when this blog updates). All email addresses are xor’d with 0x69 while in our database for optimum security.

After signing up, you will get an email to confirm your email address then you’re off to the races. Well, not literally, of course. Unless you really are heading out to the races, then I guess it is literally.

P.S. You can unsubscribe to ThimbleMail™ at any time with the click of a button.

P.P.S. This feature is in BETA. Hopefully no one will get hurt, but your help is appreciated.

Walk Boxes! Mon, 27 Apr 2015 13:34:00 -0400

Here’s a quick video I did narrating walk boxes, how they work, and how they are used with doors and other blocking objects… enjoy.

As the video shows (You did watch the video? I spent hours making it, the least you can do is actually watch it!) walk boxes can be turned on and off via script control and that was one of my basic requirements for the system.

That introduces some complexity into the path finding, but that complexity is worth it in how easy it makes blocking players with closed doors, gates, etc.

Right now, walk boxes must be convex polygons, but I plan on making it so actors can navigate around the interior of concave polygons.

That’s a slightly more complex problem because with convex polygons, you can draw a straight line/path between any two points inside the polygon, so if the actor is walking within it, there’s no pathfinding. With concave polygons, the actor will need to path find around the edges of the polygon.

Not a huge problem, but I wanted to get walk boxes working and then move on to other tasks in the engine and game. I’ll revisit path finding in a few months. As I mentioned on last week’s podcast, path finding is a task you can get lost in very easily. It’s a rabbit hole of refinements. My goal is to get everything working in the engine, then go back and refine what needs refining.

Here is the code for the jail seen in the video above (You did watch it? Right?).

SheriffsOffice <-
    background = “SheriffsOffice”

    enter = function()
        if (sheriffsOfficeJailDoor.jail_door_state == OPEN) {
        } else {

    exit = function()

    jail_close_duration = 1.5

    function openJailDoor() {
        objectOffsetTo(sheriffsOfficeJailDoor, –600, SheriffsOffice.jail_close_duration)
        objectTouchable(sheriffsOfficeJailDoor, NO)
        objectTouchable(sheriffsOfficeJailDoor, YES)
        sheriffsOfficeJailDoor.jail_door_state = OPEN

    function closeJailDoor() {
        objectOffsetTo(sheriffsOfficeJailDoor, 00, SheriffsOffice.jail_close_duration)
        objectTouchable(sheriffsOfficeJailDoor, NO)
        objectTouchable(sheriffsOfficeJailDoor, YES)
        sheriffsOfficeJailDoor.jail_door_state = CLOSED

    sheriffsOfficeJailDoor =
        name = “Jail Door”
        useDist = 20
        jail_door_state = CLOSED
        verbLookAt = function()
            if (jail_door_state == CLOSED) {
                sayLine(“The door is closed.”)
            } else {
                sayLine(“The door is wide open.”)
        verbOpen = function()
            if (actorInWalkbox(currentActor, “jail”)) {
                sayLine(“I can’t open it from in here.”)
            if (jail_door_state == OPEN) {
                sayLine(“The door already open.”)
            } else {
        verbClose = function()
            if (jail_door_state == CLOSED) {
                sayLine(“The door is already closed.”)
            } else {


– Ron

Thimbleweed Park Podcast #3 Fri, 24 Apr 2015 17:44:00 -0400

This week we are joined by David Fox as we do our weekly stand-up meeting.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

P.S. I wasn’t standing.

Comics On The Side Thu, 23 Apr 2015 11:29:00 -0400

One really nice thing about working on games for me, especially something like Thimbleweed Park where I’m intimately involved in the design is I can weave things into the story that are very personal (as long as they can make sense to the overall direction).

In my particular case, besides studying computer game and digital art, I spent a lot of my formative years working in the comic book industry. I certainly learned a lot of my artistic craft growing up in the 60’s and 70’s reading comics and copying sequential panel art.

Most recently, my own comic book Bad Dreams , which I wrote and drew over the last several years in my copious spare time was published as a limited series by Red 5 comics and is now coming out this June in a trade paperback edition and here’s my shameless plug.

This experience has also led me to creating a number of other comic books, some of which might actually be showcased at ThimbleCon of all places (at this point I’m not saying how much or many – that will have to be a surprise). Depending on audience reaction some could even be developed further. That’s part of the beauty of independent adventure game and story development as you brainstorm stories and ideas you never know exactly what might make it into your final design, but you’re free to try any idea.

Ron and I are constantly drawing from our own life experience and warping that into whatever demented shape we can to achieve a compelling story, we did it for Maniac Mansion and we’re doing it for Thimbleweed Park. No, we didn’t actually murder anyone, or build a reactor in the bottom of a swimming pool, but the characters, relationships and situations certainly have a lot to do with us, our sense humor and how we think.

Art does really have a tendency to imitate life, particularly when a designer or an artist is creating something as personal as an adventure game story, certainly that’s been my experience working with Ron.

When we created Maniac Mansion back in the 80’s we were basically just getting wet behind the ears and nothing was sacred, our interests in all forms of media, friends, families and significant relationships were all fodder for the adventure game grist mill. Even my girlfriend at the time, ‘Rae’, who became ‘Razor’ wasn’t off limits (as far as I know, she never microwaved a hamster), nor was the head of Lucasfilm Games accounting, Wendy. If I remember right, Sandy was someone at ILM Ron had a little schoolboy crush on. We won’t even get into who Dr. Fred, Nurse Edna and Weird Ed were…

As far as the stylistic visual approach and situations besides drawing from a number of B grade horror movies, I also looked toward my love of classic EC comics for further inspiration, including ‘Tales from the Crypt and ‘The Vault of Horror’ which believe it or not generally offered up their own macabre comedic twists.

– Gary

Act 1, 2 and 3 Combined Puzzles Mon, 20 Apr 2015 11:16:00 -0400

I’m a visual person. Math only makes sense to me when I see graphs and x and y axis plotted on paper, before that it’s just a bunch of symbols with no meaning. Schedules make no sense to me as a list of dates, I need to see them plotted out with bars intersecting and overlapping and spanning the weeks, months and years. It is only then that I glean the sense of the time and work needed. It’s all about me visually absorbing the information of milestone slippage and cost overruns.

Game design is no different. I need to see the design. Something about the flow and structure of the design has to excite my visual sense. I need to see the picture of the design and it has to feel good, in the way a well constructed piece of art can move the soul. I need to have a visual appreciation for the design that goes beyond the information it contains.

That’s one of the reasons I like Puzzle Dependency Charts. They are inherently visual. I can get a sense of the design without knowing anything about the text that appears in the little boxes. Puzzle Dependency Charts allow me to feel the design beyond paragraphs of text or spread sheets of data.

Last week, myself, Gary, David, and special guest designer Jenn, locked ourselves in a room for a day and begin to fill in the details of Act 3 and tie up all the dangling threads previously spun from Act 1 and 2. The next day I created the Puzzle Dependency Chart for Act 3 and began the tedious process of combining the separate Act 1 and Act 2 charts into one chart, depicting the entirety of the core game. That chart is presented above. Please, no flash photography.

There are some puzzles missing from this chart worth noting:

The Delores, Ransome and Franklin flashbacks are depicted as a single box, where in the final game they will be small mini-self-contained adventure games.

There are also several red boxes indicating that we have not fully figured out the puzzle. Most of the red boxes will explode into 4 or 5 new boxes, many with parallel puzzles to solve while (hopefully) tying into the other puzzles.

The chart does not contain the alternate solutions to many of the puzzles.

The size of Act 1 is slightly misleading due to many of the puzzles shown in Act 1 do not need to be solved until Act 2. The graphing software feels compelled to place them up there.

And most important… The chart does not depict any of the personal story puzzles chains for Delores, Ransome or Franklin. These chains are completely optional and their conclusions happen during the epilogue. We have a understanding of the core flow for each, but have not designed them in detail.

That is for our next brainstorm session.

– Ron

Thimbleweed Park Podcast #2 Fri, 17 Apr 2015 15:39:00 -0400

Hot off the presses, it’s the second Thimbleweed Park Stand Up Meeting Podcast, recorded a few hours earlier and hand edited to perfection*.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

* Perfection not guaranteed.

Thimbleweed Park Podcast #1 Mon, 13 Apr 2015 13:34:00 -0400

Welcome to the first Thimbleweed Park Standup Meeting Podcast.

Standup meetings are the trendy hip meetings that agile projects have each day to quickly talk about what is happening. Management will tell you they are standup so everyone stays focused, but the real reason is they want to save money on chairs. Don’t be fooled. It’s all about the bottom line. Do you ever see the fat cat executives standing during meetings? No! They are sitting in their comfy diamond encrusted Herman Miller chairs, paid for by pained soles of the exploited worker.  But I digress…

Gary and I will record a weekly edition of our standup (I’m actually sitting, screw standing) meeting each Friday that recaps the week and we’ll chat about what we’re trying to get done next week. Going forward, they will be posted Friday afternoon and include other team members as they come on the project.

We’ll try and keep them to around 5 minutes.

You can also subscribe to the Thimbleweed Park Podcast RSS feed if that’s ‘your thing’.

– Ron

Thoughts On Props Thu, 09 Apr 2015 12:06:00 -0400

Making a graphic adventure is sorta like making an animated cartoon. You have a world of backgrounds and stage pieces, some are interactive, some are just static set dressings that exists to reinforce the world and story.

Set dressing helps tell the story and gives the player valuable clues about where to go and what to do. Given the resolution we’re working with on Thimbleweed Park, and we’re paying homage to our earlier classic adventure games, most items are going to be displayed in some sort of straight on view, as odd angles are a bit harder given the ‘jaggies’.

Once again, we’re pretty much dealing with icons, we want the player to look at and immediately recognize their function: we really don’t want people saying “What the hell is that ? Looks like a phone? Or maybe an adding machine? No, wait, it’s a banana!”

Once we have our basic design, the first order of business, much like in film, is to make lists of all the visual assets, this includes characters, locations and all the objects and props.

Each of these needs to be designed, from a simple line rendition to fully rendered object. Use and location determines size/scale relative to the scene, angle, lighting and shadow and what if any animation might be required and each of these is layered onto the item as we go. Even though we’re dealing with a limited number of pixels and colors, I think there’s something very stylistic and recognizable about how we’re approaching the art and how the resulting objects will look.

As we wire up a room and its associated puzzles we may decide to add more items or props, maybe because it’s funny, makes the scene more interesting, or helps direct the player.

The ability to change and iterate items on the fly is a luxury we have over traditional film animation given that it’s reasonably easy to modify 2D art in our style, once again, the power of Ron’s engine and a versatile scripting language make all the difference… Hamster in a microwave anyone?…

– Gary

Engine Roadmap Tue, 07 Apr 2015 12:14:00 -0400

The following is the roadmap for the Thimbleweed Park 2D point & click engine. Keep in mind this is just for the engine, not for the actual game.

I’m really happy and excited by the progress on the engine so far. I’m much farther along than I thought/feared I’d be at this point. The original plan was for David Fox to come on in June to begin game scripting, but I think we’re going to move that up by a month. Around a quarter of the game is already walkable, so it’s time to start wiring up some puzzles.

All of the engine tasks lived their lives solely in my head, but I figure it’s time to start writing them down and making some task lists and put together a roadmap of where it all is going.

In the early stage of a project, schedules are more guidelines than ridged dates and milestones not to be missed. I like to get everything down and listed, but be flexible enough to move tasks around as needed. I tend to focus on risky endeavors first. If I don’t know how to do something, I like to get it done early, at least to the point where I understand how to do it.

I also like to hit everything with broad strokes, get all the system working at a basic core level, then go back and add features, work out kinks, optimize, and generally make them look better. It can be a real trap to spend too much time making one system look perfect, only later to find you don’t have enough time for a more important feature, or worse, you end up cutting the system you spent a month polishing too early.

The actor scaling in the last post is a good example of this. I’m not happy with the way it looks, but I wanted to get scaling in and working, it’s important for the room layout’s Gary is working on, and there is also a lot of code infrastructure related to scaling, like how to specify the scaling, linking actors to scaling, etc. Now it is working, I’m going to move on to the next item. I’ll revisit the visual aspect of the scaling a few months from now. How it looks isn’t important right now.

Thimbleweed Park is going to be an ugly game for many months. That’s how it is. We’re posting raw un-censored, un-pr-sanitized images and videos.


Sound system and basic commands to play sounds – I’m currently just using SDL_MIXER for audio and based on using it in other projects, it seems to do everything I need. I’ve looked at solutions like FMOD, but they are too expensive, even with their “indie” pricing. We’d end up spending over $6000 just to license FMOD for Win/Mac/Linux, I’d rather use that money on actual music. I might drop in a better system down the road, but this gets us started.

Scrolling inventory – The inventory is working, but you can’t scroll it yet. It’s not an issue until you get more than 8 items.

Windows version – I want to get the engine compiling on Windows. I had my GGLib compiling a test version of Scurvy Scallywags on Mac and Windows, so I image getting Thimbleweed Park compiling and running on Windows shouldn’t take more than a day.

Walk boxes – The editor part of the task is done, I just need to add it to the game engine. I started doing this a couple weeks ago, then abandon it due to my solution being too simplistic and not able to handle turning boxes on and off during gameplay. Plus, I really suck at math.

Actor talking animation – Actors can say lines of dialog (as you’ve seen), but there is no animation. All the animation is currently broken up into heads and mouths, so it’s just a matter a triggering them. Not sure of we’ll do lip-syncing. Our mouths are 2 or 3 pixels, but it might be nice when playing audio. That’s a “down the road” task.

ThimbleScript Wiki – I’m putting together a wiki of our scripting language, I should have that ready by the end of the month.

Script control over text and image sprites – I need to add commands so the scripts can create and display standalone images and text. There is already commands for showing and manipulating objects that appear in rooms, but scripters will need to create other images and text, mostly for closeups like an elevator panel or a newspaper closeup. All the engine code exists, it just a matter of hooking it up to scripting commands.

Basic cut-scenes – Cut scenes are a little more complex than just turning off the cursors, they need to track where the game was before a possible “cut” to a new room and silently return everything back to normal. Not rocket science, but it will take a good day or two of testing all the edge cases.


SFX triggers in animations frames – I’d like to embed sound cues into animations so game scripters don’t have to hand time sounds when animations happen. The obvious example of this is foot steps.

GGPackfiles for test builds – All the game assets will be packed into an uberfile. Shouldn’t take more than an hour to enable this. It was working before, it’s mostly writing the bash scripts to gather up the assets.

Add a toolbar to the debug window plus hotkeys – The debugger window window could use a toolbar and some user configurable buttons. To pause and step execution, you need to use the keyboard, which is fine, but they could use some fancy buttons as well.

Macro preprocessor for Squirrel – Squirrel doesn’t have a preprocessor stage, so I’m going to add the ability to do #define, #if, #etc commands.


Music system – As I mentioned above, I’m using SDL_MIXER for audio and it is a good fallback, but I’d like something better for music. I’d love to use FMOD, but it’s just too expensive and I haven’t found anything like it that’s significantly cheaper and also cross platform. We need something that will work on Mac/Linux/Windows as well as iOS/Android and consoles. Maybe I’m missing something obvious.

Shaders to test out material system for layers and objects – I want to use shaders to some some fancy-pantsy stuff like rippling water, depth of field, and lights, but still keeping it pixel faithful. Shaders are fun to play with.

Fix window scaling – The game window is currently hard created at 1280×720 and I want get window sizing and full screen mode working again. This was working during the Scurvy Scallywags tests, but I broke it.

Save/load system – This one scares me. If you want to do a “perfect” save game, then it’s a lot of data to save from a wide range of places and systems. The easiest thing to do is some kind of “check-point” system, but I wouldn’t be happy with that. I want to get able to quit playing at anytime and have the game perfectly restored when I load. I won’t go into all the issues that make this hard (maybe another post), but this could take a couple of weeks to get right.

Implementing a complex animation system – I want to create (or find) an animation tool that will allow for the compositing (not necessarily pixel editing) of complex animation scenes consisting of multiple images and timelines. Flash has some good tools for this, but I don’t know that it can emit the data in a way that I need and be friendly to 8-bit pixel art.


Translation system – implement the system that will pull text from data files for all the different languages. I’m going to implement it the same way we did at Humongous Entertainment and how I did for DeathSpank. It’s not hard, it will just take a week or so. The side goal is to allow “user” translations.

Talkie system – Getting actors to speak their lines, plus pull them from different language packs. Not that hard, just a lot of edge cases to handle.

August and beyond…


– Ron

Everyone Panic… Monday’s blog entry delayed until Tuesday. Mon, 06 Apr 2015 13:34:00 -0400

Today’s blog entry will be delayed until Tuesday due to me traveling. Tomorrow I’ll be talking about the schedule and road map for the engine. If there is one things that all developers agree on, it’s that scheduling is one of the most rewarding and exciting parts of the project.

– Ron

Parallax Wed, 01 Apr 2015 09:22:40 -0400

First of all, I know this is a little off topic, but I always want to spell “paralaxx” with two x’s, not two l’s.  I don’t know why, but I can’t spell for shit, so just ignore me on all spelling related issues.

Quick post today with a short video showing parallax scrolling and actor scaling.

Parallaxing creates a nice sense of depth by just having the foreground and background layers scroll at different rates. To keep things simple, I set it up so there are two foreground and two background layers. It made the code a little easier to have a fixed number, and I don’t think we’ll need more.

This also shows actor scaling, which will allow Gary to create room layouts that have some depth and dimension. Actor scaling wasn’t introduced in the SCUMM system until Monkey Island.

The foreground bushes are my crappy programer art.

Here is some code porn from the engine:

void Room::renderLayer(int layer)
    if (_images[layer]) {
                _imageParallax[layer])-(_roomScreenSize.x/2.0f), 0.0f));

Simple things excite me.

– Ron

Modernizing Mon, 30 Mar 2015 12:14:00 -0400

One of the questions I get asked a lot is how true to the classic adventures is Thimbleweed park going to be?

Maniac Mansion was filled with dead ends and death, are we going to have that? Monkey Island got rid of death and dead ends, but it was still a hard game filled with puzzles without a lot of clues.

The classic adventure games tended to push people into the deep end of the pool, sometimes with no lifeguard on duty. Are we going to do that?

How are we going to handle new and modern players? People who have never played an adventure game before? Are we going to hold their hand? Have a tutorial? IAP to buy your way past a puzzle? Is there going to be a hint system?

They are all interesting questions. We have no doubt that Thimbleweed Park will hit the hardcore adventure game players and they will like it for it’s complexity and depth, but what about the other 99% of players? The ugly fact is, most of the hardcore crowd backed the game (and thank you!), so they have already paid their money.

Our main goal is to make a great adventure game for us and our backers, but our other goal is to make enough from Thimbleweed Park that we can make another 2D point & click adventure. It might not be a sequel, maybe a whole new game and maybe with a very different art style, but it would be nice to make another.

To do that, we’re going to need to sell the game to people who didn’t back the Kickstarter or contribute to the development via PayPal and to do that, we’re going to need to appeal to (or at least not alienate) the new modern gamer.

But… we need to do that without distracting from what makes Thimbleweed Park the rebirth of a classic 2D point & click adventure game. It has to remain honest to it’s roots, ourselves and to our backers.

It’s another one of the interesting design challenges of this game.

Thimbleweed Park will not have the death and dead ends of Maniac Mansion. Those were born from ignorance more than a focused design decision. It will follow my rules of adventure game design, but we hope it will have something else, and that is clear feedback and not only clarity of goals, but also reiteration and reframing of those goals.

In Monkey Island 2, you needed to charter a ship from Kate Capsize. When you first talk to her, she gives you a wealth of information about what you need to do, why you need to do it, and how much it will cost you.

The problem is, when you go back to talk to her, she doesn’t tell you much more than the cost to charter her ship. She doesn’t allow you to ask her questions about the previous conversation or probe any deeper. If you talked to Kate, then stopped playing for a few weeks it was easy to forget what you were doing and be completely lost. 1-800-740-JEDI was your only option back then. $0.75 a minute, I might add.

I don’t believe that modern gamers want easy games, but what they do want are goals that are clear. They want to know what they should be doing and then they don’t mind if it’s hard to actually do it or figure out how to do it. They just don’t want to be lost. For an adventure game designer, you never want to hear “I have no idea what I should be doing.”

Our goal for Thimbleweed Park is to create a true classic adventure game, but we do want to learn from our mistakes and use our knowledge and experience in the same way that Monkey Island refined the design of Maniac Mansion.

For Thimbleweed Park, it’s about being clear what the player’s goals are and (and this is important) allowing players to return to conversations and probe deeper. Maybe keep track of how long it’s been since the last conversation, or if the player has visited a location, then let them ask some new questions. These questions don’t need to be about the new location, it’s just the game understanding you’ve been exploring and time has passed (you don’t want players to be able just mine conversations).

It’s not about giving away the solution, it’s about being a little clearer.

It’s also about letting players know they have accomplish something that is getting them closer to their goals and bringing the story to a conclusion. Players should feel a sense of accomplishment. They should know they are on the right track and feel good about what they are doing.

Casual games have this down to a science, but a lot of their praise and reward systems are “out of fantasy” and (for me) tend to be very patronizing, treating the player more like a child that got a gold star (sometimes literally).

We’re not going to do that, but there are some great lessons to be learned. Be clear about player goals, reiterate goals and reward for completing goals (substitute “puzzles” for “goals”).

All three of those can be accomplished completely “in fantasy”, never taking the player out of the game for an annoying pop-up, and in the end, it will make the characters and the story stronger.


– Ron

Badges? We Don’t Need No Stinkin’ Badges! Thu, 26 Mar 2015 10:54:00 -0400

One small design issues Gary and I are wrestling with is badges.

The two main characters in Thimbleweed Park, Detective Ray and Reyes, are both federal agents. As of yet, we’ve never called them FBI agents or specified what agency they work for, but they are real federal agents.

And occasionally this has posed a small adventure game design issue because they are federal agents and they have badges and guns. Why doesn’t everyone just do what they say and answering any questions they have? If they want to use the photocopy machine, can’t they just flash their badges and use it, rather than solving a puzzle chain to get a nickel? Let’s ignore the fact that it’s pre-debit-cards-1987 and why isn’t everyone carrying some pocket change around at all times. Let’s just ignore that for a moment.

Yes, Chet the survivalist out in the woods might be reluctant to let them explore his underground compound, and yes, Natalie, reporter for the Thimbleweed Nickel understands freedom of the press and isn’t going to just answer any questions they ask, or do anything they want, but if everyone responded with “Not without a warrant”, it would be highly unrealistic and, well, boring.

The sad fact is, in real life, most people will answer any question and do pretty much anything the authorities ask.

We’ve dealt with the largest of the puzzle issues that having a badge breaks, but we’re always asking ourselves: “Why don’t they just flash their badge?”

It’s an interesting problem to solve. It’s one of the things that makes this fun.

– Ron

Wireframing the Game Mon, 23 Mar 2015 11:26:00 -0400

Ron and I are now in the throes of what we call “wireframing the game”, which really is just another word for prototyping a playable walkthrough.

This is a first pass at putting in preliminary art for all the rooms and their associated puzzles, then connecting everything so we can walk through all the contiguous locations to get an idea of what the game’s really going to feel like. How long it takes to walk from one location to another and does the game give the player the right mental map of the world?

This is something we want to do fairly quickly. In the old days, with Maniac Mansion, we actually created a version on paper to give us a rudimentary feel of how everything was connected, but now we have the tools to do it all digitally.

We’ve always called these “wireframe rooms” because they just need to be laid out in flat color and composed with their most prominent necessary features in place. All the rendering detail, as well as a lot of additional window dressing (plants, non-essential objects, patterns, dither, and the like) will be added as we move into more final versions. I think we also call these ‘wireframes’ because at this point they can now actually be “wired-up” into the game engine.

Fast quick versions are good because we might not like how they feel once in the game, and we don’t want a lot of time invested. We need to be able to throw out a room and the art with no investment. We don’t want to keep a room that is wrong just because we’ve spent time on it.

Here’s a little progression on the Diner exterior and interior, doing a bit of a take on the classic 1950’s diner.  At this stage I stay with a number of basic geometric shapes: circles, rectangles, triangles, etc. As things evolve, we look at different positions for the camera, scales, and layouts, but right now I like to keep things pretty basic

When we first started working through the design back in January, I spent about a month sketching some of the more well defined game locations out on paper. Once I had a rough image I went ahead and blocked it out, trying to retain the flavor of the associated graphical approach we developed for Maniac Mansion and the rest of those first Lucasfilm games.

In those days, given the C64 character set constraints, I’d literally just block everything out with rectangles of different basic colors, a solid brown rectangle for a wall with smaller blue rectangles for windows and doors, like I was cutting it out of colored paper, then start layering details on that, window and door frames, bricks, etc. The most repetitive details at first, followed by a few unique ones to iconically reinforce location and function.

Here’s what the bathroom looks like, taking the concept to a first blocked-in pass:

Once the design process for Thimbleweed Park got underway and brainstorming began in earnest (and David Fox became involved), it really geared up the list and functionality of the ‘rooms/locations’.

As we quickly added more rooms, I stopped roughing out all but the most complex room layouts on paper and went entirely digital, cranking these out directly in Photoshop. At this point these are mostly out of my head, although I’m referring to the internet via google image search for some of the more specific and iconic details.

At the wireframe stage it’s really like looking at iconic game tokens…….Monopoly anyone?

Rooms will ultimately come in a variety of sizes, scales and potential camera angles (most likely for larger, more impressive expansive areas such as the factory and hotel lobby, etc.) .

As we get deeper into figuring all this out, I start by working my way through some of the more obvious and straight-forward locations so we can both get a feel for how things will actually work and feel in the game.

Once I’m done with the room’s wireframe, I give the art to Ron and he wires it up in the game. We might have some videos of a game walk-though in the near future.

– Gary

Your Kickstarter Dollars At Work! Fri, 20 Mar 2015 16:13:00 -0400

No ego-fueled narrated video this time, maybe next week.

For me, most of this week was taken up in getting the first pass at a game engine debugger, tweaking Wimpy, and separating the game assets from the engine code.

Up until this week, there was no debugger in the game engine other than just debugging issues with Xcode. While Xcode is a powerful debugger (so is Visual Studio, so let’s not turn this into a religious IDE war), it’s really not appropriate if you are just trying to track down an issue in the scripts. There is little need to step into the c/c++ backend code to do that, and I don’t feel a requirement of a good game programmer should be knowing c/c++ or having Xcode or Visual Studio installed.

First step was to get a debug console window running independent from Xcode (or VS if running on Windows). Any warnings or other output is redirected to this window, and there is a place to enter commands.

You can dump any variable, room or object…

And set them…

You can also execute any valid Squirrel code from the command line, so the game programmer can invoke functions or start scripts at any time. You can also read a stream of commands in from a file if you have a complex situation to set up.

This is just the first phase of the debugger, in the next few months I’ll add the ability to visually single step through code and add breakpoints. Phase two. Coming soon: an awesome toolbar.

I’ve also been making various tweaks to Wimpy to streamline the workflow. When you add an object in Wimpy, there is now an option to automatically insert the object’s code into the script file. It’s amazing how much time this saves. Add the object in Wimpy, then open up the Room’s source and just fill in the details.

Probably the biggest task this week was separating all the game assets from the Xcode project. Mac applications like all the resources embedded in the .app file. This is nice because it keeps the file system clean, but it’s not very conducive to rapidly iterating during Thimbleweed Park’s development.

As I mentioned above, I don’t want a requirement of game programmers to be the need to muck around with Xcode or Visual Studio, plus I like to think about the game engine as a very separate “product” from the game.

Much of this work was figuring out the structure and filesystem layout for the project…

I wrote a quick bash script to create new rooms. You enter new_room Diner and it creates the room’s .nut code and the .wimpy file (The files beginning with __ are the template files) and any needed folders.

From the time Gary gives me art, I can be walking around the room, clicking on objects in under 5 minutes.

The _SpriteSheet folder is built whenever art changes (from Images/) and can safely be deleted at anytime (and is not version controlled).

The other goal in separating the engine from the game assets was to have two version control repositories, so game programmers can pull down all the assets without the engine source code. All they need of the engine is the compiled program, then point it at the game assets.

I’m sure a lot of this will change as we see what works and what doesn’t. David Fox should be coming on soon and I’m sure he’ll have a lot of “feedback”.

Wimpy Mon, 16 Mar 2015 10:52:00 -0400

Welcome to the first narrated Thimbleweed Park video. Sit back end enjoy 4 minutes of my smooth sultry FM radio voice as I explain our latest tool: Wimpy.

This is the first time I’ve ever done a narrated video (for anything), so I do apologize for it being a little choppy and scattered. I’ll get better. I found it odd doing narration because I’m just talking to myself. I guess it’s one of those things you get used to the more you do it. Next time I might try it was someone else in the room, listening to me.

One of the challenges I face with doing narration is that I’m not naturally a talkative person. I like to sit and think about things, I can’t just ramble on about stuff. And I’m OK with that in my personal life, it just makes doing fun stuff like videos and twitch streams difficult, unless you like watching a video where I sit around and think about stuff.

OK, enough about me. Let’s talk about Wimpy.

Wimpy is a tool I’ve been working on for the past few days and it’s purpose is to allow game programmers to visually define the objects that appear in a room.  They can select an object, change it’s hotspot rect, use position, as well as move the image around the screen.

Up until last week, I was editing the room’s .JSON files by hand, which is fine for a few test rooms, but we’re starting to build the rough-cut and I need to be able to quickly get rooms defined and into the game. Our goal over the next few weeks is to have a completely walkable version of the world. This will allow us to walk around and see how the size and connectivity feels. Based on this, we might change how the map is connected, or add and remove rooms as needed. It’s important to do this BEFORE you’ve spent the time creating final rooms.

When I started the tool, I wasn’t sure if I wanted to built it into the game’s run-time, or as a standalone tool that used the same library as the engine, or as a native GUI app.

Building tools into the actual game can be nice. It means when you’re playing the game, you can flip it into an editor mode and change objects live. There benefits to doing tools like this, but I also feel that it can add a lot of baggage to the game’s run-time and I often find that integrated editors are harder to maintain and aren’t as slick as they can be when done stand-alone. I also like to keep the game’s run-time code as clean as possible. There are fancy-pants ways around all this, but the end goal is to build a great adventure game, not build a toolset.

The other issue with building tools into the run-time is saving data. When the room’s .JSON files are loaded into the running game, they are instantly parsed and turned into internal game structures. If the data was editable, I’d have to reconstruct the files and then save them out. The internal data structures just aren’t conducive to that.

I also looked at building Wimpy as a truly native program, which would have given me access to all the list controls, buttons, menus, etc that your used to on the OS. This was problematic for a couple of reasons.

The first is I wanted Wimpy to be cross platform. Gary, David and I all work on Macs, but we might bring someone on that works on Windows and I don’t want to maintain two versions of all the tools. I could have used wxWidgets or Qt, but I don’t know them very well and the look and feel of the UI always seems off. No matter what OS you’re running them on, it’s just slightly (or more than slightly) wrong.

So, what I decided to do was build it as a separate program, but use all my engine code so it replicated the look of the game as much as possible. For the game programmer, it’s important that they see things as close to how they will actually appear in the game. Wimpy reuses a lot of code for the room and object rendering, animation, and loading. It means if I change how objects are rendered or data is stored, Wimpy will get these changes as well.

Wimpy reads and writes the room .JSON files, as follows:

background: “bank”
name: “Bank”
sheet: “BankSheet”
objects: [
        hotspot: “{{146,114},{171,88}}”
        name: “bankClock”
        pos: “{158,101}”
        usedir: DIR_BACK
        usepos: “{159,26}”
        zsort: 88
        animations: [
                name: “state1”
                frames: [ “bank_clock1”“bank_clock2”“bank_clock3” ]
                name: “state0”
                frames: [ “bank_clock3”“bank_clock2”“bank_clock1” ]
        image: “bank_rope”
        name: “bankRope”
        pos: “{300,32}”
        prop: TRUE
        zsort: 6

I know I promised to show some actual code during this weeks update, but I think I’ll save that for another post. Just think of it as the first in the long line of broken Kickstarter promises.

OK, I lied. Here is a little bit of C++ code from the engine that loads objects:

void Room::loadObjectsFromArray(GGDictionaryArray *array)
    if (array == GGNullPtrreturn;
    for (GGDictionary *dict : *array) {
        if (dict->intForKey(“prop”) == true)
        GGString *key = dict->stringForKey(“name”);
        Object *object = Object::findObjectWithKey(key);
        if (object == GGNullPtr) {
            object = GGAutoRelease(Object::newWithDictionary(key, dict, _sheetName));
        if (object->sprite()) {

My library started out as objective-c and I converted it to C/C++ a little over a year ago. I really enjoyed objective-c’s retain/release model of memory management, so I replicated it, as well as NSDictionary and NSArray (complete with verbose method names). The stl drives me crazy.

– Ron

The Big Decisions Sat, 14 Mar 2015 20:59:00 -0400

When I asked what we could do to make this dev blog better, one of the suggestions was to talk more about the decisions Gary and I are making. The hard, tough decisions that can make or break a project. The decisions that can mean the difference between a flop and an enduring cult classic. The decisions we look back on and realize how close we came to disaster, if not for our years of experience and highly tuned design sense.

Well, today I wrestled with just such a problem, so I thought I’d share.

Tool names. Yeah, I know. Not sexy. Sorry for the dramatic build up.

I always struggle with what to name tools. I know they are just tools, tools that me and one or two other people are ever likely to see, but it’s still important to me. Tools names should reflect the character of the project or engine. Nothing is worse than an object editor called “Object Edit”.

The name and theme of the SCUMM system was a wealth of fun tool names. It was rare we couldn’t think of a good one (and one or two that were too gross to use). If the SCUMM system hadn’t been called SCUMM, I don’t know what it would be talked about today. Maybe I’m wrong about that.

SCUMM was the name of the engine, but it was also the name of the compiler, not the run-time engine like many suspect. The name of the run-time engine was SPUTM.EXE (renamed to MANIAC.EXE or MONKEY1.EXE when we shipped).

MMUCUS was the tool that crunched all the raw art and script assets into .ROO files that were packed into .LFL files when the final game was built (all the bytes were XOR’d with 0x69 to make the files virtually uncrackable – eat on that SSL).

CYST was the character and animation editor and BYLE was used to create fonts (or maybe it was the other way around, I forget).

FLEM was a GUI tool that allowed the game programmers to define objects, object states and the walk boxes. This was all before Windows, so the GUI was all hand written and very “8-bit”. Of course, back then we didn’t call it 8-bit, we called it modern, cutting-edge, and the future.

The Thimbleweed Park tool I’m working on now is our equivalent to FLEM.

Problem is: I didn’t have a name for the tool and it was driving me crazy. Yeah, I know. First world problem.

The vast library of code that I’m building our engine on is call GrumpyLib and has existed for years. It was the used in Word Spiral, The Big Big Castle, and Scurvy Scallywags. It’s not really an engine as much as it is just a bunch of cool code I use to solve problems.

My job over these first few months of Thimbleweed Park is to take all this code and build some kind of a 2D point & click engine (the easy part), but I wasn’t sure what to call the engine (the hard part).

Naming an engine is important because it sets the tone and theme for all the tools.

Based on my library of code being called GrumpyLib, I’ve decided to call the engine Grumpy and the FLEM-like tool I’m building now is called Wimpy.

I feel like I have a naming system for tools now. The project can finally begin for real.

For my Monday post, I will do a video demonstration of Wimpy and if you’re nice, I might even post some code.

– Ron

What Can We Be Doing Better? Fri, 13 Mar 2015 12:38:00 -0400

Thimbleweed Park has been cranking away for coming up on 10 weeks and we’ve blogged about the development process 30 times, getting some great feedback and suggestions in the comments. It’s been truly invaluable for us.

This is all a very odd departure for me. When making games, I’m used to tolling away in private and asking for advice, input and help from a very small group of friends. Much of that comes from me being a pretty extreme introvert. I like quiet and I like to be able to think about that I’m doing. There is a reason you don’t see me doing twitch feeds or being a clown in front of a camera.

So doing a dev blog (if the BAFTA gave out awards for dev blogs, we totally would have won one) where Gary and I post about everything that’s happening, good and bad, is pretty stressful for me (I can’t speak for Gary), but it’s also been fun and very helpful.

So… our question to you is:

What could we be doing better? What would you like to see that we’re not showing or talking about? How can we make the Thimbleweed Park dev blog more useful, more entertaining, more insightful, and more educational? What can we do better?

– Ron

P.S. We won’t reveal spoilers, so don’t ask for that.

Pass One Of Act 2 Puzzles Wed, 11 Mar 2015 15:01:00 -0400

Time for some more puzzle dependency charts. Forget Instagram and Snapchat, it’s time to start sharing your puzzle dependency chart with all your friends.  It’s the thing all the kids are talking about.

Here is a first pass at the puzzles for act 2. There are still some puzzles we haven’t figured out, so this will get a little beefier in the next few weeks, but all the core chains are there. There are a couple of puzzles that start in act 1 and don’t get finished until act 2, so that’s why there are some unconnected nodes.

There are a few more puzzle chains that happen in the factory, so the bubble at the end will get more complex, and still contain a similar feel of parallelism.

This also doesn’t include the character specific puzzle chains that only relate to the character stories, since many of those are optional unless you’re solving the epilogues.

I’m keeping the puzzle charts for the three acts separate right now, just so they are easier to edit and manage. Once act 3 is designed and charted, I’ll move everything into one big chart. It’s going to make my head hurt when that happens.

A couple of things came out of this latest brainstorm session.

The first was the length of the three acts. Should act 2 be the longest/biggest, or should that be act 1? It feels like act 2 should be longer than act 1, just for pacing reasons. Right now it feels like act 1 is bigger. That might be misleading due to the character focused puzzle chains not being part of the chart, and they will add playtime during act 2, although it is “optional”.

Act 3 should be the shortest. Players will know what they need to do by the end of act 2, so act 3 should be a nice fast paced conclusion, and you don’t want it to drag on.  Being back on Mêlée Island with LeChuck was the act 3 of Monkey Island.

It’s hard to tell the true length just based on puzzle charts, but it’s a good indication. We won’t know for sure until we start playing it, then we can adjust as needed. Add a puzzle here and there, or snip a few away.

The second thing was realizing that this story is really about the two detectives, Ray and Reyes. They are the main characters. Ransome, Delores and Franklin, although fully playable, are really supporting characters. They have great b-stories, but the game is about the detectives. There are lots of puzzles where you need to be one of the other three characters, but you will probably spend most of the time playing Ray or Reyes. They both have very different motivations and personalities and one isn’t more important or more of a lead than the other.

This is a good thing, it feels like it’s giving the theme of the story more focus, but still giving players choice and alternate avenues of exportation.

– Ron

Switching And Inventory Mon, 09 Mar 2015 10:42:00 -0400

It’s Monday again (or will be by the time I get done writing this, play some games, watch some TV, and go to bed and get some sleep), so it’s time for a new video!

The latest engine features to get checked off “the TODO list” are character switching and picking stuff up and sticking it in the inventory.

There is no UI for the character switching yet, and we don’t know exactly how we’re going to do it, but it’s completely functional. Maniac Mansion had a New Kid verb that displayed a list of the kids that you would then click on to switch. We don’t have the space for another verb, so we’re thinking of an icon in the upper corner that shows the current character and clicking on it pops down a list of icons for the other characters. We don’t want to clutter up the screen with icons and menus and other none-authentic crap , so it will take some time to visually figure this out.

The character switching UI is a good example of a task that “can wait”. The keys give us all the functionality we need to progress on the core of the game. My development philosophy is to make a quick pass at the whole game, get everything functional and then add and polish in waves. We’ll talk about this more over the next few weeks as we put together the playable storyboard version of the game.

For now, you just hit the 1, 2, 3, 4 or 5 keys (those will work in the final game as well). Whatever we do, I promise there won’t be a bouncy floating arrow above the selected character’s head and you won’t run around collecting in-game currency in the form of little floating coins or stars.

The second item checked off this week was the inventory. Characters can now can pick up objects that can be used in the construction of sentences.

Bank <-
    background = “Bank”

    … snip …

    bankFlyer =
        icon = “bank_flyer”  // Need a better way to specify this. Hack for now.
        name = “Bank Flyer”
        verbLookAt = function()
            currentActor.say(“‘Open an account TODAY and get a FREE toaster.'”)

    bankFlyerHolder =
        name = “Bank Flyers”
        flyers_left = 1
        verbLookAt = function()
            if (flyers_left) {
                currentActor.say(“It’s a stack of promotional bank flyers.”)
            } else {
                currentActor.say(“It’s empty.”)
        verbPickup = function()
            if (flyers_left) {
                flyers_left -= 1
                if (flyers_left == 0) {
                    setObjectState(bankFlyerHolder, EMPTY// pickupObject might do this by default in the future.
            } else {

    … snip …


The one thing I have left to do with the inventory is USE obj WITH obj.

I probably should have gotten USE/WITH working for the video, but I lost 3 days last week to GDC. On a side note: Brian Moriarty’s talk on LOOM™ was great and I don’t know that I’ve ever been called a SCUMMLord(™?) before.

So, Gary and I have been working on Thimbleweed Park for about 8 weeks now and the engine has made great progress, but I still go through these episodes of panic over how little time I think we have left. I have to stop myself and look at how much has happened in a very short time and that we have 16 months left. I do feel good about where we are and we’re laying a solid foundation that will (hopefully!) pay off down the road. We’re actually in a really good place right now.

Now… I’m sure the project will go to hell at some point. All projects do, it’s part of the process of making a game. I don’t think I’ve ever made a game that didn’t feel like a big giant steaming unfinishable pile of crap at some point during it’s development.

Rest assured, when Thimbleweed Park does goes to hell, we’ll blog about it, so at least you’ll get some entertainment and/or educational value out of the meltdown.

Then we’ll fix it.

But that’s a few months down the road so we’re trying to enjoying the fun part of the project while it lasts.

Beginnings are always fun, then there is the boring time, then you go though the dark period, then it becomes fun again, then super stressful, then you ship the game and you never want to see it again, then you come back to it years later and realize it was a pretty damn good game.

On one last note… please help spread the word about the Thimbleweed Park dev blog and if there is anything Gary and I can do to make it better, please let us know.

– Ron

Characters! Characters! Characters! Sun, 01 Mar 2015 11:56:00 -0500

As Ron and I work through the design and associated character story arcs, in addition to the five main playable characters, we’ve determined there are around fifty more characters that live within the confines of the Thimbleweed Park universe.

Each of these requires a written description (approximately a paragraph or more) of their function within the game, personality and some amount of backstory so we can determine how they might behave within the perspective of the story. What are their likes and dislikes? Where might they have gone to school. Did they go to school? Do they have siblings? What scares them? What makes them happy?

I also need to make sure they are visually unique, consistent and iconic enough that a player can easily recognize them as they become familiar with the cast of characters and their settings. What’s someone’s profession? How would they dress? How do they interact with the other characters?

All this drives the character’s visual design, also in case of creating this style of character (at least for me) I like to arrange everything I’ve done side by side in a single photoshop file as I create them so I can constantly compare and reference what I’ve done so far as part of an ongoing iterative process.

I also tend to use iconic items and clothing to reinforce personality and function, these can be a concept from out of my head or referenced from online. I usually use google image search and it’s interesting that an iconic representation of an item wether it’s a bottle, a phone or a pistol has pretty much remained the same over the last 50 years and that most players can immediately recognize an item even when it’s reduced to a small number of pixels (I think the media has done an amazing job of getting our brains to recognize iconic representations on a screen) .

Once a character’s front facing pose has been drawn it’s fairly straight forward to create the matching side and back views, followed by walk cycle and any special animations it requires.

There are still quite a few left to do and some of them won’t make the final cut and we’ll play with skin tones, races and sex. It’s all about exploration.

– Gary

Bonus Movie and Mr Spock Fri, 27 Feb 2015 15:01:00 -0500

First of all, I usually don’t get choked up when celebrities die. I enjoyed their work, I will miss their new work, but I didn’t know them. I feel for their families and friends, but it’s not a loss I internalize.

There have been two exceptions. The first was John Candy. I don’t know why his death hit me like it did. The second is Leonard Nimoy, which I found out about today on Twitter while I was compiling (no, really, I was compiling).

Star Trek is an indescribable part of my life. Spock really does feel like a friend. I loved Next Gen, but Star Trek will always be Kirk, Spock, Uhura, McCoy and Scotty. It’s what I watched as a kid; everyday after school. I even went to a Star Trek convention back in ’89.

This is as close as Gary and I have to something to memorialize Mr Spock. Live Long and Prosper.

Now on to the fun stuff.

Here is this week’s video, complete with animationing objects.

There are three reasons I didn’t get as much done as I wanted to this week:

1) I goofed around too much. Monday and Tuesday are just days I want back.

2) I decide to refactor a bunch of code having to do with how an object’s images are represented in the room data files. Animated objects were being kept in separate .json files and it was getting unwieldy, so I moved animated objects into the room’s .json file. They are never seen outside the room, so they can just live in there.

3) I ran into a odd Squirrel bug that took me a couple of days to figure out. It wasn’t a bug IN squirrel, more of how I was using the API (many thanks to Vincent Hamm for helping and listening to me debug and gripe on IM). There are a lot of really great things about Squirrel, documentation isn’t one of them. One thing I worry with Squirrel is that I’m really bending it to get it to do what I want and someday I’m going to break it.

The managing of object states is pretty verbose right now. As time goes on, I’ll streamline a lot of it so less scripting code is needed.

Here is the code:

Bank <-
    background = “Bank”

    enter = function()
        if (bankClock.state == OPEN) {
             playAnimation(bankClock, “state_open”)
        } else {
            playAnimation(bankClock, “state_closed”)

    exit = function()

    bankPainting =
        look_count = 0
        name = “Cheap Painting”
        verbLookAt = function()
            if (look_count == 0) { currentActor.say(“You’d think a bank could afford a better painting.”) }
            if (look_count == 1) { currentActor.say(“This looks like a knockoff.”) }
            if (look_count == 2) { currentActor.say(“I think I can see the numbers behind the paint.”) }
            if (look_count >= 3) { currentActor.say(“I’m done looking at this painting.”) }

    bankClock =
        name = “Clock”
        state = CLOSED

        verbLookAt = function()
            if (state == CLOSED) {
                currentActor.say(“It’s who cares’o clock.”)
            } else {
                currentActor.say(“It’s gears all the way down.”)

        verbOpen = function()
            if (state == OPEN) {
                currentActor.say(“That is already open.”)
            } else {
                state = OPEN
                playAnimation(bankClock, “do_open”)

        verbClose = function()
            if (state == CLOSED) {
                currentActor.say(“That is already closed.”)
            } else {
                state = CLOSED
                playAnimation(bankClock, “do_close”)

    bankToMainStreetDoor =
        name = “Door”
        verbWalkTo = function()

name: “Bank”
sheet: “BankSheet”
background: “bank”
objects: {
    bankPainting: {
        usepos: “{83,26}”
        usedir: 8
        hotspot: “{{40,120},{119,82}}”
    bankClock: {
        animations: [
                name: “do_open”
                frames: [“bank_clock1”“bank_clock2”“bank_clock3”]
                name: “do_close”
                frames: [“bank_clock3”“bank_clock2”“bank_clock1”]
                name: “state_closed”
                frames: [“bank_clock1”]
                name: “state_open”
                frames: [“bank_clock3”]
        pos: “{158,101}”
        zsort: 158
        usepos: “{161,26}”
        usedir: 8
        hotspot: “{{146,114},{171,88}}”
    bankToMainStreetDoor: {
        usepos: “{17,11}”
        usedir: 2
        hotspot: “{{0,125},{12,0}}”
props: {
    bankRope: {
        image: “bank_rope”
        pos: “{300,32}”
        zsort: 6

– Ron

Brainstorming Like It’s 1987 Tue, 24 Feb 2015 16:00:00 -0500

Last week Ron, Gary, and I spent two days together brainstorming Act 1 of Thimbleweed Park. I knew I was going to have fun, and wasn’t disappointed. Just like old times, except it was at Gary’s office in the Santa Cruz area instead of a Skywalk Ranch conference room. But the coffee drinks were way better. I don’t think they invented coffee drinks yet in the 1980s, at least not at the Ranch. (My new favorite, Soy Mocha Chai Latte. Almost as good as Hot Butterbeer from the Wizarding World of Harry Potter.)

The first step was for me to wrap my head around the game. Having been reading the Thimbleweed blog posts from the beginning helped a bit, but the overview design docs that Ron and Gary sent to me before our meetings really got me going. From a “character bible” with a paragraph or two on each of the “actors” (lots of backstory that may never make it into the game but really helps us write dialog), to the puzzle and location maps, magically unblurred from the versions you all have seen. But there were lots of gaps in my understanding, so for the first hour Ron and Gary walked me through the game, and I asked all the questions I had saved up.

Besides coffee and a big whiteboard, what else is needed for a successful brainstorming? I’ve been thinking about that for the past few days. There’s definitely a mental mode brainstormers want to enter, but which you can’t just turn on… So you have to prime the pump.

We started by drawing the game’s map with all the locations, describing what the player has to accomplish by the end of Act 1, and listing what objects would be needed to get the player to that point. We then stepped back to see if it would be any fun playing through. When we noticed that we had too many puzzles where you could buy something at one location and use it somewhere else, we pushed our creativity buttons and came up with much more interesting solutions (unlike in Zak McKracken, there are no Thimbleweed pawn shops where you can stock up on a dozen needed items in this game!).

This felt very methodical at first, but then the magic began. We saw patterns that we liked and amplified them, ending up with some great running gags. We came up with crazy ideas that made us all laugh out loud (some of which may make it in the game). We didn’t care if our suggestions would be stupid… no need to pre-filter at this point, just get them all out and see which ones connect and feel right. Then we entered that unfettered mindlinked state where more than one of us had the same idea at the same time… it didn’t make any difference which one vocalized it, it just had to get up on that white board.

By the end of Day 2, we felt really good about our progress. The game was coming alive, and we could picture ourselves playing through and having a blast. Can’t wait to start scripting!

– David

More Maps and Puzzles Mon, 23 Feb 2015 10:04:00 -0500

It’s Monday so it’s time for a big fat meaty Thimbleweed Park dev blog update and for today’s action packed episode we’re going to dive into maps and puzzle dependency charts. These map and puzzle chart refinements are the result of the two-day brainstorm Gary, David and I had last week. I’ve blurred out anything that could be a spoiler.

First up is a map of the world. We had much of the map figured out for this post, but as the puzzles become more solidified, the map can change with a whirl of additions and deletions. We might come up with a location that sounds fun, but later realize it serves no real purpose so we remove it. The room stays on a list and might come back, but only if we find a good use for it.

Cutting stuff is almost as important as adding stuff. Every room in the game should have a purpose. Most of the time that purpose is to find an object or solve a puzzle. Sometimes rooms exist just as a home to a character needed for story reasons, but that is usually coupled with a puzzle, but not always. Rooms can exist to help define the world, maybe it’s an establishing shot or an overlook to help players understand where they are, or to set a mood.

If the room is just something to be traveled through, it should be cut. If the room only has one small purpose, also consider cutting it.

One of my pet-peeves with “director’s cuts” of movies is that a lot of those scenes should have been cut and were initially cut for a reason, only to be brought back by marketing departments to sell more DVDs.

Of all the rooms that were cut from Maniac Mansion, Monkey Island, the Humongous games (or most anything I’ve done), I can only remember a few that were cut because we ran out of time. Most were cut because it made the game tighter and better. Sometimes I’ve resisted cutting, fought and argued against the cut, only later to find the game better for the loss. Don’t be afraid to cut. Cut, cut, cut.

As a perpetual warning to readers of this dev blog: don’t get too attached to anything you see here. A lot is going to change over the next 18 (I guess it’s 16 now!) months. It’s part of the process. Cut, cut, cut.

Next up is the puzzle dependency chart. This looks quite different from the one posted a few weeks ago, mostly because this dependency chart is just Act I, where the other was a small chunk of puzzles from all the acts. The first chart was getting a little unruly, so I started over and began building from the beginning.

I’m really happy with the shape of this chart and by shape I really do mean the shape of it. It has that much sought after diamond shape, starting small, branching out and then pulling in. It means players aren’t going to be overwhelmed at the start, then they have multiple puzzles to solve in parallel, then everything pulls and focuses in at the end.

There are a few puzzles not shown on this chart that players will start solving in Act I and not complete until Act II or Act III. There aren’t a lot of them, but a few are needed so players can have nice epiphany moments with characters, puzzles or objects they found hours or days ago.

I would estimate this chart represents a little more than a third of the game. Act II should be a little bigger, Act III will be about half this, then the character epilogues (which shouldn’t be very long).

Also, this puzzle chart contains three nodes labeled “Ransome Flashback”, “Delores Flashback” and “Franklin Flashback”. These nodes are the playable flashbacks and consist of small self-contained little adventure games, complete with their own puzzle charts (not shown). Each of the flashback adventures should take about 15 minutes to play and help set up the characters and their backstories. We wanted to do them as “playable” so players didn’t have to watch long cut-scenes.

I firmly believe players shouldn’t lose control for more than 10 or 15 seconds, maybe 30 at the most (and rarely). Adventure game stories should be played. If I wanted to watch a story, I’ll watch a movie, they do a much better job of it.

Last week I focused on design and didn’t even crack open Xcode.  This week is going to be non-stop programming and the week after is kind-of screwed due to GDC. I mean “screwed” in the good sense. GDC is a lot of fun.

– Ron

Missed the Kickstarter? Fri, 20 Feb 2015 21:16:00 -0500

If you missed the Kickstarter and are looking for a way to support us, we’ve just added several new options using PayPal and Humble Bundle.

CLICK HERE or use the handy Support Us link at the top. Either one is fine, they both go to the same place.

– Ron

UI in Action Tue, 17 Feb 2015 10:45:00 -0500

Another week and another stunning professionally produced gameplay video, this one of the first pass at the verb UI.

My goal last week was not only to get the UI working, but also the hooks from Squirrel into the engine so when verbs and objects were clicked on, everything flows correctly and wasn’t just kludged up.

Astute readers will note the interface works more like Monkey Island than Maniac Mansion, and that is a good thing. Maniac Mansion was a first pass at the verb-based point & click UI and it was clunky. Monkey Island introduced (or maybe it was Last Crusade) scanning around the screen and the “sentence line” autoupdating. In Maniac Mansion, you had to select a “what is” verb. It also required a double-click to execute sentences. What were we thinking?

On the programming side, I was having some issues with how Squirrel handled classes, so I ditched the notion of rooms being classes and just made them simple tables/dictionaries. It works a lot better since I don’t really need full-on classes for the rooms. There will only be one of each and they never get destroyed once created.

It also allowed me to get rid of the object { } table that enclosed all the room’s objects. It was an unnecessary scope due the c code’s inability to cleanly iterate through Squirrel classes. There was probably a way around it, but less is more and I like this better and it’s all about me.

It could be argued you might want to create a base room class and derive from that, especially in the case of generic rooms like the forest in Monkey Island and the hotel in Thimbleweed Park, but endless class deriving and polymorphism is a pit of pain and eye poking. Object oriented programing (or OOP we pros call it) can make you feel very clever, but sometimes it feels like it’s being used just because it makes you feel very clever.

I’m sure this will all change dramatically over the next few months. Stay tuned!

Here is the scripting code the runs the video above

TestStreet <-
    background = “TestStreet”
    enter = function()
        print(“Entering TestStreet”)
    exit = function()
    TestStreetToBankDoor =
        name = “Bank Door”
        walkTo = function()

Bank <-
    background = “Bank”

    function threadTest()
        while(1) {

    // Called when the room is entered, after objects are inited.
    enter = function()
        print(“Entering Bank”)
        // This thread needs to be killed when leaving the room. Need to figure out a way to make that happen automatically.

    // Called when exiting, before new room enter code
    exit = function()

    bankPainting =
        look_count = 0
        name = “Cheap Painting”
        lookAt = function()
            if (look_count == 0) { currentActor.say(“You’d think a bank could afford a better painting.”) }
            if (look_count == 1) { currentActor.say(“This looks like a knockoff.”) }
            if (look_count == 2) { currentActor.say(“I think I can see the numbers behind the paint.”) }
            if (look_count >= 3) { currentActor.say(“I’m done looking at this painting.”) }

    bankClock =
        name = “Clock”
        lookAt = function()
            currentActor.say(“It’s who cares’o clock.”)

    bankToMainStreetDoor =
        name = “Door”
        quickExit = true    // Actor exits before fully reaching the door
        walkTo = function()

// All rooms must be loaded before they can be referenced.

// Create detective
detective <- Actor(“DetectiveFemaleWalk”)
detective.talkColors(0x45a3ff0x173450)    // text + outline colors

// Make her the selected character

// Put her inside the Bank at the front door

One issue I have yet to solve is a simple and slick way to do different dialog for different characters.

if (look_count == 0) { currentActor.say(“You’d think a bank could afford a better painting.”) }
if (look_count == 1) { currentActor.say(“This looks like a knockoff.”) }
if (look_count == 2) { currentActor.say(“I think I can see the numbers behind the paint.”) }
if (look_count >= 3) { currentActor.say(“I’m done looking at this painting.”) }

For a lot of lines, everyone can say the same thing, but we’re going to want enough variation to give the characters personality.  In reality (pro tip), you don’t need that many character specific lines. The characters in Maniac Mansion basically react the same to 95% of everything the player does, but it’s that 5% that stands out. That 5% feels like 75%. It’s about picking and choose the custom replies and making them count.

I could so this…

if (selectedActor == DetectiveRay) {
    if (look_count == 0) { currentActor.say(“You’d think a bank could afford a better painting.”) }
    if (look_count == 1) { currentActor.say(“This looks like a knockoff.”) }
    if (look_count == 2) { currentActor.say(“I think I can see the numbers behind the paint.”) }
    if (look_count >= 3) { currentActor.say(“I’m done looking at this painting.”) }
if (selectedActor == Ransome) {
    // etc

But that’s going to get real tedious real fast. I need to figure something out.

The other issue I need to deal with is fonts. Right now the C64 font is a truetype font and truetype fonts want to render smooth and antialiased. It works most of the time, but with certain sizes it looks odd. I may end up doing a true bitmap texture atlas based font once all the sizes have settled down, but that’s months down the road.

And in conclusion, I leave you with a time lapse of getting the UI working…

– Ron

Monday Updated Pushed To Tomorrow. Mon, 16 Feb 2015 11:50:00 -0500

The Monday Thimbleweed Park update will be delayed until tomorrow morning due to the long weekend.

While you wait, please check out the new Thimbleweed Park FAQ for all you questions and answers.

– Ron

Quickie Bathroom Wed, 11 Feb 2015 14:42:00 -0500

Gary is out sick today so he couldn’t write anything about his latest concept art.

I hear this is the only bathroom in all of Thimbleweed County. That would be just like an adventure game, wouldn’t it?

Adventure games can be weird with the rarity of what would be common items in the real world. Back when I was working on Monkey Island, I remember playing a “competitor’s” adventure game and there was a puzzle where you needed a pencil. My character was in LA and the only pencil in the game was back in New York. I had to get on a plane and fly across the country to get it.

– Ron

Maps and Puzzles Mon, 09 Feb 2015 09:56:00 -0500

I spent much of last week working on the Thimbleweed Park design, so not a lot happened in the code. Gary and I spent the time putting together the map of the world showing all the locations, or “rooms” as we call them.

I’m not sure why the term “room” crept into my lexicon for describing locations in adventure games. I don’t know if it was because Maniac Mansion took place in the mansion, so it was natural to describe them as rooms, or if the term originated in early text adventures. SCUMM called them rooms and many of the commands used that word and it’s just stuck.

As we’ve been putting together the puzzles and story, Gary and I have been keeping a big list of all the rooms in the game, but last week we finally put them together in map and starting making all the connections. Having a list of rooms is one thing, but when you see them all connected together, your brain (or at least mine) can start building an image of the world. Seeing them all connected together also points out problems with bunching or choke points.

An adventure game world should open up like an onion (well, an inside-out onion). As players solve puzzles they get access to more and more of the ever expanding world. It’s good for dramatic reasons, but also helps with focus and making sure they aren’t overwhelmed with too many choices too early.

Maniac Mansion had 36 explorable rooms, plus another 5 or 6 rooms for things like the title screen or the talk show set. Monkey Island had around 70 explorable rooms and another 15 or so close-ups, title screens, etc.

We’ve always thought about Thimbleweed Park being Monkey Island size in terms of the world, so we’re shooting for 100 rooms and will probably come in at around 80 or 90. It’s hard to tell at this stage. With Maniac Mansion and Monkey island, disk space was our number one limiter of size and with Thimbleweed Park, that’s close to a non-issue. Our limiting factor will be the work involved in drawing and implement the rooms.

The map below includes all the major locations, and some will grow by 5 or 6 rooms. For example, Delores’ Mansion is 3 rooms on the map, but it will end up being closer to 8 or 10.  The pillow factory is another that will expand dramatically, as well as the circus and the hotel.

Now that we have a map, we’ll start the process of adding, removing and editing. Some of these rooms won’t make it into the final game because they’ll end up being redundant, uninteresting, or the puzzle required for their existence was cut.

Please note: as with anything you see on this dev blog, don’t become to attached.

It’s also important to remember that these “rooms” scroll, so they can be, and often are, more than one screen wide.

We’ve also done a few passes on the puzzle dependency chart. This is far from done, so it represents maybe 25% of the game. There are several disconnected nodes that will get hooked up as we figure out bridging puzzles and that will change the look and flow quite a bit over the next few weeks.

Enjoy! My plan for next week is to have the core UI working, including verbs, and probably room transitions, and Gary’s plan is more concept art while we both noodle away at puzzles.

Town Building Concepts Wed, 04 Feb 2015 20:30:00 -0500

As we begin to flesh out the visual locations in the town, we need to design each store front, other buildings and the exterior features of the town. Additionally, the architectural styles need to be consistent to one another while conveying an iconic representation players can easily relate to.

I start out with a building’s basic shape – and research a number of images in a particular style on line – in this case  stereotypical small town American businesses. I’ll start roughing out a basic building shape in blue pencil and felt pen. Then render more shading based on it’s construction materials, is it made of wood, brick, glass? How many windows? What’s the aesthetic? What’s the function?

Once I have an image that evokes the feel, I’ll go back in and add the appropriate window dressing , signage and other details. Finally I’ll go back in and add more appropriate typography, logos and associated sight gags when I execute a more final digital render.

We’re still early in the design process, so we don’t know if all these will make it into the final game, but it helps spur ideas.



– Gary

Scrolling Rooms Mon, 02 Feb 2015 11:08:00 -0500

Another Thimbleweed Monday and time for a new video and some source code.

I spent last week working on getting rooms implemented and it closely follows how they were set up in SCUMM.  In SCUMM I had the luxury of writing my own compiler, so I could customize the syntax to my liking.

Since we’re using Squirrel for Thimbleweed Park, I needed to figure how to do something similar, yet retain what I liked about how rooms were set up in SCUMM. I’ve come pretty close, and I might make some small changes to the Squirrel compiler to make the syntax a little clearer. By and large, it’s working quite well.

There is probably a better way to do all this, but this is a trip down memory lane for me as well, so I wanted to have it be as close as I could to making a classic SCUMM game. I even pulled up the original Maniac Mansion SCUMM engine source code to see how it handled the camera.

Cameras are always something you spend the entire project tweaking and I spent an afternoon working on it, trying to get it to feel right. I’m not 100% sold yet. This camera drifts a little too much and could use a slight acceleration when it starts moving. The camera in the early SCUMM games are pretty crude. Everything had to scroll on 8-pixel boundaries due to the C64 character set and then later on due to the compression we used in the PC. We could have jumped through some hoops to get it working, but performance was a huge issue and we were pushing it as it was.

There is no pathfinding at the moment (it relies on the honor system) and I’m not sure how I’m going to implement it. I could do an old SCUMM style walk-box system, or maybe bitmap based with A*. I probably won’t get to pathfinding for a month, it’s not critical at this point.

The video is driven by the script below with minimal hand waving.

class Bank
    background = “Bank”  // the data file to load (Bank.json)

    // Called when the room is entered, after objects are inited.
    enter = function()

    // Called when exiting, before objects are destroyed and new room’s enter code is run
    exit = function()

    objects =
        bankPainting =
            name = “Cheap Painting”
            lookAt = function()
                currentActor.say(“I’d think a bank could afford a better painting.”)    // .say() not working yet

        bankToMainStreetDoor =
            name = “Door”
            quickExit = true    // Actor exits before fully reaching the door
            walkTo = function()


detective <- Actor(“DetectiveFemaleWalk”),10)


One thing you’ll notice is there are raw strings in the source code and for translation reasons this is a really bad idea. I’ll do a full post in a few months talking about strings, rapid development, translations and how we’re going to handle it. Until then, hold your eye rolling and self-righteous distain.

In addition to the above source code, each room has an additional file that defines it’s visual characteristics, including images, hotspots, and walk areas.  The files are in JSON format, which I find amusing since JSON was created by Doug Crockford, who Gary and I worked with at Lucasfilm and he produced the NES port of Maniac Mansion. In addition to JSON being a great data format, it’s my little thanks and nod to Doug.

Right now I edit these files by hand, but I’ll be writing a GUI editor in April that will allow the game programmers and artists to define everything visually. The editor will read and write these files as I find it very convenient to have editor data files in a format that I can bring into a text editor and made big changes or massive find/replaces. Sometimes the best tool for the job is notepad.

name: “Bank”
background: “Bank”
objects: {
    bankPainting: {
        usepos: “{83,26}”
        usedir: FACE_BACK
        hotspot: “{{40,120},{119,82}}”
    bankMainStreetDoor: {
        usepos: “{25,10}”
        hotspot: “{{0,10},{20,120}}”
        cursor: CURSOR_EXIT_LEFT
props: {
    bankRope: {
        image: “BankRope”
        pos: “{300,32}”
        zsort: 6

Some of you may have noticed this isn’t valid JSON. I wrote my own JSON parser for Scurvy Scallywags that can read compliant JSON, but also relaxes some of the rules just a little. Key’s don’t need to be in quotes if they are made from alpha+digits, commas are optional if they are not syntactically confusing, and the opening “{” is optional as the file is assumed to be a dictionary. Small changes, but I find them convenient.

There might not be a new video next Monday since I’m going to be gone for two days (family stuff) and then focusing on the design and getting ready for the “Big Brainstorm” with David Fox.

But the week after that, I plan on having a first pass at the UI, selecting verbs, building sentences and clicking on objects.

It really is 1987 all over again. In a whole lot of ways.

– Ron

Not A Postmortem Sun, 01 Feb 2015 11:41:00 -0500

It’s important to keep in mind that the Thimbleweed Park blog is not a postmortem.  We’re posting stuff as we think of it and as we try it out. It’s not vetted or the product of a carefully thought out decision. It’s just stuff we’re thinking of.

As with any project, much of it will be wrong, not always 100% wrong, but wrong and we’ll adjust it. That’s part of the process. This goes not only for the design and art, but also the tech.  You try things and then you adjust.

It’s easy to look at game like Maniac Mansion, Monkey Island, or insert your favorite game here and imagine it came out fully formed. It’s not the way creativity works. I’ve seen “design documents” online for shipped games that I know were the product of revisions and adjustments throughout development. They do not represent what the design doc looked like when the project was started, they are the design doc when the game finished.

Publishers often require a design doc always be kept “up to date”, and that is a good thing, but it’s easy to lose where everything came from. It’s important to remember how screwed up everything was at the beginning. It’s normal. It’s good.

What you’re going to see on this blog is the process from crappy idea through (hopefully) a fun game.

Please keep that in mind when you see our crappy ideas (or our good ideas that never make it into the game).

– Ron

Pigeon Brothers Fri, 30 Jan 2015 11:11:00 -0500

Regarding concept sketches in general: When Ron and I come up with an idea that we need to visualize, it may require some research – I.E. I may not know what a particle accelerator looks like off the top of my head – and the internet is a wonderful resource (I used to have to physically go to the library and look stuff up).

However in many cases I just quickly visualize and sketch  things out of my head so we can get a fast idea of what something might look like, especially if we’re including some sort of sight gag. “Is this actually funny?” “Really?”.

A lot of the concept art we’ll be posting are quick concepts, just to get our brains kick started. We’re not married to anything we might come up with on the spur of the moment – however, sometimes the first quick pass can be the right direction.

Gypsy Store Concept Thu, 29 Jan 2015 12:31:00 -0500

Taming the Design Tue, 27 Jan 2015 18:16:00 -0500

“Pillows made America great! Pillows helped win the war!” – Uncle Chuck

Gary and I did a daylong brainstorm session yesterday with the objective of taming the design.

The problem is we had too many ideas bouncing all over the place. We had the core of the story figured out pre-Kickstarter, but all the loose threads never really came together into a unifying theme. We’d come up with good puzzles, but they didn’t feel like they were supporting the story. They were just fun puzzles.

We started by listing all five playable characters and asking ourselves “What is their story? Why are they here and what do they really want?” They can all want different things, but they have to be related and come together to make one larger and stronger story. From a puzzle standpoint, it also helps if they are all driving towards the same goal, even if for different reasons.

It was time to strip everything away and rebuild it.

The pillow factory has always played a crucial role in the main story’s climax, so we started by asking “Why do each of the playable characters want to get into the abandoned pillow factory?” If we gave them all the same puzzle objective, they (and the player) can be working towards the same goal. Each character is looking for something different, but it all leads to the pillow factory.  In Maniac Mansion, all the kids were there to find Sandy, so the player focus was the same.

The other issue we faced were the two detectives. We hadn’t fully fleshed out their stories or personalities. They were there to solve the murder, but we didn’t really know who they were beyond a simple paragraph.

We wanted to make them different, not just male and female carbon copies of each other. They needed to have very different goals and deal with situations differently. We also felt it would be more interesting if they were working together, but also at odds, maybe some deep mistrust. Doing that would heighten the mystery of what was going on in Thimbleweed Park.

So we wrote all our ideas on two whiteboards and started to talk through everything. We’d have an idea that made sense for a while, then we’d abandon it in favor of a better one. It was a day of bouncing between “we’re screwed”, “this is genius”, “we’re screwed”, “this is genius”, goto 10.

The end result was we could talk through the story from beginning to end. We had five (six if you include the murder) different stories that all came together, then briefly separated for the epilogue.  All five stories are serving the same overarching theme, yet have their own little “moral” and meaning for the character.

This morning I set out to write it all down as a linear narrative, much like a walk-through (hyphen? no hyphen?). If we didn’t know the details of a puzzle or location, I’d write something like “You need to make the phone ring (TBD) so the hotel clerk leaves his desk”.  Seven pages later, it was all down and it all made sense and fit together better than it seemed to the end of the day yesterday.

The document is filled with (TBD), but now it’s just a matter of filling those in over the next few months.

And lots of puzzle dependency charts.

* None of this is written in stone, any of it could change, names and locations are just temp brainstorm, so don’t get too attached to it. By the time the game ships it will be a space shooter.

We’re Walking And We’re Walking Sun, 25 Jan 2015 20:54:00 -0500

Don’t be misled by this video looking like a nearly finished point & click adventure game, there is still a lot of work to do. TODO: Insert smiley face.

My goal last week was to get the foundation of the Actor system in and working. Second only to the Room class, it is one of the workhorses of the engine and will drive the movement and animation of every character in the game.

Here is the Squirrel code…

// Called when the player clicks
function clickedAt(x,y)

detective <- Actor(“DetectiveFemale”),50);

Obviously there is a lot going on behind the scenes in the c code of the Actor class.

Being able to display and manage images is something that’s been in my engine since day one, but for Thimbleweed Park we need to be able to play animations that are more than just cycling through frames. The Actor class has to manage not only walking, but reaches, gestures and various special animations. It needs to understand the direction the actor is facing and if they are talking, so all the game scripter needs to do say something like…


…and everything else is handled for her. This class got a lot of use (and overuse) in the SCUMM system. If anything had more than a two-state animation it became an actor, even if was a smashing crate, a boulder or a swinging rope.

Last week, Gary and I started looking at tools that would work well with 2D bitmap graphics and could also do layers that could be turned on and off at runtime.

Of all the suggestions we got (thank you for those), Aseprite seemed like a good choice, so we spent last week putting it through it’s paces. We also built some of the animations purely in Photoshop to get a feel of that process and we’ll probably use a combination of the two, with larger (in pixels) and simpler animations just using Photoshop.

Art pipeline has always been important to me, mostly because I’m lazy. I don’t want to have to hand export animations when they change, I like to be able to type ‘’ and have it go though all the art and animations files, convert anything that changed and build spritesheets.  Once you start doing stuff by hand, you introduce the human element. I like just pushing a button. More time to read Twitter.

So part of last weeks exploration was getting that process figured out. Aseprite has a nice command line tool that will pull animation apart files and dump the frames and layers into a folder, then my script invokes TexturePacker and out come packed spritesheetswith duplicate frames removed.

If we find another editor we like (or an artist has tool they feel more comfortable working in), and the file format can be pulled apart by the munge script, it should work in our pipeline. Although, there are benefits to standardizing tools, so we can’t go crazy, but the flexibility is good and other reason game code shouldn’t read editor formats directly. Always try and use a run-time format that can be converted to from multiple sources.  The exceptions are very standardized formats like .png or .jpg.


After getting the engine to load the animations, the next step was playing them while taking into account the direction the actor was facing. I wrote some hacked code to respond to the arrow keys and spacebar to change direction and start and stop walking. Everything was coming together swimmingly.

Now I just need to get someone walking around the screen.  Another quick hack and I’d call the walkTo() function when the mouse was clicked.

My first thought after seeing the result was, “Hey, this is amazing!”. That was followed by, “Hey, something is wrong. This doesn’t feel right.”

I spent a good 10 minutes clicking around the screen watching her move. Something was wrong. It didn’t feel like the old SCUMM games.

Time to power up SCUMMVM and take a look at Maniac Mansion.

It hit me after the first click. SCUMM actors move twice as far in the horizontal than in the vertical. It gives the actor’s movement this fake sense of perspective.

I went back and changed my code to look at the primary axis of movement, set the actor’s speed based on that and then adjust the step distance of the other axis accordingly. I timed how long it took Dave to walk from one side of the screen to the other, then adjusted the detective’s walk accordingly. I don’t remember if Gary and I spent any time tinkering with the walk speed of the Maniac Mansion characters, but it feels good.

The other issue is that my code does most of the internal calculations in floating point (just as fast as an int in 2015, pure witchcraft in 1987), so the detective moves very smoothly, often stopping on sub-pixels. Modern hardware makes this easy and it looks really slick, but it lacks “authenticity”. It’s was an easy fix, but I might turn it into a user selectable option in the final game.

So there you go… another Thimbleweed Park weekly milestone checked off.

Next week Gary and I are going to focus on game design, but I also want to get started on the Room structure and setting up objects.  After that, I’ll move onto getting a first pass of the verb UI.  By the end of Feb, I hope to have a mini playable adventure game all driven by scripting.

It is strange how much of this process reminds me of getting SCUMM up and running the first time.

Scripting Test Tue, 20 Jan 2015 12:10:00 -0500

This might not seem very impressive, but it represents a major milestone in Thimbleweed Park. If you’re not impressed, at least pretend you are. My feelings get hurt pretty easy.

I’m looking at using Squirrel as the scripting language for Thimbleweed Park and one of the things I always liked about SCUMM was how it handled multi-tasking. It was effortless to run scripts in different threads and let objects handle themselves without cumbersome state engines or weird co-routines.

I just want to start a function and have it run until told otherwise. I’ve seen a few scripting languages that can do this, but Squirrel didn’t have the ability “out of the box”.

I was chatting with my friend Vincent Hamm (who worked on SCUMMVM in the early days) and he didn’t think it would be too hard, so he whipped up a quick proof of concept.

The true test of a game scripting language is being able to do powerful things with very little code.

I spent the few days last week getting his code integrated into my engine and started to implement all the bindings between Squirrel and my code.

I wrote the following Squire code that drives the video above.

function bounceImage(imageName)
    local image = Image(“GameSheet”, imageName);

    local x = random(01280);
    local y = random(0720);

        local steps = random(100.0,150.0);

        local end_x = random(01280);
        local end_y = random(0720);

        local dx = (end_x – x) / steps;
        local dy = (end_y – y) / steps;

        for (local i = 0; i < steps; i++)
            x += dx;
            y += dy;

  , y);

for (local count = 1; count <= 10; count++)
    startthread(bounceImage, “Detective1”);

for (local count = 1; count <= 10; count++)
    startthread(bounceImage, “Detective2”);

Over the weekend, I started to create the structure of a “room” and figuring out how the scripting will interact with all the objects, characters and verbs. I should have that working by the end of the week and will do another post with some more glorious code. I know everyone lives to see source code.

There is still a long ways to go before it looks like an adventure game, but believe it or not, this is a big step forward. It’s pretty much just polish from here on out.

– Ron

Thinking About Locations and Characters Mon, 19 Jan 2015 12:46:00 -0500

Although we’ve pretty well established our approach to the game’s visual style, the first few months of design and development has a lot to do with figuring out how things will actually look and work within those constraints.

Aside from basing a location’s look on a real-life counterpart, the design of its’ specific puzzles and their place in the story really drives a location’s visual design. In some cases we already know we need an important puzzle that does X, and we’re designing a location around that, or we’ve decided on a location and need to come up with a good reason for it.

As we create locations and associated characters, it’s important that each have their own peculiar aspect. We tend to begin with a very stereotypical/iconic concept approach to the design then try to layer on an appropriate unique twist. That way the player starts out with image they can easily identify with and understand… “I recognize that’s a clown, but I don’t know why he’s carrying a pineapple that has a steering wheel attached to it…”

The above is an early animation test, back when we were being more faithful to the C64 palette and everyone looked orange. One of the main reasons we decided to relax our palette constraints is to be able to have more realistic and varied skin tones.

Although we’ll be spending a lot of time in the near term working primarily on static images, we’re also starting to think about animation as well.

We’re beginning to look at 2D animation tools that run on the Mac (both Ron and I work on Macs), I’d like to find something that supports a good old-school style bitmap approach (as opposed to Flash), that might have similarity to the kind tools we used on Maniac Mansion and Monkey Island. When working on Maniac Mansion, I animated on the C64 using an in-house tool called Skedit.  By the time Monkey Island came about, we were using DPaint Animator.

Any new editor should have layers, reasonable drawing tools and be able to save into an easily parseable file format. So far we’re haven’t found anything we like, so if anyone can recommend a good 2D animation program that runs on the Mac, please let us know.

– Gary

Linux Thu, 15 Jan 2015 11:38:00 -0500

What flavor of desktop Linux should I use for the initial port of Thimbleweed Park?  I realize this is like asking what religion is the right one, and in some ways it might even be a thornier and more contentious issue, but I am fearless in the face of controversy. I ask the questions everyone else is afraid to ask.

I use CMake to generate the Xcode and VS projects, so what IDE should I use on Linux?  Or just have CMake build make files on Linux?  I tend to spend 99% of my time on the Mac in Xcode, switching to Windows just to do a build or for compatibility issues. Windows and Linux won’t be platforms I do a lot of core work on.

I’m currently using SDL for window creation and input and I don’t see any reason to switch. It runs on Linux and works pretty well on the Mac and Windows. I don’t use any of SDL’s rendering, I only use it to create the windows and then get a context back and do everything in OpenGL/DX from that point on.

OK, that’s a lie. I do use their font lib because I don’t want to write font rendering code. Every OS seems to do it different, and it’s nice to have it consistent across devices.

I’m no stranger to Linux as I run Ubuntu on all my servers, but those are all headless machines I SSH into and I’ve only dabbled in the desk top a few times.

I’l probably run it as VM on my Mac using Parallels, at last for a while, then I’ll get a dedicated machine.

I figure it might be better to get the core of my engine running on Linux early on.

– Ron

Story Layout Mon, 12 Jan 2015 17:25:00 -0500

Thanks for all the feedback in the last post about replayability. Bucking the trend of Internet comments, it was all very interesting and insightful.

A couple of people mentioned the dead-ends in Maniac Mansion, and I want to reiterate what Gary and I said in several interviews: There will be no dead-ends.  The design of Thimbleweed Park will follow my rules of adventure game design, formulated after Maniac Mansion and before Monkey Island. Dead-ends in adventure games are the product of bad game design, nothing more. IMHO.

So, our goal is to have different endings, but not require players to replay the game (or play meta-games with save games) to see them.  I agree with some of the commenters that people don’t have the time or patience these days to replay a game to get different endings. The Stanley Parable took a very novel approach to this, but that whole game was very meta, so it worked in a way that won’t for Thimbleweed Park.

One difference between Thimbleweed Park and Maniac Mansion (and The Cave), was that in Maniac Mansion (or The Cave), you picked the characters you wanted to play with before the game started. In Thimbleweed Park, you are always playing with 5 characters. You don’t get to choose to be Ransome the Clown. You do get to choose how much you play with him and how much of his story you explore, but he and the other characters are not optional.

Please keep in mind that this is just what we’re currently exploring. It might change as we flesh things out over the next few months.

When the game starts, you will be able to switch between the two detectives, but you won’t know about Ransome, Delores or Franklin yet.  There will be a small 3 or 4 room intro that sets up the story and allows players to get used to and explore the interface (there will be no tutorial, but more on that in another post, so hold your rage/support).

On to the good bits…

Once you get into the town and start investigating the dead body, you will meet characters who will tell you about Ransome, Delores and Franklin, and when they do, you will play a short flashback that sets up their stories.  When each flashback is complete, you can switch to them at will.

The main story is broken up into 3 acts, with the final act triggering the ending of the main story.  Putting it in globally understood Star Wars terms: blowing up the Death Star was act 3, the medal ceremony was the ending.

Each of the 5 characters have their own sub-stories consisting of 3 acts. Character first acts are told through the flashback, the character’s second act is required as the puzzles are intertwined with the main story’s second act, but the character’s 3rd act is optional. You can choose to play them or not.

Also, the acts are not linear, you will have to switch to other characters to complete puzzles, so it’s not like players will be able to play all of Delores, then switch to Franklin and play all of his story. Like any good adventure game or story, it’s all intertwined, related and connected.

When the main story ends, there will be a satisfying ending, discovery of the killer, justice, closure and all that, but you can keep playing. If you haven’t completed all the character stories, you can go back and do those. Once they are all done, you will move into a small playable epilogue that ties everything together.

I know it seem complex, but once you’re in and playing, it should feel fairly natural.

Please keep in mind that we’re still brainstorming and exploring ideas. This is part of the messy screwed up process that is game design and making stuff. Sometimes things work, sometimes they don’t and you change them and pretend like it never happened.

– Ron

Maniac Mansion, The Cave and Thimbleweed Park Thu, 08 Jan 2015 10:59:00 -0500

The main criticism I heard about The Cave was the repetition of playing multiple times to get all the endings.  Each character had their own story and to see all 7 stories, you needed to play the game 3 times.  Each character had their own section of The Cave, so there was new stuff, but there were also 5 sections that had to be repeated.

While designing the game, I didn’t think twice about this for two reasons:

1) That’s the way Maniac Mansion worked and I was trying lift the spirit of that game. Despite what conspiracy theorists will say, the reason there are 7 characters in The Cave is that Maniac Mansion had 7 characters. It wasn’t to make people play an entire extra playthrough to see everything. Occam’s Razor and all that.

2) I really didn’t expect players to finish The Cave and then immediately start it up again and do another playthrough. I figured people would take a break. Enjoy the story and the deep meaning behind it all, examine themselves and their own desires, then maybe a week or two later, they would play it again. It’s why the repetition wasn’t a huge concern for me.

2a) The Goldmine level was just poorly laid out. I will 100% cop to that, and I think that one level contributes a lot to the feeling of monotony on subsequent playthroughs.

Now, this post isn’t some cathartic postmortem on the design of The Cave, so let’s get on to Thimbleweed Park, which is what you (quite literally) paid your money to see.

Thimbleweed Park has 5 playable characters: Detective A, Detective B, Ransome, Delores, and Franklin. Each of those characters has their own story and ending. The design decision Gary and I face is how to avoid the repetition of having to play the entire game multiple times to see all the endings.

One option is you get all five endings in one playthrough, but that would mean the endings couldn’t be mutually exclusive and they can’t really change the outcome of the story. As storytellers, we want the endings to have meaning and finality.

We could do some artsy-fartsy flashback storytelling where the different endings are just possibilities, kind of like how it worked in Monkey Island 2 with Guybrush dying in the acid pit. Artsy!

We could just let players skip through sections they have already played, but this feels lame, kind of like fast forwarding your VCR to get to the good parts (this is 1987, VCRs were all the rage). It’s too meta for me and feels like you’re not really playing the game, you’re just outside the game.

One of our biggest jobs over the next few weeks is to figure out how to do this and not force players to replay sections of the game just to see a different ending.

Although… you had to do that in Maniac Mansion.  You had to reply a lot of the game just to see Wendy’s ending over Bernard’s ending. I don’t remember a single person complaining about that, yet, players complained non-stop about (what I perceived as) the same thing in The Cave.

How were they different? Or are they not, and it’s the players that are different?  What does it mean for Thimbleweed Park? Will our heroes escape? Tune in next week! Same adventure time, same adventure blog.

– Ron

ThimbleCon ’87 Wed, 07 Jan 2015 11:41:00 -0500

Once Ron and I established we’d be developing a title that harkened back to Maniac Mansion, we started playing around with the look and tools.

The most obvious being photoshop which is kinda the workhorse of the 2D art industry. I’ve been using it mainly for my comic book pages and other project coloring since I’d been primarily drawing on paper, scanning my finished inked black and white pages and completing them digitally to add color and text.

In the case of Thimbleweed, the style really lends itself to just drawing everything digitally from the start. Although I still spend time figuring out my initial concepts and layouts as rough sketches or storyboards.

Here’s one of my first exercises as we’re rapidly coming up with a wide cast of characters…

For the concept of ThimbleCon, we want to have some events happening in town that bring a number of interesting and unique characters into the mix.

People might wonder given the size of the Edmund Hotel some of what’s going on to help keep it in business. The short answer is a bunch of small eclectic venues. Given the hotel was originally built during the town’s heyday, now long gone, there’s an incentive on the part of the last vestiges of Thimbleweed’s founding fathers and mothers to not go quietly into the night (you’ll find out more about all that later).

In any event, by hook or crook the hotel’s struggling to stay in business by any means possible and its a perfect venue for a small local sci-fi, comic and gaming convention in the 80’s – additionally having started my professional career in the comics industry in the 70’s and 80’s it takes me right back to my roots.

– Gary

REGISTRATION FOR THIMBLECON 87- to be held at the scenic Edmund Hotel in downtown Thimbleweed Park will be open soon: Last year we had a record turn out of 62 paid attendees – and are hoping to surpass that – With booths from Stan’s Toys & Comics, Comp-u-venture (formerly 3 guys computer games, formerly 4 guys computer games) and a sales rep from a major distributor. We’ll also be holding our traditional costume contest. Look for registration forms at Stan’s and at the Edmund West Willow Ballroom. Remember snacks and refreshments will be served by Chris Sprouse’s mom while they last- so get there early.

I Got Nothing Done Tue, 06 Jan 2015 11:34:00 -0500

I got nothing done on the engine yesterday.  I had the best of intentions. Sleeves rolled up, hot coffee poised within easy grasping, then I decided to check the Kickstarter page and proceeded to get lost in spiral of spreadsheets and budgeting for the rest of the day.

When your Kickstarter ends, you don’t get a bunch of money.  A big truck with a Kickstarter logo doesn’t drive up and dump a pile of cash on your driveway (idea: do a Kickstarter to get a truck that dumps Kickstarter money on people’s driveways). Instead you have to wait at least 14 days while all the credit cards clear (or don’t clear).  Amazon’s web page is very confusing about how much money you will actually get and when it will show up.

Yesterday was the first day the money was actually available and we had a real total.  Kickstarter takes 5%, Amazon takes anywhere from 3% to 5%, and then there is the unknown of failed credit card transactions. When the Kickstarter ended, we had a lot of failed credit cards, but over the next week most everyone updated their information and the pledges cleared.

When all the dust settled, these are the final numbers:

Raised: $626,250

Fees: -$57,198

Failed Transactions: -$4,890

Available: $564,162

All those number lined up with what we expected and budgeted for, so that was a big relief.

Many of the failed credit cards came from backers who were having issues with Amazon and they went on to back using PayPal, so maybe only half of the $4,890 was actually lost.

The total PayPal money (after fees) is around $8,000.

We budgeted the project using just the Kickstarter money and we’re going to use the PayPal money as a safety net or for improvements.  If we want to add some new feature, or spend a little more on music or art, then it will come out of that fund.

The PayPal money is all going to make the game better.

OK, now I’m off to do some programing. This time for real. Honest.

– Ron

Engine Mon, 05 Jan 2015 13:11:00 -0500

After I posted this question on Grumpy Gamer, I started to take a close look at engines that were suitable for a 2D point & click game. Lots of great choices, but deep down (if I’m honest with myself), I’m a game engine snob. Whenever I use an engine, I keep wanting to modify it and hack into it to do what I need. I guess I’ve found over the years that it’s a lot easier (and less stressful) for me if I just create my own.

I have a fairly robust 2D graphics engine written in C/C++ that I used for The Big Big Castle, Scurvy Scallywags and 30+ game-a-week prototypes over the years. It’s stable and I’m used to it. It runs on iOS and (mostly) on Android, and I ported it to Windows and the Mac about six months ago.

I use SDL for window creation and handling input, but not for rendering. I just get the surface back and then use my own rendering code. It has an abstraction layer for OpenGL, DirectX, etc, but the DirectX layer is pretty simple and kludgy. I’m not sure I have the desire to fully learn DirectX, so I might get someone to help with that.

I think my engine has everything I need…

Except a scripting language.

I looked at Lua which it’s pretty easy to integrate and is highly optimized, but I really hate the syntax. There is just too much that is goofy about Lua. I like my { braces }.

I looked at writing my own scripting language. It’s not as complex as it seems, and I figured it would take me about a month, but I’m not sure I want to eat up that much time. 18 months seems like a long time, but it’s going to go away fast, it always does.

The other option was Squirrel. I’ve followed it for several years, but never really had the need to integrate it. I like the syntax and it’s pretty simple implement. I’ll probably go in and modify the syntax a little to mimic how SCUMM laid out code for rooms and objects.

So, mixed with design and budgeting, I think this week will be spent getting Squirrel implemented and building a quick test game to see how well it works.

I’ll let you know how it goes.

– Ron

Important Question Fri, 02 Jan 2015 15:20:00 -0500

Day 1 is Friday, I don’t plan on working this weekend, so is Monday Day 2 or Day 4? Making games is hard.

– Ron

Day 1 Fri, 02 Jan 2015 11:25:00 -0500

First official day of Thimbleweed Park. Desk is clean. Not sure how long that will last. My guess is until 3:28pm.

Most of today will be spent getting getting tools organized and updating design docs. Gary and I have a lot of notes that I’m going to move into Puzzle Dependency Charts. They will start as a bunch of unconnected fragments, and over the next few months will all get linked together in the final design.

– Ron

First Post Thu, 01 Jan 2015 03:01:00 -0500

Welcome to the Thimbleweed Park Development Diary. If anyone in the gaming press had bothered to mention it, I’m sure it would have been voted most anticipated development diary of 2015. But no one did. I’m not bitter.

Thanks again to everyone who supported our Kickstarter. Even if you couldn’t be a backer, your tweets and kind thoughts were enough.  2015 is going to be a magical year for Gary and I.  Working together again on a point & click adventure is an odd dream come true.

See, I’m not bitter.


The plan is for myself, Gary and (eventually) other team members to post here at least every Monday for the duration of the project. We’ll take you through what we’re working on, decisions we’re making, get your feedback, and talk about any issues we’re dealing with.

We’ll have (non-spoiler) test builds for people to download, try out the UI and generally stress the tech.

Our plan is to spend the next 4 months finalizing the design, wrapping up loose ends of the story, story boarding all the rooms, and getting the engine in shape. Come May 1st, we’ll start full production of the game.

Over the next few weeks, I’ll be talking a lot about the engine and our tech plans.

Welcome aboard.

This article originally appeared on