A few people have asked what the difference with the engine we used for Thimbleweed Park 1 and what we are using for Thimbleweed Park 2.
They are basically two different engines with a few similarities, mostly in the format of the room images.
Thimbleweed Park 1 used SDL for graphics and sound and a scripting language called Squirrel.
Squirrel is a good language, but it couldn’t do the code optimizing I wanted and was missing a few convenience features.
You had to ship your game with full source and it compiled it at run-time. I wanted it to emit byte code so I could run an optimization pass.
After Thimbleweed Park 1 I started working on a early version of Death by Scrolling (called Runner back then) and in a fit of insanity I wrote a new scripting language called Dinky. It compiled to byte-code and had an optimization pass. It was still 80% compatible with Squirrel, but I added some new features and it was a lot faster.
About this time the idea of Return to Monkey island was starting to become real so I started (with David’s help) the game Delores. It was going to serve as a test bed for porting Thimbleweed Park 1 to my new engine that we’d use for Return to Monkey Island.
Thimbleweed Park 1 used the SDL sound engine which is very limited and porting to mobile and consoles required re-writing the sound engine. I initially poo-poo’d using FMOD because it would cost $6000 to use it for Thimbleweed Park 1, but in the end I spent more than $6000 porting to all the different platforms. Penny-wise, pound-foolish.
So Delores used FMOD and it’s a dream.
I also teamed up again with Derek who I had worked with on DeathSpank and he removed SDL and began a new graphics back-end that would use Vulkan, Metal, DirectX, etc. It would make porting to other platforms a lot easier and allow for better use of shaders.
We started Return to Monkey Island and basically used the Delores Engine. The big change we had to make was supporting hires images. It was just scaling the rendering, but we had to add a lot of smart caching because the texture were a lot bigger than pixel art.
I then started working on Death by Scrolling again and used the Return to Monkey Island engine with a new tile map renderer.
Death by Scrolling shipped and then Thimbleweed Park 2 became a reality.
Back to the Return to Monkey Island engine. The changes were pretty simple since we just need to scale it for pixel art again.
The big changes were in the Dinky scripting code since I want to re-look at the UI and verbs. I wasn’t happy with Thimbleweed Park 1, Delores or Return to Monkey Island and wanted to try something new, kind of a hybrid between the best of the three.
But more on that later…
So, it’s a very different engine.
Thimbleweed Park 1 -> Runner -> Delores -> Return to Monkey Island -> RPGTBD -> Death by Scrolling -> Thimbleweed Park 2 -> TBD
Comments:
The FMOD situation is a little disheartening. I wish open source all the way down - as for dependencies - would be the way for game development. Of course it can be done, but some areas still seem to require compromises.
Please do keep those technical glimpses behind the scenes coming.
And FMOD’s live preview — while running the game I can change envelopes/parameters until I’m happy.
And after I had to upgrade my Mac during RtMI (LeChuck’s ship killed the frame rate), it’s fun returning to much lower resolution scenes.
(Just kidding. I know it isn't. I hope it isn't.)
Thanks for the insights. The moat complicated part for me sounds like the graphical engine.
Got mo experience in the gaming field even though I would like to make it a passion of mine.
Just impressive that you can handle your tools this way.
Curious question though: Do your build and dependency systems also change and evolve over time?
And David: Glad you are getting more custom tools at hand to increase player immersion.
mo=no
(I should not write texts on my phone...)
- will you ever make the engine available to the public?
*by everyone I mean me.
Let's say: the Puzzle dependency chart has been defined.
OR, the story has been designed.
OR, nothing, we have just met and there will come a day for a brainstorming.
OR, we are taking a long vacation before the cruch.
OR, ...
I was there, in the late 80s early 90s, and the feeling from one Lucas adventure to the next was the constant innovation. What were you guys gonna come with next.
From the initial parsers to the word dials in Labrynth, to the fix huge verb list in Mansion, the disappearing verbs in Zack, action sequences in Indy3, smaller verb pool default verb right-click in Monkey, the wonderful verb-less, inventory-less interface in Loom...
It was a great journey!
That way, you can sit in your living room shouting things like "use parachute on ferret" at your computer/TV and really get immersed.
Anyway, just popping in to say I'm over the moon about this news. Grew up with the old Lucas adventures, and nothing else in gaming excites me as much as the people behind those doing new games. Just a lovely surprise every couple of years.
This was a good excuse to replay Thimbleweed again! Can't wait to see what you guys are planning, and super happy the blog is back. Honestly chuffed about the idea I'll have this to keep me sane in the forseeable future.
Threepwood’s Booty Dance (a rhythm game)
Tentacles Broken Dawn (prequel to Maniac Mansion and origin story of Green and Purple)
Thimbleweed’s Bughunting Delores (a text-only couch co-op game in which you need to find the bugs in actual Mmucusflem game code)
We would definitely be interested in undertaking a similar project for TWP2 as well.
If possible, we would also really appreciate it if, during the development process, you could keep the possibility of integrating an Italian dub in mind, ideally in a way that would make it relatively easy to add later on.
Thank you again for all your support. I hope we’ll have the chance to collaborate with you again very soon!
In contrast, you're writing thousands(?) of lines of code with TWP2's scripting language, but ripping out the old one (that shipped! that your team, presumably, knows well?) seems pretty major. What kind of pain did Squirrel's lack of optimisation cause your team while building TWP - or was it more about the unnatural structure? I'd love to see some example fragments.
Both programs are well thought-out and intuitive when it comes to producing scenes, but they are truly gate-keepers when it come to smaller companies attempting to run a business in game/computer audio. Because there's so much segmentation, it's not really possible for little guys to make something that works for everything unless you use one of them, or you offer a version that can be baked into the final product. But that carries it's own issues where the game devs have to learn the bespoke way to utilize the dlls etc etc
Not a huge fan of how expensive they are, and their hold on game audio is growing stronger and stronger because people don't pay as much attention to audio as they do to graphics, so fewer people care.
Would be cool to also hear how you went about making dinky. Lua upsets me for reasons that I don't even fully understand and other scripting languages like python are just way too heavy to try to embed.
Probably too late now, but have you considered WASM in a WebView? You can compile all your engine code (c/c++ and others that target WASM), and those call into JS and use the browser API's for WebGPU, audio, etc. You can still build native apps for anything that has a WebView and you get the benefit of a single codebase for all platforms. Native capabilities can also be bridged for things like haptics if you care about those. Added bonus is that it will run in a browser too.
love both your games and the insights here even more!
Have you considered creating a whole new DSL specifically for your games, or are Squirrel/Dinky just "good enough"?
I'm a seasoned developer myself and am currently working on such a language/VM.
Specificically tailored for point-and-click games, with a stack based VM written in C and both a compiler and language server in Go.
Goal is to have a very comfortable scripting environment for script authors, eg. using VS Code.
Would love to read your thoughts!
wow, thanks for getting back to me - it's an honor!
What I meant is a language specifically for the game, rather than a general purpose scripting language (with an little altered syntax).
For example, my engine currently uses scripts like this one:
// Playable characters
actor Dave {
full_name: "Dave Miller"
}
actor Bernhard {}
actor Syd {}
// Items
actor FrontDoor {}
actor FrontDoorKey {}
when Dave uses FrontDoorKey with FrontDoor then
setFlag FrontDoorOpen
@async Dave: "It's open now!"
Bernhard: walkTo Dave
end
---
This gets parsed into a bytecode for a (stack based) VM, which I specifically designed for the game with opcodes like OP_ACTOR_SAY or OP_ACTOR_WALK_TO.
I also created an LSP, so I can edit my game scripts in VS Code and get instant feedback like "Actor 'Larry' not defined" and things like that.
So, is Dinky more along those lines or based on Squirrel/LUA?
Thank you!
Add comment: