When I try to run the start.sh file in Mint 20 Cinnamon I get this error:

start.sh: 6: Bad substitution
start.sh: 8: source: not found
start.sh: 11: get_gameinfo: not found
start.sh: 12: get_gameinfo: not found
start.sh: 13: get_gameinfo: not found
start.sh: 32: define_option: not found
start.sh: 35: standard_options: not found

I looked at the lines of code that are causing these errors but I don't have enough experience with shell scripting so I'm not sure exactly what's wrong or why. It deems like it's not recognizing a bunch of variable names or other definitions.

Also, I opened the gameinfo file and it just says:

Trine Enchanted Edition
2.0.0.2
2.12 build 508

I assume that's probably correct because I haven't changed it.

How are you running it, exactly? It looks like it's using busybox instead of bash. The script itself invokes /bin/bash, so either /bin/bash is linked to busybox on your system, or your method of invocation is ignoring the script's #! and using its own shell (maybe /bin/sh, which may be busybox). I suggest either renaming the script to "start", or invoking with /bin/bash start.sh.

Note that I can't run Trine on my machine, either, but for different reasons: the gog-shipped libraries are not compatible with my system (fixed by moving lib out of the way if you use start.sh) and the game itself does nothing on launch (something I have yet to fix; I just run the Windows version under wine, instead).

I'm not sure what busybox is, but I was using this command:

sh start.sh

I didn't realize that I was supposed to use bash instead, so now I tried this:

bash start.sh

And I got this error:

Running Trine Enchanted Edition
./bin/trine1_linux_launcher_32bit: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Are you sure it's bash instead of sh? Anyway, I checked in the lib folder and there are all kinds of files but not the one that it wants. But it doesn't even specifically say that's the folder where it belongs, so I'm not sure whether that even proves anything.

EDIT: And I just noticed that the first line of the start.sh file says that it's using bash, so I guess I should have noticed that before but I was just looking for the errors themselves. Most of what I use is sh instead of bash.

EDIT: I also tried running the game/trine1.sh file using:

sh trine1.sh

and

bash trine1.sh

Both times I got this error:

./bin/trine1_linux_launcher_32bit: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Since it's executable, the command should've been just:

./start.sh

As I said, plain sh is probably either busybox or dash (two minimal shells Debian derivatives often use instead of bash as /bin/sh). I blame gog for naming it "start.sh" instead of just "start". I personally don't use their startup script, anyway. That means you need to install the 32-bit GTK-2 libraries. Since I use gentoo, rather than Mint or another Debian derivative, I can't tell you exactly how to do that. Sorry. After you get them installed, you may need to install more as it will only tell you the first one it failed on.

Oh, great. So it could be like 100 things in a row that I have to find and install one at a time. Well thanks anyway.

But just to clarify, I got the same error when I ran it using:

./start.sh

And I didn't realize that's a different shell than using the sh or bash commands. That's weird. If you don't use their startup scripts then how to you access the game? The startup scripts seem to just get it to run, but not actually represent any sort of executable file for the whole game itself; I mean how could it? It's only like a page of code. So what I'm wondering is, where is the actual file to run? Maybe I can just run that directly, can't I?

Right. It would've gotten you past your first problem, though. it's the same as running "/bin/bash start.sh", except less typing and a guarantee that you're using the shell the script was meant to be run with, without thinking about it. I have my own convoluted way of doing things. I install games as root in /usr/local/games, and run them with custom scripts that use a wrapper I wrote called dogame. My trine script looks like this (but gog's forum will remove the indentation, so pretend there are spaces in front of exec):

-------------------
#!/bin/sh
dir=/usr/local/games/Trine\ Enchanted\ Edition/game
cd "$dir"
if [ "x-c" = "x$1" ]; then
exec dogame "$dir/bin/trine1_linux_launcher_32bit"
else
exec dogame "$dir/bin/trine1_linux_32bit"
fi
------------------------

There you can see that the actual game is game/bin/trine1_linux_32bit and the launcher/config program is game/bin/trine1_linux-launcher_32bit. No, you will get even more errors without adding lib and game/lib/lib32 to your LD_LIBRARY_PATH first. Then you will get the same errors as before. The only advantage to setting LD_LIBRARY_PATH to include lib and game/lib/lib32 so you can run the binary directly is that you can also get an immediate list of missing libraries, using:

export LD_LIBRARY_PATH="$PWD/lib:$PWD/game/lib/lib32"
ldd game/bin/trine1_linux_32bit | fgrep "not found"
ldd game/bin/tine1_linux_launcher_32bit | fgrep "not found"

Note that you may also need to bypass one or more of the supplied libraries by adding /usr/lib32 and/or /usr/lib in front of the LD_LIBRARY_PATH, and that if it's already set in the environment, you will lose what's set (some distros use that to select the opengl driver, for example).

Or, to do the same thing with less hassle, just edit game/trine1.sh, and change the last line to add ldd after the semicolon.

Or, if you trust frozenbyte to do the work for you, you can try running game/bin/install_dependencies_ubuntu_64bit.sh.

Actually, I had tried running the script to add dependencies, but this is what it says:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libGLU1:i386
E: Unable to locate package libportaudio0:i386

But concerning the lib files, are you implying that these libs (like DLLs as far as I can tell) aren't referenced directly by the executable files, and therefore need instead to be referenced by a script that runs an executable file? That's really weird! Of course, my only experience with using DLL files is in Windows, but there the exe files always have the references built into them. To not have that makes the file less complete and incapable of running independently, right? So then how can it even really be considered an executable file?

I probably should've just referred you to the ./play.it thread or the ./play.it page for this game instead of leading you through the steps, since, as I already mentioned, I don't use a Debian/Ubuntu derivative and can't tell you how to fix dependency-related issues. vv221 and friends have made it so that you can just create a .deb package for the game and install it. Just follow the instructions for Debian. In Linux and Windows both, the executables require libraries, and refer to the libraries they need by name. They search for those libraries in a particular path, and what you're doing in the script is adding places for it to look. You can do the same thing by setting PATH in Windows. The game ships with some libraries, and if you want to use them, you have to add their location to LD_LIBRARY_PATH so the executable can find them. You'll notice that my script didn't set LD_LIBRARY_PATH at all; that's because my system actually has all the needed libraries in the standard path already. Also, just like in Windows, missing libraries need to be provided externally to the executable.

Oh, well that clarifies it. Thanks anyway. I don't know why some Linux games install and run with no problem at all, though others are a huge pain, even though anything on Windows installs and runs easily. I think I'll just play the Windows version instead. I prefer to play the Linux games when I can, so that I don't have to keep restarting my computer to go into Windows every time, and then back into Linux after I'm finished, but I guess I just have to do that for some games. Oh well. Thanks again.