Engine Roadmap

by Ron Gilbert
Apr 07, 2015

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 1280x720 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

Sushi - Apr 07, 2015 at 15:31
Ron, I was wondering for some time...
Reading your posts, it seems you have to build a lot from the ground up (paralaxx scrolling, verbs,...)
The kickstarter video showed an engine that was already pretty complete (compared to MM scumm).
So how come you have to redo all of that? Or was it all just pre-animated and not a real playable engine at the time?

Ron Gilbert - Apr 07, 2015 at 15:35
The stuff you see in the KS video was actual code running, but it was not in an adventure game engine. An adventure game engine is a lot more then displaying images on the screen, it's about verbs and inventory and talking actors and save games, using objects, etc. Yes, I could have brut forced the whole game with just the code I had to make the KS videos, but it would have been amazingly inefficient. A good adventure game engine is about quickly iterating.

Jonny - Apr 08, 2015 at 08:16
This will be the A new hope for future adventure games... Oh the joy

Nigiri - Apr 07, 2015 at 15:52
That was probably a video (an awesome one, I have to say. Loved the music)

hyggligmathias - Apr 07, 2015 at 15:40
From that list it looks like we're in for a treat :) I just hope you'll keep on doing the game you'd want to make when the oldschool purist backers come in complaining about shaders and dof.

Christopher Griffin - Apr 07, 2015 at 16:10
Shaders are fun!  I remember thinking how awesome it was to render a cube that had textures with transparent alpha sections on them, and then using a silhouette shader to watch it essentially turn into a shadow box.  Actually, I can imagine a shader that would be used for the lights getting turned out...

ThieN - Apr 07, 2015 at 16:41
Hey ron, really loving these blog post. When i was eight years old i always wanted to be a game programmer and maniac mansion started it all! Its unbelievable seeing the build process described like this and a real eye opener.

Have to say the best thing till now is you admitting you suck at math ;)) Gives us regular guys the convidence to think we could pull sometihing like this off too!

Enough flattery.... Whats the secret of monkey island??


Gregory - Apr 07, 2015 at 16:45
This isn't a suggestion necessarily, but I've always been interested in the idea of composing a game's soundtrack in a music tracker (OpenMPT, for example), and then writing a library to control the order of the patterns, toggle channels, adjust the volume, change instruments, etc.  

For example, you'd have a scene in the game that would loop patterns 1 through 9, and could set the number of times to loop.  Then if the player travels to a new scene or we randomly fire a cutscene, we'd find our location in the old pattern, if we're at the beginning, quickly fade it out and start the new loop, else we're in pattern 9, queue up A and B to play a segue because that doesn't sound as abrupt.  When the scene changes, start patterns C through 1F and put those in a loop.  Maybe always have some instruments playing in a muted channel.  Inside of the pattern, make a decision whether or not to unmute the channel.  Do this randomly to give the soundtrack some variation.

I imagine this is similar in idea to what FMOD and iMUSE do/did, but I admit to knowing very little about either of those.

Ron Gilbert - Apr 07, 2015 at 16:52
I've always want to explore something like this for repeating game music. It's got an API to produce the control files:


iMuse was amazing to use, but it worked at a very core level, dealing with individual notes. It was also very time consuming. In addition to the musicians, Monkey Island 2 had a full time programmer that did nothing but install iMuse hooks into the SCUMM scripts.

longuist - Apr 07, 2015 at 17:17
Thanks for the link, that went under my radar

Iron Curtain - Apr 11, 2015 at 10:52
As much as I wanted to hear chiptune in the game (after all, I am a chip musician myself), I have accepted that it is Ron's (and Gary's) game, and they get to choose who does the music as they please. It is really their game, we're just producing it. ;-)

Gianni - Apr 07, 2015 at 16:55
Hi Ron,
nice updates lately!
I was asking myself: what about dialogs?
Do you plan putting lines and replies in the room code or you plan having a dedicated system for them?

Ron Gilbert - Apr 07, 2015 at 17:02
Dialogs are an interesting question, and I don't know if we're going to have them or not. Maniac Mansion didn't. They didn't show up until Last Crusade. They are amazingly time consuming and balloon the amount of writing. It's going to come down to how much time I have to spend on programming verses writing.

But to answer your question, I would not embed dialogs in code. We did that for Indy, Monkey 1 and Monkey 2, but there are better ways. For DeathSpank I created a special scripting language called .sassy files that allowed for the creation of dialog puzzles without code. If dialogs appear in Thimbleweed park, it will use .sassy files and I'll do a post describing them.

