Join us on our own very special Reddit: /r/Linuxers

Ron Gilbert, developer of Thimbleweed Park is switching to Linux

By - | Views: 24,448

Ron Gilbert is a name most in the game industry will know from the likes of Thimbleweed Park, and earlier works like The Cave while at Double Fine and they were even the producer on my all-time favourite RTS Total Annihilation. More than that, Gilbert was also the creator of the classic Monkey Island and it appears they're now attempting to switch to Linux.

Terrible Toybox, the actual team behind Thimbleweed Park are working on a new game and game engine too. They released Delores: A Thimbleweed Park Mini-Adventure in May 2020, as a small standalone title that acts as a prototype for their newer game engine. They even put up the source code for the Delores game on GitHub, although it's not under an open source license. It doesn't support Linux yet but that appears to be planned.

So what's the fuss about? They're switching their development flow to Linux and they've started blogging about the adventure too with a first post about their new hardware a few days ago. Seems they've settled on a Dell XPS 13 with Ubuntu Budgie. The question is: why are they doing it? As they said in the post:

My goal is to see how far I can get developing my new game on directly on Linux and not the Mac (I haven't developed on Windows in years). Can I ditch the Mac and go 100% Linux?

For working on the "game", this shouldn't be a problem once the engine runs on Linux. The few custom tools I use (Wimpy, for example) and all built from the same code the engine is, so once it's working under Linux, they should compile as well.

It's quite interesting to see more developers try out Linux, although not too surprising with how Apple is now again moving CPU architecture. Not just that though, as Apple have been getting more hostile for indie developers, with all sorts of extras being needed now and that's on top of the "Apple tax" that forces you onto their hardware. Gilbert mentioned this as well, with Apple being 'more paranoid and authoritarian' as time goes on.

Since their initial blog post it seems it went mostly okay, and they're continuing to learn and find the software they want. Will be fun to see how it all goes. Good luck, we're here if you need us Mr Gilbert and our Forum is always open. We're always happy to help game developers on Linux.

Article taken from GamingOnLinux.com.
Tags: Game Dev, Misc | Apps: Thimbleweed Park
62 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
52 comments
Page: «6/6
  Go to:

Creak 6 Aug
Quoting: mirvYou've given a very narrow view of what constitutes a game, though I'm sure that wasn't your intent. If you want to make a game that looks and plays like, say, Shadow of the Tomb Raider, then no you probably wouldn't create an engine from scratch.

But let's take the example of Star Swarm (I'll let you look that up). Particularly at the time, and I daresay it's still true, other engines couldn't handle what it was doing. Not without lobbing stupidly massive computing power at the problem. And therein lies the crux: requiring obscene computing power reduces potential customers, and also makes development an utter pain. Tailoring your own code base to the desired game type has performance, sometimes stability, and development benefits in many (not all) situations.

It's a balancing act of course. If an existing game engine does all you need, use it. If not, can it be modified to do what you need, and what effort will that require. Is it complete overkill, will it limit potential customers and sales, or will it provide more.

No Man's Sky. Existing engines couldn't handle the procedural generation requirements, as in literally weren't written to handle the data precision needed. The developers had to write their own engine.

Generic game engines are great for many developers, but if you overlay the use cases in a sort of Gaussian distribution, there's still extreme ends where a pre-existing game engine simply isn't suitable. That's because not all games are the same (thank goodness), and not all developers have the same level of resources available to them.

And I've ignored something else that goes into making a game: the reasons for making it. Particularly for indie developers, there are programming language reasons (a game is a great way to hone one's skills), personal satisfaction, of just plain freedom to play around entirely unconstrained by someone else's whimsy. Graphics aren't everything, after all.

You're argument about space exploration games is completely valid, I actually experienced it, but I think you're underestimating a lot the resources needed to build a game engine and the tools around it. In the end, you're the one giving a narrow view of what constitutes a game. You found one game type that proves your point and deduced it should invalidate everything I said?

To be clear, I never said all the games should use the same game engine, but nowadays game developers have choices. And as game engines improved over the years, I am sure about 95% of the games could be done with these game engines now. I would even say that with technologies such as DOTS in Unity, even huge space exploration games could be done with it (but it is still too experimental to start a game on it, yet).

TL;DR: their are exceptions of course, yet my points are still true for a crushing majority of game types. And I'm not pulling arguments out of my ass, I do have a lot of experience in developing both game engines and games.

As for the pleasure of writing a new game engine, I completely get it: I'm the first one wanting to create everything from scratch, because it's more exhilarating, but with the increasing quality required by players nowadays, as a game dev, you need to wonder if it is really worth it, and ask yourself: do you want to make a game? or an engine?

Quoting: ObsidianBlkIf I may add just my two cents on top of this...

If there were not some people out there that took on the challenge of making new game engines, then we wouldn't have the likes of Godot, Unity, Unreal, Game Maker, Cryengine, etc, etc. Furthermore, if *everyone* falls into the belief that it's not worth making a game engine, how many future engines with even better features or design methodologies may we miss out on?

The great many game developers out there may be best suited to make their game in a pre-existing engine. For those that are excited about going the extra (thousand) mile(s) and building something literally from the first bit onwards, it's those dedicated souls that keep the industry growing, give the others options, and allows everyone to build something new!
I think we do need more choices, but the situation changed a lot within the last decade. We went from very few public game engines (e.g. Unreal, CryEngine) that cost millions of dollars, to dozens of game engines that can go as low as completely free.

Of course, there will always be the need to create new ones, but at some point, game dev is a job on its own, and engine dev is something else. If a studio would really like to create a game engine, I would advise them to have at least one successful game before, so that they have enough resources to code their own game engine.


Last edited by Creak on 6 August 2020 at 4:44 pm UTC
mirv 6 Aug
View PC info
  • Supporter Plus
Quoting: CreakYou're argument about space exploration games is completely valid, I actually experienced it, but I think you're underestimating a lot the resources needed to build a game engine and the tools around it. In the end, you're the one giving a narrow view of what constitutes a game. You found one game type that proves your point and deduced it should invalidate everything I said?

It appears you're taking issue with me. I suggest you re-read what I wrote in a neutral method; I was providing counter arguments against someone who wasn't you, and because it seemed to me that there was an impression that all games should have features X, Y, and Z.

I simply don't see how you were otherwise trying to get that I've provided a narrow view, or using a single counter-example (actually I provided multiple) to invalidate anything you wrote.

Quoting: CreakAs for the pleasure of writing a new game engine, I completely get it: I'm the first one wanting to create everything from scratch, because it's more exhilarating, but with the increasing quality required by players nowadays, as a game dev, you need to wonder if it is really worth it, and ask yourself: do you want to make a game? or an engine?

I will say that "increasing quality required by players" is a statement I don't agree with in this context. How are you defining quality? Are you saying that someone writing their own game from scratch can't match the quality of using an existing engine? A game engine doesn't make someone a good artist, nor does it guarantee stability of the product over more custom code.

Please note that I'm not saying you're wrong, or right. Actually I'm saying that neither way is wrong or right, and there exists a whole lot of space for custom engines, generic engines, and the entire range of gaming complexity to coexist quite happily alongside each other.


Last edited by mirv on 6 August 2020 at 5:16 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.