TesterTron3000

by Ron Gilbert
May 02, 2015

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:

- Ron

Mattias Cedervall - May 04, 2015 at 11:22

Ron, what do you think of a point and click adventure with password saving instead of save files?

Christopher Griffin - May 04, 2015 at 13:13

Password saving is great for games that have few variables and perhaps a crude level numbering system. However, for the type of saving you would want in an adventure game, they just don't make sense. Storage space is essentially "free" these days, so doing a full type of save is favored much more.

A simple password is usually used for games where a few quantities are memorized, and perhaps what level someone is on. They don't hold a ton of information, such as where you've been, which dialogue choices you've made, item combinations you've made, and exactly where you're standing in the world.

Brian Bates - May 04, 2015 at 15:46

Unless of course you want a 1,000 character password!

Tomimt - May 04, 2015 at 16:45

Yeah, I doubt password saving would be really that good system for an adventure game where's way too many variables. There's just too many different kind of states the player can quit the game in. If adventures were like arcade games, where jumping level to level by password is far easier to manage, then it could work, but in reality it just isn't an ideal system.

Mattias Cedervall - May 05, 2015 at 04:32

I suspected that there are too many variables, but I was thinking more of the philosophical aspect of password saving. Then it's easy to get a password from a friend (I don't have any) and you kan skip certain parts of the game. With some games it's possible to share save files, but it's easier to share a password (if it's not too complicated).

Ron Gilbert ✓ - May 06, 2015 at 00:25

The state for an adventure game is too much for a password. It comes down to how many bits of information can a password hold. It's pretty limited. Passwords work for games with checkpoints.

Alessander - May 06, 2015 at 17:23

In theory, it seems to me that one could use a Gödel numbering function and create a password combining all the values of the many variables... However, the password would probably be too long and expensive to calculate...

Nor Treblig - May 06, 2015 at 21:24

Adventure games actually often do have some kind of password/cheatcode system for testing and debugging purposes.
E.g. they allow you to start at a specific location in game with a specific set of inventory items.
In SCUMM this was called boot params, see this page for a detailed list: http://wiki.scummvm.org/index.php/Boot_Params

And then there are also traditional cheat codes like Ctrl+W in Monkey Island 1 and 2 for instant win!

Tomimt - May 07, 2015 at 17:16

Those are pretty different from password saves though. Debugging codes are just for that: fast jumping from spot to spot in order to see can you break something. And cheats are an entirely different matter.

Nor Treblig - May 09, 2015 at 23:07

Sure, but this would make it at least possible what Mattias Cedervall wanted: easily sharing such codes with friends and skipping parts of the game.
Of course they cannot replace proper saves.

Dan - May 11, 2015 at 08:35

Password saving would be very unconventional for adventure games, I think.

By the way I've still got some floppy disks in my cellar, bearing the inscription "savegames".

Kenney - May 04, 2015 at 11:25

This is not only brilliant but completely fascinating.

Vegetaman - May 04, 2015 at 11:36

Very neat! Reminds me of Dr. Fred running around in the arcade room in Maniac Mansion at one point, and I also like the Adventure for Atari 2600 style "green barricade" it looks like showing the end of the screen scroll area. This is a fantastic test mechanism.

Damian - May 04, 2015 at 12:22

Oh!
This MUST be in the game. If you include it, I'll make a Twitch channel called "Thimbleweed Park plays Thimbleweeb Park" and see if the game can finish itself in automatic-random mode!
XDDDD

Jörn Huxhorn - May 04, 2015 at 17:56

I agree so very much! This needs to be a hidden "cheat code" in the final game!

Ron Gilbert ✓ - May 06, 2015 at 00:26

That's not a bad idea.

Scandinavian in a tree - May 04, 2015 at 12:28

To be honest I like many aspects of this temporary wireframe art, especially the rooms inside the buildings. The wireframe art of the street destroys the illusion of it being cool for some reason. It must be the proportions of the buildings in accordance to the woman, or that they are placed so close together like a placeholder-thing. And I know that the final street of the game will not look that way. I just want to point out that the proportions of the rooms inside the buildings feel right to me, but the street dont yet (maybe the buildings need to be placed more apart. Maybe we need more stuff in the far background, such as mountans, UFOs or clouds. Or maybe the buildings need to be bigger. Or then again maybe we need a different perspektive, like a map thingee or that the buildings are at a not-straight line). But at any rate I love these videoes - they give me input..

Derrick Reisdorf - May 04, 2015 at 14:55

I definitely agree that the buildings need to be bigger and possibly spaced apart more as well. And, if this happens, the camera view would need to be pulled back (everything scaled smaller).
The other option would be to have a map view (or birds-eye view of the area). This would be my preference, unless there are objects or puzzles that occur on the streets themselves (e.g. drop something into a mail slot, examine sewer drain or manhole, climb light pole, etc.).
If there are street puzzles, maybe Ron can somehow implement a "run" option- which possible would introduce the need for a run anim.
I'd like to hear Ron's take on this- if the street room will stay mostly as-is, or if it's just a placeholder of sorts.

Ron Gilbert ✓ - May 04, 2015 at 17:10

This is all very very early art tests. The scale is wrong due to experimentation

Nor Treblig - May 06, 2015 at 21:13

It could be handled like in Zak McKracken, e.g. here for reference a street with normal scaling:
http://www.mobygames.com/game/atari-st/zak-mckracken-and-the-alien-mindbenders/screenshots/gameShotId,438562/

And here a large area with a super small actor running super fast (speed in pixel/s is actually about the same as with normal scaling!):
http://www.mobygames.com/game/dos/zak-mckracken-and-the-alien-mindbenders/screenshots/gameShotId,267696/

Dan - May 04, 2015 at 12:47

It's remarkable how short the code is! Very efficient!

Lennart - May 04, 2015 at 13:36

Don't let these test scripts tempt you to block of areas the player has no business in just for sake of fast running test scripts. Joke aside, what is your philosophy on this issue? Many games let you go anywhere anytime, like Sam'n'Max, The Dig, Monkey Island, other lock you to your current "scene", like Last Crusade, Fate of Atlantis, and Loom.

Doug - May 04, 2015 at 14:42

I guess the length of the soak will overcome the bias, but there's a heavy skew towards early objects and to a lesser degree early verbs. A smaller chance per action would reduce the skew and increase the chance of doing nothing...

*twitch*

Diduz - May 04, 2015 at 15:58

I like how the autotesting system is obsessed with Zak McKracken.

Peter Campbell - May 04, 2015 at 17:01

^
Best comment yet!

Augusto - May 04, 2015 at 16:30

One question: why using randomOdds with 0.2 five times? Wouldn't it be more efficient to get a random value between 0 and 1 and check if <0.2, <0.4, <0.6... so every random number means an action is performed. Or... are you testing idle time too?

Thanks for sharing!

Doug - May 04, 2015 at 17:28

Not every verb can be applied to every object.  Plus it rolls on all objects as well as all applicable verbs.  The only way to do a "fair" roll would be to count the possible actions and then select the index by random.  (Yeah, it the question occurred to me at first as well :)).

