Salvation Prophecy [update: Steam Release]

[bstone]

lol. Got my lazy ass to find the way and redeem a product code. Now I could finally give you my vote. Good luck!

[Mind Calamity]

Good job on the Linux port so far, looking good. It should give you more support, since the Linux gaming community is bigger than it's ever been (and is still growing).

[drwbns]

Voted for you awhile back Excellent job btw, especially working on it alone. When you get rich and famous, send me a postcard

[scrawl]

Really excited about the linux port, keep it up

[dudeabot]

i tried voting a lot of timnes already but the page just keeps refreshing..

doesnt work for other projects as well

maybe they have something agasint Brazil? xd (or maybe its just me =p)

anyway, good luck on the poll

[duststorm]

Wow, that was fast on the linux progress.
Great that you are working on it!

[Jabberwocky]

Thanks a lot for the support guys.

i tried voting a lot of timnes already but the page just keeps refreshing..

Yeah, that happens to me sometimes too. It seems temporary though - I just wait and come back a little later and everything works fine.

For sure, a lot of people have been very supportive about the linux port. I guess if there's a silver lining to the long process of getting on Steam, it's that it gives me time to work on that. It's the perfect project since I don't have a lot of money for new artwork, but working on linux costs nothing but time. My biggest issue right now with the linux port is that the input seems really flaky compared to windows. Does anyone else who uses OIS experience this problem? I looked at the OIS linux code and it might have something to do with the way it handles the (invisible) mouse pointer hitting the edge of the window, then "teleporting" it back to the center - perhaps when that happens it loses some precision on that frame. If I can't get it worked out, I may need to look into another input system for keyboard and mouse - maybe SDL, unless anyone else has other suggestions.

With the most recent batch of greenlit games, Salvation Prophecy has moved into the 30s. So if I can keep up interest in the game, hopefully it's only a matter of time.

[Jabberwocky]

I might have been a little hasty blaming OIS - my mouse feels a little "jumpy" on the desktop too. You just don't notice it as much unless you're in-game and the camera turns with the mouse movement. Maybe I'll need to pick up another mouse and see if it's just a problem with this particular one.

[pinaster]

voted, again!

[Jabberwocky]

I sent a review copy of the game over to IndieGameHQ, and they really dug it. One of the guys there, Nate, made a new gameplay trailer for the game which I think turned out pretty good:

[youtube]REzCjv1P1As[/youtube]

It's very appreciated when a nice surprise like this lands from out of nowhere. I think Nate did a better job of capturing the gameplay in a much shorter and more concise video than I accomplished myself with the earlier videos.

In other news, the linux port is still going strong. I just finished converting all my shaders to glsl, which is actually mind-numbingly boring work. If I'd known how annoying this would be, I'd have written way less shaders for my game. I'll be looking into building a linux installer pretty soon, and so far nixstaller looks the best.

Any linux experts out there know whether a binary compiled on Ubuntu will likely work on other distros, provided that any non-standard linked libraries are included with the installer?

[duststorm]

I'll be looking into building a linux installer pretty soon, and so far nixstaller looks the best.

Any linux experts out there know whether a binary compiled on Ubuntu will likely work on other distros, provided that any non-standard linked libraries are included with the installer?

Building a binary package for linux is hard, so be sure to read up on it. Simply creating an installer will not solve your issues. Maybe even on the contrary, nixstaller does not seem to be widely used or known (I didn't know about it, it's not in the debian or ubuntu software repository either, development does not seem very active, ...) so using it might make things harder than they could be.
I would opt for a simple .tar.bz2 archive that one extracts somewhere in the /opt folder (you can provide an installer script that does this for you if you want).
Also a lot of linux users don't like the visual style and workflow of windows-like installers. They are pampered with packages that simply work.

Have a look at some other applications that have managed to do this to get some ideas. Off the top of my head, some applications that successfully did it:
chrome, skype, qt libraries, guitar pro
You will basically have to include all the libraries that you are using, compiled for a standard x86 or x64 architecture. You should even be careful with dynamic linking to standard libraries (such as the c++ standard libstdc and glibc).
Be sure to target LSB standards, and use the LSB app checker to verify how compatible your application is. Tools such as ldd are your friends too.
It's quite tricky, the base rule is to package as much libraries as possible, but there are some libraries you cannot package without breaking things.

