Thimbleweed Park is the first game of this type I’ve ever played. It was so good and the story was fantastic.<p>I recommended it so some friends and they didn’t care for the story or the art style so I’m not sure why my recommendation fell flat but I felt like I was playing a game version of Twin Peaks. Quirky but captivating!<p>I’ll have to give Delores an ol play-a-reno!
"Grumpy Gamer" is Ron Gilbert, responsible for SCUMM, Monkey Island, Humongous Entertainment, and more: <a href="https://grumpygamer.com/about" rel="nofollow">https://grumpygamer.com/about</a>
Interesting but one bit i disagree with:<p>> I've always skewed away from visual programming and dialogue engines. While they are great for beginners, getting real work done is problematic.<p>Having visual tools is certainly <i>not</i> just for beginners, i guarantee you that most AAA and many AA and even smaller projects use dedicated visual tools for things like dialogue. As an example see Obsidian's conversation editor described here [0] that they have used for several of their projects. For other examples see the dialog editor used in Witcher 2 (REDkit) or the editors used in Bethesda's games (the engine might be a bit clunky at times but the tools are largely visual, outside of quest-specific scripting of course). Witcher 2's tools also include visual quest and FSM ("steering") editors. These are all tools that are used to do real work.<p>Personally i have worked professionally in game tools for many years and visual tools are always an improvement over something basic. It is usually programmers that seem to want to ignore them, but i'm 100% sure that is because they can do most of the stuff with pure text (though rarely at the same speed as a good visual tool would allow, even if they think otherwise - note that i'm not talking about scripting here, this is often better done via a scripting langauge) and they do not like working with GUIs and such (i am one of the apparently rare programmers who likes working with GUIs) so they come up with excuses why their way is better.<p>Many things in games, including conversations (and perhaps high level quest flow, depending on the game), are better done with visual tools than text - especially if these tasks are to be done by non-programmers.<p>[0] <a href="https://jesawyer.tumblr.com/post/175082312536/im-curious-as-to-what-the-conversation-editor" rel="nofollow">https://jesawyer.tumblr.com/post/175082312536/im-curious-as-...</a>
We changed the URL from <a href="https://github.com/grumpygamer/DeloresDev" rel="nofollow">https://github.com/grumpygamer/DeloresDev</a>, which has the code, to the blog post that gives a bit more background.
It amazes me how much is available today to anyone even remotely interested. I still remember cousins having to record radio signal on cassette to later use on their computer.
For those interested in a more modern take on SCUMM, there's a new tool built for Unity: PowerQuest <a href="https://powerhoof.itch.io/powerquest" rel="nofollow">https://powerhoof.itch.io/powerquest</a>
I was always curious if there was a "first-class" port of the scummvm for canvas/webgl? I know there were efforts using emscripteen and all that but they all died because of discrepancies in architectures etc. Anybody aware efforts in this area to write scummvm groundup for the web?<p>I am really really really hoping the answer is no so then my next question would be - anybody interested in building one? :)
The author, Ron Gilbert, did a great fireside chat style talk at Handmade Con 2015 where he discusses developing games at Lucas Arts, and his indie work in progress at the time, Thimbleweed Park.<p><a href="https://www.youtube.com/watch?v=cktmhqXMsGI" rel="nofollow">https://www.youtube.com/watch?v=cktmhqXMsGI</a>
because it took me too long to find it
I think it is this:<p><a href="https://thimbleweedpark.com/" rel="nofollow">https://thimbleweedpark.com/</a>
Note, that actual game engine source is not available. That's a bit sad for users who want to run this game natively on Linux and other unsupported platforms.
Interesting, it’s written in “a custom language called Dinky that is based on and inspired by Squirrel”.<p>Is it common for games to use custom scripting languages? I thought it would be more efficient to use an off-the-shelf language - Lua seems to be the most popular?
The code is only half the game. Ron and crew had a wicked, warped sense of humour which played out in the puzzles.<p>Dinky was the name of an island in Monkey Island 2, assuming some in-joke there.
Delores: A Thimbleweed Park mini-adventure is a point-and-click adventure game for PC from the developer of Thimbleweed Park, a higher-budget kickstartered point-and-click adventure. Here's the into blog post: <a href="https://grumpygamer.com/what_i_did_during_the_pandemic" rel="nofollow">https://grumpygamer.com/what_i_did_during_the_pandemic</a>
It's a little sad he isn't interested in taking PRs to improve the game, even if I appreciate why: He actually believes in real testing.<p>One would hope a PR might at least be considered for inclusion when/if he does another update release of his own in the future.
From the GrumpyGamer post referenced on the GitHub page -<p>«The other downside is these really are the dev tools we used to make the game, and like most in-house dev tools, they are poorly documented and very crude around the edges.»<p>What the man said. Sigh.
If you like this, please have a look at some of it's ancestors, all gems:<p>Maniac Mansion<p>Zac McKraken and the Alien mind benders<p>Day of the tentacle<p>Loom<p>Monkey Island<p>... a whole other bunch I wish I had played too ..<p>...<p>Enjoy!
> <i>Don't believe the myth that programmers can test their own code. They can't.</i><p>Interesting take that I’m not sure I can agree with. Good programmers write good tests because, well, that’s one of the things that makes a “good” programmer. If you take a dedicated test writer out of the picture you must still have a good program with good tests.<p>The whole “blind spot” conundrum posited by the author can simply be solved by having at least 2 people on a project. Each one will look at the code differently and write tests differently.