longuist - Apr 07, 2015 at 17:33
I would like to have dialogs in the game, when replaying MM it always felt like something was missing. But as you and others already stated; They should be infrequent and rather short to not get bored. Hope there is some Ron-Time left for some of this. One (in digits:1) dialog puzzle would be great too.
Btw, thanks for the great new blogpost!

prbalbontin - Apr 07, 2015 at 18:47
I didn't notice the lack of dialogs in MM until you mentioned it (I played it for the last time a while ago). Ron, maybe you could ask what people would like, just to get an idea of what are the expectations for that. Honestly, I think most of us think of funny dialogues when we are asked what a graphic adventure is, since it's one of the most iconic and recognizable aspects of the genre. It never occurred to me that Thimbleweed Park would come without them (in fact, if I knew there were not included by default I would have paid for including them as a stretch goal).

Ron Gilbert - Apr 07, 2015 at 19:00
I didn't say it wouldn't have them, it's just something we need to really think about. The problem with asking people what they would want is that people want everything. It's more about tradeoffs, every choice is. I know players like dialogs, and I like doing them, it's just about being realistic and smart in the decisions we make.

Part of this blog is us "thinking out loud", so please understand that.

prbalbontin - Apr 07, 2015 at 22:06
Oh, I totally understand that, Ron. I'm sorry if I sounded as if I was complaining, it wasn't my intention. Please, keep thinking out loud, it's priceless :)

Pier Luigi Rocca - Apr 07, 2015 at 17:22
SFML is now supporting Android and iOS, so they say in their changelog http://www.sfml-dev.org/changelog.php wouldn't it be a candidate for a free (as in beer) audio library?

Uli Kusterer - Apr 07, 2015 at 17:28
Interesting post, as always. I was kinda wondering why you never mentioned game state saving, as I see that as the most difficult part that I'd try to solve at the engine level right from the start. It'd also solve the cut-scene state restoration problem implicitly, because you could just save off all state, let the cut scene mess it up, then restore the game (and set a flag that the cut scene already run so you don't end up in an endless cutscene loop :-p).

If you can make the game use a fixed number of objects, you could just give each object a unique identifier (i.e. the name of the Lua global that holds its table) and list of properties that need saving, then loop over a list of all objects and save all those properties out. Since Lua uses tables for each object, you could probably just give un-saveable properties a prefix and then loop over all keys in its table and have your code only save ones that don't have this prefix.

Or am I imagining this as being too simple? I've written my share of file formats and editors, but admittedly I haven't written savegame code yet.

OGI - Apr 07, 2015 at 18:44
Ron, what about audiere?

Ron Gilbert - Apr 07, 2015 at 18:48
These don't do much more the SDL_MIXER. FMOD is nice because of the tools allowing musicians and SFX designers to change data and how it flows into the game. FMOD is really about the tools. FMOD also has some interactive music functionality, but it's really about the tools.

Phaze - Apr 11, 2015 at 04:41
Since youre selling it that way, sounds to me (no pun intended) that you should just buy the FMOD. :)

Mattias Cedervall - Apr 07, 2015 at 18:56
Ron, I hope we will be able to deactivate the dialog subtitles (if we want) when we have voice acting coming from the speakers. I'm playing the special edition (I'm special too) of Monkey Island right now and I can't find a way to turn off the dialog subtitles. :-(

Thank you for the very interesting update, Ron! :D I'm most excited to hear about the translation system. I hope things worked out regarding the font(?).

Ron Gilbert - Apr 07, 2015 at 19:02
Yes, you will be able to choose text, voice, or text-n-voice. I suppose you could choose neither, but that would be kind of confusing and a super-hard-mode.

Mattias Cedervall - Apr 07, 2015 at 19:46
Sounds great! :-) I hope you'll be able to use the C64 font! Thank you very much for your reply, Ron! :D

longuist - Apr 08, 2015 at 01:52
Haha. I guess its what speedrunners dream of..

Meuti - Apr 07, 2015 at 19:18
"I'm much father along than I thought/feared I'd be at this point." - Congratulations I guess! Boy or Girl? :D

Ron Gilbert - Apr 07, 2015 at 19:24

Peter Campbell - Apr 07, 2015 at 20:31
Ron, I'm glad to see that unlike many developers, you're being careful with the game's budget and seriously debating whether to use several thousand dollars of the kickstarter funds on FMOD that may have a much cheaper and just as efficient alternative (regarding FMOD).  Peter Molyneux could learn a thing or two from you and should be taking notes on how to handle a game's budget, he pretty much committed career suicide with the Godus debacle (he had already badly damaged his reputation with the terribly awful Fable 3).  

I also see that you are indeed seriously considering porting TP to consoles since you want an audio program to support such platforms.  The way I see it, if you do port Thimbleweed Park to the PS4 and Xbox One for example, those consoles already have close to ten million users each and will continue to sell like crazy for the next 7-8 years to people who usually never play games on computer and mobile platforms.  No matter how good or bad Thimbleweed Park would sell on consoles, I just see a giant goldmine of net profit to be made despite the costs of porting and the percentage of sales revenue that Sony and Microsoft would take for every copy sold.  And i dunno if you and Mr. Winnick are self-publishing the game, I'm assuming that you guys are the owners of Terrible Toybox, Inc. so other than Microsoft and Sony there really won't be a publisher middleman who's going to take a chunk of the sales away from you guys since you guys are the publishers.

And looking way way into the future, if you and Mr. Winnick do decide to launch another kickstarter campaign for another old-school adventure game running on the Grumpy Gamer Engine or something else, I'm pretty sure we've got your back =)  But that's not important right now, there is tons of work to be done on making Thimbleweed Park as good as possible.  Mush!  Mush!  All joking aside, seriously you guys are kicking ass and it's only been 3 months!

Justin Graham - Apr 07, 2015 at 21:11
"We need something that will work on Mac/Linux/Windows as well as iOS/Android and consoles. Maybe I'm missing something obvious."

I think OpenAL is probably your best bet. It might be a little low level, but it is cross platform and not too difficult to use.

Jonny - Apr 08, 2015 at 08:13
I was just gonna say OpenAL too. Although I haven't used it directly, it has iOS support etc and seems to be pretty nice.

Tomimt - Apr 08, 2015 at 01:49
That looks like a solid roadmap to me. Personally I've been amazed on how fast you've made progress with the engine and from the looks of it you're a bit amazed about it yourself as well.

Krystian Gałaj - Apr 08, 2015 at 02:00
I'd specifically recommend OpenAL Soft ( http://kcat.strangesoft.net/openal.html ). Still no tools, but in my experience it performs a lot more consistently (and usually taking less CPU time) than SDL on Mac and Linux, is really thread-safe, and also provides audio capture, 3D sounds and decoding of popular sound formats. And it seems to be present on all the platforms you need.

delMar - Apr 08, 2015 at 02:17
Funny that you mention user translations.

I came across this post the other day:

As I guess you'll be asking for recommendations concerning crowd localization tools in or about June, I'll just keep that link here as a reference and re-post it then :-D
Maybe I will even have found the time to test it myself by then.

Ron Gilbert - Apr 08, 2015 at 02:27
The EFIGS languages will not be crowd sourced. I was referring to a system where post-release, users can do translations into  any unsupported language they want.

delMar - Apr 08, 2015 at 02:45
Oh, right. I remember that small detail.
It's great that you intend to make user translations possible above the ootb translations.

delMar - Apr 08, 2015 at 02:21
Ah, concerning savegames:
I take it you don't store all game-state variables in a common GameState(TM) object?
'Cause, y'know, it'd be just about Marshalling / Unmarshalling then.
Marshalls go along pretty well with Detectives, btw.


Yes, I know. Sorry.

Pottty - Apr 08, 2015 at 03:02
Actually the save/load system is not that hard, I wrote one for Unity engine witch is pretty easy (well... maybe a little bit inefficient).
My solution was something like this: I create a SaveData class and placed here every variable I wanted to save, when I called the save() function it serialized the whole SaveData class and wrote it in a file. The load is the same backward with de-serialization.

Christopher Griffin - Apr 08, 2015 at 09:36
Ron's been doing development for quite some time; I'm sure he's familiar with the de facto process of serializing the game's variables into an object and writing it out to the filesystem.  The tricky bits with doing saves involve additional problems, such as correctly working saves between game versions (where new objects/states could be introduced; essentially breaking the old save game file) and/or saving the states of things that seem unimportant, but ARE important -- like whether or not a clock is open or closed.  It's a variable, true, but it's really the state of a script object, which is somewhat external to the game, as its definition resides outside of the game's codebase.

And if Ron has the same programming OCD tendencies that the rest of us have, he probably wants to use the most robust efficient way possible which will require TONS of consideration.