Some literature to get you started:
http://stevehanov.ca/blog/index.php?id=97
http://freegamedev.net/wiki/Portable_binaries

I wish you a lot of luck!

[areay]

As a Linux user who has recently purchased and played the latest desktop Humble Bundle I can tell you that most of the installers used 'nixstaller' and everything seems to have been built on Ubuntu and released as a binary. I run everything on Fedora and had no issues with any of the games (apart from 'shatter' which for some reason wasn't compatible with intel GPUs on x86_64).

I have another HB game called 'Lugaru' which is actually an Ogre3D game so I grabbed a quick list of shared libraries that the main binary uses

Code: Select all

[areay@arrakis lugaru]$ ldd ./lugaru
	linux-gate.so.1 =>  (0xf774b000)
	libSDL-1.2.so.0 => /home/areay/lugaru/./libSDL-1.2.so.0 (0xf769b000)
	libopenal.so.1 => /lib/libopenal.so.1 (0xf7624000)
	libstdc++.so.6 => /home/areay/lugaru/./libstdc++.so.6 (0xf7538000)
	libm.so.6 => /lib/libm.so.6 (0x47625000)
	libgcc_s.so.1 => /home/areay/lugaru/./libgcc_s.so.1 (0xf752c000)
	libc.so.6 => /lib/libc.so.6 (0x47032000)
	libdl.so.2 => /lib/libdl.so.2 (0x471e6000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x471ed000)
	librt.so.1 => /lib/librt.so.1 (0x4721f000)
	/lib/ld-linux.so.2 (0x4700f000)

[areay@arrakis lugaru]$ ls
Data             libstdc++.so.6  README-linux.txt  Troubleshooting.txt
libgcc_s.so.1    lugaru          Readme.txt        uninstall-lugaru.sh
libSDL-1.2.so.0  lugaru.png      Screenshots       xdg-open

As you can see it's pretty simple; Ogre3D's libraries must be linked statically and the few non-standard things it does need (SDL and OpenAL) are in the package repository for all Linux OSs. In fact, for some reason, Lugaru actually includes the stdc++ and SDL libraries that it uses in the root of the game's install dir (licenses prevent static linking maybe?) so that's another way to solve problems.

Like Duststorm, I'm keen to help out with your port as I'll be a customer when you get round to supporting my darn platform!

[ppClarity]

Linux has its own flavor of DLL-hell that can be worked around without too much pain. A common method is to install all of the dependent dynamic libraries in a subfolder and use either the rpath compiler directive when compiling the binaries or to use a wrapper script to set the LD_LIBRARY_PATH environment variable to set the library search path priority. I'm guessing that nixstaller automates this process.

BTW, shipping libstdc++ or even libc itself is not uncommon.

[Jabberwocky]

Thanks duststorm, areay, ppClarity -
this is exactly the sort of discussion I was hoping for.

Regarding nixstaller - as areay mentioned - I chose it because of it's popularity among the Humble Bundle games. Torchlight uses it, which I have installed on my linux box, and:
1. I liked how it worked
2. Where it's been discussed, people seem pretty happy with the torchlight installation process.
3. It's nice to have an example to look at.

Also, There are a lot of other nixstaller features I like, such as:

• The installer can register the software in the user's package manager (rpm, dpkg, pacman and slackware's tgz are currently supported). This allows the user to easily remove, view or update your software. In case the installer could not register the software, an uninstall script will be installed.
• ‘Package Mode’ also allows advanced dependency handling. ‘Dependency Packages’ can be used to verify the existance and compatibility of dependencies and if required install missing files.
• Creation of desktop menu entries following the freedesktop standards.

I've been looking at both LD_LIBRARY_PATH and rpath as methods of packaging up my own shared libs, and I'm leaning heavily towards rpath. Having the lib path baked right into the executable seems more bullet proof. Also, LD_LIBRARY_PATH seems to be commonly critiqued.

Here's the ldd output for the Torchlight binary:

$ ldd Torchlight.bin.x86
linux-gate.so.1 => (0xb7783000)
libOgreMain-1.6.5.so => /usr/local/games/Torchlight/./lib/libOgreMain-1.6.5.so (0xb7377000)
libCEGUIOgreRenderer-1.6.5.so => /usr/local/games/Torchlight/./lib/libCEGUIOgreRenderer-1.6.5.so (0xb736a000)
libCEGUIBase.so.1 => /usr/local/games/Torchlight/./lib/libCEGUIBase.so.1 (0xb711c000)
libfmodex-4.36.21.so => /usr/local/games/Torchlight/./lib/libfmodex-4.36.21.so (0xb6fc3000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6f96000)
libzzip-0.so.13 => /usr/lib/libzzip-0.so.13 (0xb6f8e000)
libfreeimage.so.3 => /usr/lib/libfreeimage.so.3 (0xb6e9c000)
libpcre.so.0 => /usr/local/games/Torchlight/./lib/libpcre.so.0 (0xb6e6b000)
libXaw.so.7 => /usr/lib/i386-linux-gnu/libXaw.so.7 (0xb6e02000)
libSDL2-2.0.so.0 => /usr/local/games/Torchlight/./lib/libSDL2-2.0.so.0 (0xb6d3b000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb6c07000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb6bf5000)
libXft.so.2 => /usr/lib/i386-linux-gnu/libXft.so.2 (0xb6bde000)
libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 (0xb6bda000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb6ba6000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6ba1000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6abc000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6a8f000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6a71000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb68c7000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb68ac000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb6812000)
libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xb67b5000)
libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb67ac000)
libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb6792000)
libglut.so.3 => /usr/lib/i386-linux-gnu/libglut.so.3 (0xb675a000)
libGLU.so.1 => /usr/lib/i386-linux-gnu/libGLU.so.1 (0xb66e5000)
libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0xb660c000)
libjpeg.so.8 => /usr/lib/i386-linux-gnu/libjpeg.so.8 (0xb65b5000)
libmng.so.1 => /usr/lib/i386-linux-gnu/libmng.so.1 (0xb6531000)
libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0xb6512000)
libIlmImf.so.6 => /usr/lib/libIlmImf.so.6 (0xb644f000)
libHalf.so.6 => /usr/lib/libHalf.so.6 (0xb640a000)
libIex.so.6 => /usr/lib/libIex.so.6 (0xb63f1000)
libraw.so.5 => /usr/lib/libraw.so.5 (0xb6364000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb633a000)
libgomp.so.1 => /usr/lib/i386-linux-gnu/libgomp.so.1 (0xb632a000)
libXmu.so.6 => /usr/lib/i386-linux-gnu/libXmu.so.6 (0xb6310000)
libXpm.so.4 => /usr/lib/i386-linux-gnu/libXpm.so.4 (0xb62fe000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb62dd000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb62d3000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb62a9000)
/lib/ld-linux.so.2 (0xb7784000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb62a2000)
libnvidia-tls.so.295.40 => /usr/lib/nvidia-current/tls/libnvidia-tls.so.295.40 (0xb629e000)
libnvidia-glcore.so.295.40 => /usr/lib/nvidia-current/libnvidia-glcore.so.295.40 (0xb4668000)
liblcms.so.1 => /usr/lib/i386-linux-gnu/liblcms.so.1 (0xb462f000)
libImath.so.6 => /usr/lib/libImath.so.6 (0xb4629000)
libIlmThread.so.6 => /usr/lib/libIlmThread.so.6 (0xb4620000)
libjasper.so.1 => /usr/lib/i386-linux-gnu/libjasper.so.1 (0xb45cb000)
liblcms2.so.2 => /usr/lib/i386-linux-gnu/liblcms2.so.2 (0xb457f000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb4576000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb4572000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb456a000)

And the contents of the /usr/local/games/Torchlight/lib directory:

$ ls
libCEGUIBase.so.1 libfmodex-4.36.21.so
libCEGUIExpatParser.so libOgreMain-1.6.5.so
libCEGUIFalagardWRBase.so libpcre.so.0
libCEGUIFreeImageImageCodec.so libSDL2-2.0.so.0
libCEGUIOgreRenderer-1.6.5.so OGRE
libCEGUIOpenGLRenderer.so plugins_opengl.cfg

The OGRE subdir contains all the plugins.

So in the case of Torchlight, only a small number of game-specific shared libs are packaged up:

• CEGU
• FMOD
• Ogre
• SDL

Which incidentally is pretty much the exact same set of libs I use. It seems to rely on the standard installed libraries for everything else.