I am the worst programmer; i totally would just fix the code and annotate it in the comments.  Terrible practice.

(Yeah, I know that the analysis of this script is probably worth more time than it took to write the script.  And I know it is likely FineTM for large enough number sets.  .. just ... ~twitch~)

lemonCurd - May 04, 2015 at 17:35

So, if the object is able to handle all verbs, it will be walked to with a probability of .2, looked at with probability 0.16, picked up with 0.128 opened with 0.1024 and closed with 0.08192? Nice! I don' get the plan behind this, but I'm sure it's most diabolic! And I also like that with probability .32768 nothing happens at all. A well earned rest!

Doug - May 04, 2015 at 17:59

I think there is a devilish plan in the numbers. But they do tend to infinity, as the loop will never end until it finds a solution (the encompassing while(YES))

Which, on the whole, seems very enthusiastic.

DZ-Jay - May 05, 2015 at 06:19

You're right, I don't really think that was on purpose. It looks to me like Ron tried to spread the chance across all five actions with equal probability. However, since they are all mutually exclusive and tested in order, each consecutive action has 20% minus the probability of the ones before it.

-dZ.

Ron Gilbert ✓ - May 06, 2015 at 00:29

I did that because it was fast, otherwise every time I added something new, I'd have to refigure the odds. I realize that it's not statically perfect, but it took me 15 minutes to write it. It will get better over time.It does exactly what it needs to now and I have tons of other things to do. That kind of my philosophy at this early stage; get everything working only to the stage it needs to be.

Augusto - May 06, 2015 at 16:32

Great reasons, keep it simple, move forward

:)

Thanks!

Peter Campbell - May 04, 2015 at 17:05

Kill Thrill, that must be the sequel to the greatest PSX fighting game never released, Thrill Kill lol

Ron - May 04, 2015 at 17:27

Are these the final graphics ? I hope that you and Gary try to make the graphics a little bit more complex, like the Last Crusade, the VGA Version of Zak Mckracken (hopefully 256 Colors)...

Dan - May 04, 2015 at 18:28