Ratchet - Apr 08, 2015 at 03:03
What about http://www.modplug.com instead of FMOD? Is's available for WIN/MAC/LINUX (love2d.org uses it i.e.)
There is also BASS -> http://www.un4seen.com/

LichiMan - Apr 08, 2015 at 06:09
Are you going to create a Twitter account for your version control commits?
It was really fun to follow the Scurvy Scallywags ones!

Dr. J - Apr 08, 2015 at 08:32
Savegames: Just have a list of handles to each object and tell them to dump/restore their variables. All the rest goes in one big GameObject.

Zak Phoenix McKracken - Apr 08, 2015 at 08:43
Just a note on save/load system: I played "The Cave", and I didn't feel comfortable when resuming games. It uses "check-point". For Thimbleweed Park, it should be better to have a perfect state.

Peter Campbell - Apr 08, 2015 at 09:52
Wouldn't an auto-save feature, and an auto-save feature only be the best way to go about things for TP?  Or the only other non-cheesy thing I can think of is for the player to have the option to start the Act that they are on all over again.

Ron Gilbert - Apr 08, 2015 at 10:06
I won't do check points. Once you have a robust save, auto-save is nothing more then calling it periodically (assuming it's fast).

The hard part is saving the data in the first place. It's not as easy as it sounds. It's a lot more complicated then just saving a key-value paris for game state. The scripting language is can run a lot of different threads, and each of those threads has their own stack frame and when the game gets saved, a call could be nest quite deep and everything on the stack needs to be saved.  Plus the animation system can have many animations playing, and each of those can have several layers, all this their own state that needs to be saved. Then there is the audio. 32 channels. If the SFX is short, probably don't need to save it, but if it's a long SFX, it's position needs to be saved and then restarted in the right spot. Same goes for music. If there is an interactive music system, all that needs to be saved. Then there is patching. A save game needs to still be valid after a patch that could introduce new variables, game states or possible the deletion of data and assets.

None of these are hard on their own, they just take time, but put together, saving is quite a complicated task. I know how to do it, I just dread the task of actually doing it and then debugging and testing it.

Death by a thousand paper cuts.

Zak Phoenix McKracken - Apr 08, 2015 at 10:17
OK, good! I think it should be simpler using an "aware" saving approach (that is: no autosave, but user intentionally want to save). In that way, by pressing the classic F5 key, you can stop threads, animation, background music... and when the user loads a saved game, it restarts animations, music, murdering, and so on...

Ron Gilbert - Apr 08, 2015 at 11:18
There will be an autosave, in addition to saving intentionally. Also, with PC games, if someone just hits the close button on the window, it should just save and close. I find confirmation dialogs to be annoying. I said close. Close!

Zak Phoenix McKracken - Apr 08, 2015 at 11:34
Let's poll...
Q: Do you like a save/Load dialog window?
1. Yes
2. Of course
3. Naturally

Let's vote!

Franklin - Apr 08, 2015 at 11:42
Ron already said there will be a normal f5 saveload and autosave.

Mattias Cedervall - Apr 08, 2015 at 08:54
Regarding saving: Emulators like bSNES use save states in addition to emulating ordinary battery saving (when games such as Zelda support battery saving). Perhaps Thimbleweed Park can use the same saving technique as emulators use? The source code for several emulators are available.

Derrick Reisdorf - Apr 08, 2015 at 10:33
I would think the game would be somewhat dialogue-heavy.  You know, asking the townsfolk questions, and whatnot.  Trying to cleverly (and unbeknownst to the character or suspect) extract crucial information from him/her, Columbo-style.

I had actually thought it could be a key component to the game.  In addition to your normal dialogue puzzle, I would think that it could also be a way to vary the clues given to the player.  Ask the right questions, you get better clues.  And, with most characters you should not be able to access the entire dialogue tree during one playthrough.  For example, once you reach a certain question (or number of questions), the character would clam up, "You know. I don't really feel comfortable answering any more questions without a lawyer present.", or, "You sure do ask a lot of questions, mister. And, I don't have any more answers for you, anyway.", etc...  You may or may not ever become privy to a specific clue (or given a specific item).  However, it would take some work to make sure that if you never gain access to that clue that you will be presented with an alternate solution to a puzzle, whether that be easier or more difficult.  I could see where a heavily dialogue-driven game could get quite complex, but I thought it would be a great fit for a game about two detectives.

Side note/question about the phone book...  Is it safe to assume the Thimbleweed phone book will be a central mechanism for puzzle discovery?  For example, you discover a new name or business, you look it up in the phone book to get the address or call them?  Will new locations become accessible on the map via the phone book?  I assume certain clues will also trigger new dialogues with certain characters...  Any special consideration as far as how the phone book will fit into the engine?