So with the rpath / nixstaller route, I feel like I have an established, fire-tested example of a very popular game, built with similar libraries in Torchlight.

I understand that binaries could eventually break if new, binary-incompatable versions of linked libraries are released. Practially speaking, I'm not sure how often this happens with modern versions of linux. Also, nixstaller has an interesting feature:

http://nixstaller.sourceforge.net/viewp ... ?page_id=1

Dependency handling
When using 'Package Mode' (see above) Nixstaller can also handle software dependencies. Required dependencies can easily be found by scanning binaries for required shared libraries. It's also possible to specify your own method for gathering required dependencies. In case a dependency is missing or is (binary) incompatible the user will then either be notified or the installer can install it's own supplied version.

Nixstaller knows two dependency types: simple and full. Simple dependencies don't provide any files and are purely used to let the installer know what to find. If a simple dependency is not found (or incompatible) the installer will warn the user about it. Full dependencies are used to ship dependency files with the installer. In case a full dependency was not found (or incompatible) these files will be installed. Any installed dependency files are installed to a seperate place so they cannot disturb or be disturbed by for example package managers. To keep the size of the installer low one or more full dependencies can be made 'external' so the installer can download them when it needs to.

Again, thanks for your thoughts, and please jump in if anything I've said seems off.

[scrawl]

You can also take a look at StuntRally's binary linux release for a reference. I'm building it on Ubuntu 11.10 VMs and so far I'm not aware of any distribution it's not working on. It's not that hard, you just have to be careful which libs you include and which not

[alexiusnexus]

voted! better late than never

[kneeride]

omg that trailer is awesome!

[Zonder]

When you have got the linux / mac /windows versions all sorted you could consider joining into humble bundle indie. Only if sales have died down of course

[drwbns]

What surprises me is how polished Salvation Prophecy is compared to Kenshi, yet Kenshi got voted into Steam already. I know were kind of talking apples and oranges here but I really thought Salvation Prophecy easily would have been voted for first due to its much further progress. Anyone want to add to this?

[Jabberwocky]

omg that trailer is awesome!

Thanks!

When you have got the linux / mac /windows versions all sorted you could consider joining into humble bundle indie. Only if sales have died down of course

For sure, the humble indie bundle is a goldmine for indie games. I don't know much about mac programming, but the linux port would probably make it easier, since I have the game running off of opengl now.

What surprises me is how polished Salvation Prophecy is compared to Kenshi, yet Kenshi got voted into Steam already. I know were kind of talking apples and oranges here but I really thought Salvation Prophecy easily would have been voted for first due to its much further progress. Anyone want to add to this?

I think there's a couple things which limit Salvation Prophecy on Greenlight compared to Kenshi.
1. Salvation Prophecy has a huge art scope (many planet landscapes, space scenes, interior station scenes, not to mention all the different space ships and characters). Kenshi has one scene (a desert). From a greenlight perspective, that's a smart move, since basically you're putting all your effort into making one thing awesome. Most of your greenlight votes come from your screenshots and video, and "lots of pretty cool stuff" (Salvation Prophecy) probably doesn't have the same impact as "one really awesome looking thing" (Kenshi) in a video.

2. The Kenshi dev did a great job of building a community for his game, including stuff like crowd sourcing. I did a worse job on that, focusing almost exclusively on development. As a result, I have a completed, stable game (which is good), but less of a community to drive greenlight votes (which is bad).

3. It's tough to say for sure, but space sims may just be a smaller niche than Kenshi's roaming RPG game style.

Greenlight didn't exist until just after Salvation Prophecy launched, so the landscape of how best to approach an indie game has kinda changed. Before, I would have said it was more important to have a completed, stable, and polished game to get on Steam (not that Salvation Prophecy is totally polished art-wise, I still get occasional flak for my character animations). Now, with Greenlight, community is far more important. This is a good lesson for me and all indie devs.

I'm happy for Kenshi, and I think the dev has done a lot of great things with that game.

[drwbns]

Definately insightful, I say well done either way

[scratchyrice]

Well done for being greenlit today!

Scratchy

[Jabberwocky]

Thanks Scratchy!
It's been a long time a'comin.

[drwbns]

Oh sweet, kudos to you again Jabberwocky

[Klaim]

Nice, well done!