Seeing that TP will rather be a reminiscence of Maniac Mansion, I reckon with 16 colors. Although 256 colors would be bombastic.
I personally like both 16 and 256 colors. I got to know MI on a grayscale display, so 16 colors are quite luxury to me.

Peter Campbell - May 04, 2015 at 19:32

To quote Ron: "Please keep in mind this is all wire frame art and no where close to final."

Wire frame art = rooms drawn very simplistically and with little to no detail, textures, variety of colors, shading, etc etc . That stuff Gary will add to the rooms later when him, Gary and David know that they want to keep the rooms that he's doing early wireframe art for in the game. It doesn't make sense for Gary to fully draw art for a room only to have the room get cut from the final build of the game. Right now the guys just want to put together a very early beta build of the game that they can have the characters walk around in, in order to test out Ron's game engine and figure how to best do the puzzles, the story, etc. etc.

Jammet - May 04, 2015 at 17:55

Ron, do you remember the "recording mode" in Monkey Island? Maybe it was also implemented in other games. I remember you had to pess a key combination like Shift+Ctrl+F11 to load and/or playback a recording, and anyone could create recordings of themselfes playing Monkey Island. It didn't always work perfectly -- sometimes it was not in sync with the actual game anymore, and you would see the cursor wandering around regardless, because playback hadn't stopped yet.

What was this originally intended for?

LogicDeLuxe - May 05, 2015 at 05:26

I guess, they implemented recording for the Monkey 2 demo, which entirely runs on a playback loop.

Iron Curtain - May 04, 2015 at 20:25

I have an idea: Sync up these autoplays with "Yakety Sax".

Strawberry - May 04, 2015 at 20:53

I'm already getting a real 90's feel to this game. It's a good feeling.

MarcusG - May 05, 2015 at 02:15

What is a "one frame bug" ? I didn't quite follow that.

DZ-Jay - May 05, 2015 at 06:12

Not to speak for Ron, but from context it sounds like two actions triggered in consecutive frames, where the second one occurs before the game state has been updated post the first one.

Say, for example, there's an item on a table and you trigger the "pick up item" action. The game then flows through the following actions:
1. Say "Thank you."
2. Add item to inventory
3. Remove item from table

While the game goes through that sequence, imagine if a new "pick up item" action is triggered right after step #2. The item is still registered as available on the table, so the action is valid but there's only one of it. How will the game react to this situation?

Regular humans may not be as quick to trigger these situations reliably, but an automatic robot player can.

David Fox ✓ - May 13, 2015 at 15:03

@DZ, in your above example, all of those would be triggered on the same frame, so the item would appear in your inventory and be removed from the table at the same time (as seen in the next frame update). Of course, the sayLine would appear then too, but would stay on the screen for several seconds.

Where it gets more difficult is if we had a script running that did these things, waited for the Say text to vanish, and then did something else. We'd have to either turn off the UI (making it a mini cut-scene) or make sure whatever happened later could be interrupted.

Marco Lizza - May 05, 2015 at 06:12

I guess Ron was referring to the corner case you encounter when clicking/selecting items and/or verbs at a very high rate.

Natalija - May 05, 2015 at 04:24

I got one question Ron: I want to start programing but I don't know where to start... Is it best to start in C++?

Iron Curtain - May 05, 2015 at 09:44

Try this tutorial: http://www.cplusplus.com/doc/tutorial/

Lukas - May 05, 2015 at 04:27

Greetings from Austria - Vienna Watching your Blog with much interest. :)

Mattias Cedervall - May 05, 2015 at 06:27

Ron, I think there's an "h" missing in the word "as" in this sentence: The Thimbleweed Park developement blog as been updated!
Shouldn't it be "The Thimbleweed Park developement blog has been updated!" in the ThimbleMail™ Update? There's also an
superfluous "e" in "developement" that should be "development". I'm sorry but I have nothing better to do now (that I care to
admit).

Typing regards, Grammar Commie :P
Free font: http://opendyslexic.org/

Christopher Griffin - May 05, 2015 at 16:47

> There's also *A* superfluous "e" in "developement"...

Fixed that for you.

Mattias Cedervall - May 06, 2015 at 07:58

No, you didn't. It should be a lower case "a".

Christopher Griffin - May 08, 2015 at 16:00

That was for emphasis, but even if you don't believe that, it's okay because I'm not the grammar commie -- I'm allowed mistakes. :-)

mr. T - May 05, 2015 at 07:03

Awesome post, my wish came true!

Had no clue that the tester thing was implemented during the early days already. It's actually hauntingly creepy how fascinated one can get over following some fairly simple random procedures being automatically executed by a machine. But in a fun way. I actually genuinely chuckled a bit when the character couldn't get enough of the lovely clock, playing with it like a kid or teenager might do.

"All with the unblinking precision and determination of rand()"

Loved this one. Maybe kids and teenagers are powered by that one too, along with many adults.

Zak Phoenix McKracken - May 05, 2015 at 12:33

It's really smart, and clean code. My congratulations!
Wow, so there is an Arcade Room (at most in this demo!) with the poster of myself attached to the wall!! :-D :-D

Christopher Griffin - May 05, 2015 at 16:45

What's with all the comments asking if this is the "final art"? Ron and Gary both have said approximately 4,238 times each that it is NOT the final art! Perhaps a big flashing yellow banner is needed on every video and at the top of every blog page flashing in 200pt font that the "ART IS NOT FINAL".

I apologize, everyone, I've not had my coffee today.

Brian S - May 05, 2015 at 19:06

Weird - I can't seem to play these videos from my Chrome browser anymore.  I have to switch to IE to play them.  I tried also going to Ron'
s Vimeo page, but this video isn't there for some reason.  Maybe Vimeo's having problems.

Awesome video by the way.  This is our first look at a great deal of rooms and connectivity in the game all at once.  Wow.  I love this testing concept.  Does it also allow for character interaction, and swapping active characters (maybe that's not coded yet)?  I didn't notice any in the video, but I might have missed it.

Love the animated hot dog flies.

Peter Campbell - May 06, 2015 at 21:37

Firefox is the best browser, so why not use that?

Brian S - May 07, 2015 at 12:17

I use firefox as well. I prefer chrome for various reasons. I just thought a heads up might be in order.

mr. T - May 06, 2015 at 07:37

I found a wonderful article based on Aric Wilmunder's stories - "The SCUMM Diary: Stories behind one of the greatest game engines ever made": http://www.gamasutra.com/view/feature/196009/the_scumm_diary_stories_behind_.php?print=1

Felt like a sibling piece so had to link it here :)

mr. T - May 06, 2015 at 07:38

Brian S - May 07, 2015 at 12:29

Thanks for the link. That was a great article to read! For some reason I had never seen it before.

mr. T - May 09, 2015 at 10:07

You're welcome :) I've read all kinds of stuff during the years but that was a new find for me as well.

Thomas - May 06, 2015 at 17:20

Hello,

one of my former colleagues did something similar for So Blonde and wrote an article about it:

http://www.gamasutra.com/view/feature/134893/automated_testing_building_a_.php

The nice thing, if I remember correctly, was that it was running without the rendering and therefore was able to play thousands of games overnight (so it would also find puzzle flaws where you could get stuck)

Franz - May 07, 2015 at 12:47

Argh!!!
I can't stop reading this blog and watching all the videos from Ron & Gary...
It's such a good idea.
Hope it won't spoil the surprise.

bladecoder - May 10, 2015 at 18:36

What an awesome idea to test the game. How I did not think of it before? I added the bot to my engine after read your post:

A demo: https://www.youtube.com/watch?v=b13ZXUOULJY

It supports:

- Stay in a room for a specified time
- An exclude list of forbidden objects. Useful if you don't want to exit from a zone
- A flag to never leave the current room
- A flag for walking to allow the bot to trigger player walking
- Chances tuned for more actions and less lookat and combine objects in inventory

Thank you for this blog. Really inspiring for me. I am working for 2 years in an Adventure Engine and I enjoy to see how you resolve the same problems that I found.

Josejulio - May 10, 2015 at 23:53

Hey, That's awesome stuff.

I've a question, it has been in my head for a few days now, I think that you made choose to use a scripting language (e.g. SCUMM, Squirrel) is to have portability(script stays the same and only modify the bindings if needed) and/or flexibility(swap code on real time)? (or maybe I'm wrong on this).
If so, how do you decide when to start using the scripting language and when to write on a compiled programming language (e.g. c++, c, asm, etc)? Also, did you build for SCUMM a debugger? I''ve tried to use an engine with javascript support, and it was a hell of a time and effort when i have a bug in my js.

Aside from that, thanks for having a development blog and showing us all those great advances.

mr. T - May 17, 2016 at 06:32

David tweeted this fascinating interview (Antic - The Atari 8-bit podcast) of Aric Wilmunder, so thought to include it here in the comments. Lucasfilm bits start at around 50min mark but I recommend listening it all:

http://ataripodcast.libsyn.com/antic-interview-104-aric-wilmunder-star-raiders-ii-temple-of-apshai

NukeTeam - Apr 24, 2017 at 05:21

Hi, can you please tell me how to run this script ?