Sushi - Apr 09, 2015 at 02:03
Ok, raise hands... Who has an OCD to save game at the start of a dialog tree, prune it and reload as needed until all options are covered?
It is not fun to do, but I would choose the same dialog over and over again if I played it subconsciously.
Not having dialog trees like in MM, Zak and other 1987-like games would be reassuring!
Or you could think of a clever way to prevent this in the save game system. Or just by design,that unpruned dialog stays available without the need to reload, as in tales of monkey island. Anyway, saving and reloading that often is distracting. I remember just starting all over again each time when playing Zak on the C64, because save/load was long and error prone. Of course most games back then did not have save capabilities, so we were used to that. :)

Tomimt - Apr 09, 2015 at 03:55
I think this is an issue for so few people that it doesn't merit any real thought.

Justin Graham - Apr 08, 2015 at 15:18
Also with regards to using Flash as an animation tool, check out these guys. They have a Flash exporter that exports to an open format, and there are players for various engines.



Main Antagonist - Apr 08, 2015 at 17:45
For the animation software two relatively obvious choices would be
- Spine
- Spriter
(we use the latter). Besides the typical spritesheets you get an (almost) human-readable JSON output that you can use to recreate the animation of the individual parts in your engine.  Spine brings a lib for that, with Spriter it's also easy enough.

Mattias Cedervall - Apr 09, 2015 at 10:23
I ate a banana while playing Monkey Island. I felt cool.

Dan - Apr 09, 2015 at 13:02
Dialogs are a big chance to insert some jokes. But MM is still a funny game, even though it comes along without any dialog. It has actually even much more humor than some later SCUMM games that feature dialogs (e.g. both Indy adventures). So dialogs aren't any warrantor for humor and fun. I argue that they aren't a must-have in TP.
But if there was a significantly higher number of characters in TP than in MM or Zak, then I would be certainly surprised not to be able to talk to anyone throughout the game. So some few dialogs would be nice. You cold restrict the appearance of those dialogs to the detectives in order to reduce the effort. Just let it depend on the tightness of your time schedule.

Dan - Apr 09, 2015 at 13:05
Sorry, I meant "could" instead of cold.

Lukas - Apr 14, 2015 at 07:27
I think MM worked well without dialogs because you were mostly trying to avoid the NPCs.

Ciantic - Apr 11, 2015 at 17:20
I got an idea for Save format: One huge patch/diff JSON file per save game.

You record couple of JSON states in different parts of the game before releasing, and have save games diff against those. They should get pretty small.

Ben - Apr 14, 2015 at 18:09
No space in your plan for testing? What's you're general approach to this? Will ere be an automated test harness of any type?

Ron Gilbert - Apr 14, 2015 at 18:14
This is a roadmap for the next few months of the engine. Testing won't begin until Jan 2016.Test harnesses for game is hard. What I've done in the past is create little robots that run around and click in stuff and run them all night long. It's amazing how far a random clicking robot can get in a night and the bugs it finds.

Ben Jackson - Apr 15, 2015 at 20:08
interesting idea! It's a Sort of fuzzing as an extension of simple play testing. Thanks for the insight! - I always find it super interesting seeing the different approaches to the almost impossible problem of 'software quality' in different disciplines. Personally I like structured test scenarios, but this sort of thing does get you a surprising amount of stuff that structured testing cannot.

Lukas ThyWalls - Aug 17, 2015 at 16:06
Hi Ron

I want to ask something midly-related to the translations, and for that i wanna to post in a post you talk about, and maybe it's the best one i think. I don't know if someone ask something related.

You want to add the possibility for user-made translations, this don't affect me directly because i'm spanish but i think it's very good, but what about differents dubs? My girlfriend works in that area and knows some amateurs projects of games that someone want to be dubbed, and they make it real, and although is more difficult than a simple translation, some projects goes to the goal with a decent results. I know it could be (very) difficult in your side, but if you don't decide yet the sound system, maybe you can make something to have the door open to this option of "fan-dubs", maybe having a structure of folders and "exchanging" the sounds of the dialogs or something else.

Only this one. Great work, Ron, always beautiful ;)

Simon - Oct 11, 2015 at 11:34
Hi Ron,
since several days i asked myself what was/is your first decision when you start to write a new engine and therefore: how you start, what´s the first class/task you write, on which i suppose much other things will build on?