I switched from Windows over to Ubuntu about a year ago, and the hardest part of this has been living without my old Windows gaming favorites, and of course Lexaloffle's games are very high on that list. Is there any chance that the games (especially Chocolate Castle) would ever be ported to linux? Or at the very least, are any of them playable using Wine? I googled around a bit looking for info but wasn't able to come up with anything, unfortunately.
Good news! I tried out Wine. I thought the program would be really difficult and require actual knowledge about how computers and Linux work in order to use, but it didn't. It was simple, and Chocolate Castle worked perfectly in it!
I have considered doing linux ports, but it's pretty low on my wish list. There isn't much demand, and I'm not super-keen on having another set of support issues. And now I have another excuse! (They are easy to run on wine). All of the games share similiar OS-level code, so should also run ok.
Just one tip: by default they use DirectX to blit each frame to the screen. I think Wine handles this pretty well, but if you notice a game running slowly (or not at all) you could try opening config.txt and changing windib to 1.
I've played the game more now, and the only problem I've been seeing is with the audio, which likes to cut out after a while. And the program window won't close when I exit, but that's a problem I have with a lot of native Linux apps and not just Windows ones used in Wine. I don't know if this would be related to the DirectX frame blitting, but I changed the windib to 1, and I'll let you know if anything changes.
Native Linux ports would be awesome, but I understand that there's a very low cost-benefit ratio there. But if things ever change and you get around to it, I'll be first in line and camped out in front of BMTMicro's offices a week before release.
@lexaloffle: I guess to make you change your mind we have to provide you with a set of wine supporting issues. :)
Anyway, maybe this information will be helpful to other linux users:
On Wine 1.1.40 Neko Puzzle 1.21 segfaults upon start. This can be fixed by copying SDL*.dll from a more recent game (I tried this with dlls from ZenPG 1.27 full and Chocolate Castle 1.07 demo, they all work ok).
Seriously, no Linux version of an SDL-based game? It probably couldn't even be called a "port", you'd basically just have to fire up "make" and you're done.
About the support - Why not just offer a binary -without- support? (Actually, make that two binaries - don't forget 64-bit users.) Since you don't officially support Wine either, at the very least we wouldn't be off any worse than before.
Don't get me wrong -- I am keen to make this happen, but not until I can justify the extra time spent. It's not quite as easy as firing up make. At the moment I maintain about 28 builds + customised versions (demo/full/affiliate versions * 2 OSs for each game). I need to test the distribution, installation and operation of each one every time there is a version change. This will improve with better automation & unit testing, but that itself takes time. Adding Linux (and 64bit) to the number of combinations won't help this.
It does use SDL, but it's not a magic bullet. Even doing the Mac port, I had a bunch of issues: video drivers give different results for unusual screen resolutions, storing player data and the level editor file browser works differently, using the clipboard and launching a web browser differs.
Yes, these are all simple problems with simple solutions, but as anyone who has released software to a large number of people can testify, there are a lot of them. I have considered just releasing unsupported versions early as you suggested, but I don't think I would get off that easily! It's a can of worms I want to open, but not quite yet. I'd rather do it when I can ensure some degree of quality.
My plan is to eventually get everything up and running in such a way that I can change a line of code, hit a giant green button I've rigged via usb, and everything will recompile, self-test, upload, update the web site all while I go and drink a cup of tea. It will be beautiful!
Indie developers often fall for a common pattern of releasing a few games, but then becoming completely occupied with porting, maintaining and promoting them. I've resolved to keep pushing forward with new games, so I have to draw the line somewhere.
I don't want to sound whiny.. I love working on every aspect of Lexaloffle and appreciate any votes of interest from users. Everytime someone mentions a game/port they're looking forward to, I probably spend about an extra day on it that I would have otherwise deferred (including gnaw's post).
I just want to pipe in and plea that you please consider the can of worms. (They're tasty.)
If the money:effort ratio is what's stopping you, remember that the Humble Indie Bundles showed that linux players are ready to pay more for games, likely in big part just to show support for producing for the platform. I'm not a marketing wiz so I don't know how to take advantage of this.
Wine is better than nothing, but 64-bit native game binaries make me warm and fuzzy inside. If you put up a vote to gauge interest, please make a blog entry or twitter so I'll catch it by the RSS feed.
edit: There's no feed for the blog?
Also this was primarily with regards to Voxatron, but obviously all and any linux support would be much appreciated by the community.
Heh, yeah I haven't got around to writing a feed thing for the bbs yet. I do post blog notifications to twitter though.
The Humble Indie Bundle is quite an exceptional case -- masses of users, many of whom could also be motivated by donating to the EFF & to make a public statement in the public sales stats. Other indies I've talked to who support Linux have either had marginal success or ended up burning a lot of time on it.
Voxatron seems to be gaining enough interest from Linux users to make it worthwhile though, so I'm keen. I have a growing collection of games I'd also like to port with not much more overhead, so with the extra interest from Voxatron it's kind of a no brainer.
I'm not very experienced with the finer details of producing linux distributables though, so anyone reading this who's keen to help, please check back sometime to look for linux testing threads! (and I'll see about getting an rss feeder working soon).
btw -- what is everyone's preferred style of distribution package?
lexaloffle: most distributions use either the RPM format or the DEB format. Due to differences in libraries in each distro, you may need to compile it on each of the distros, such as Ubuntu, Debian, OpenSuSE, Red Hat, Fedora, etc.
Alternatively, and less "linuxy", you could distribute the shared libraries with the package, and the package could just be a tarball.
Look at how OpenTTD does their distributing for each distribution.
If you need any assistance, the community will surely help you out.
Cheers Gekz. It looks like I'll go for the tarball option for now -- the only shared libraries I need are sdl & sdl_mixer, both of which are reasonably stable at present.
if doing a game for linux... look for the following distros :
- ubuntoo
- fedora
- debian
you might be able to get it to work with RHEL6 if you get it to work with fedora, but aim for fedora :)
but rather than a distro, put down the versions of the libraries you use in the documentation.
Hi, I'd be interested in a linux version of voxatron. I'm on ubuntu, which uses deb most commonly. I bought both humble bundles, and would love to get a copy of your game too.
I bought Mac version of the great "Jasper's Journeys", but I'd pay again for a native Linux version (and I'd buy Chocolate Castle as well).
Ah! Remember SDL on Linux has to rely on OpenGL for propper smooth scroll (vsync), you've countless examples on how to do it. Emulators like Mednafen or MAME have their sourcecode available to you to take a peak ;)
Alrighty - thanks for the suggestions. I have Jasper (and hence all my other games, in theory) running natively on ubuntu now. I'll post a test build here sometime soon.
One more issue -- is it cool to store player data in ~/.lexaloffle/game_name? Otherwise is there a good place to write a smallish amount of data (< 2MB) that is shared by common distros? I'd use $HOME rather than ~ to allow the location to be customisable anyway.
Also, if I don't distribute SDL/mixer libraries with the game, do you think most users are comfortable grabbing a copy of SDL manually? e.g. "sudo apt-get install libsdl libsdl_mixer" or similar. It seems like a bit of a pain, but other games I looked at required some command-line work to set up anyway, even if to chmod +x an installer.
vanfanel - that's interesting about opengl, thanks. I tried Jasper w/ the default driver and, indeed, there was a bit of tearing. I'll write an optional opengl backend eventually - but the good thing about straight X blitting is that it seems to run perfectly smoothly even with generic video drivers.
For storing game data, that would be a perfectly canonical way to save data in Linux :).
As for the manual distribution method, you could include a script that checks for the existence of the SDL libraries before the executable is run, and if not, LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH executable to get the included shared libs.
Neverwinter Nights from Bioware did it this way, except they just assumed you didn't have SDL and it defaulted to using the included libraries.
Including the libraries will improve the longevity of the game in case SDL gradually changes over the next 5-10 years, and causes compatibility issues in the future.
Of course, you could just open source the game... ;)
ok, cheers. That seems to be the most practical approach for now.
Troy Hepfner (Dirk Dashing) also recommends a similar method in his tutorials, which btw are quite a handy reference for anyone who stumbles across this thread.
I don't think SDL will break for a long time, but if I'm unable to support my games (or can't be arsed), I'll open source them anyway. I've also left instructions with trusted associates to do so if I get hit by a bus. (Don't take that as an invitation, all you crazy bus-driving Linux purists).
[quote]vanfanel - that's interesting about opengl, thanks. I tried Jasper w/ the default driver and, indeed, there was a bit of tearing. I'll write an optional opengl backend eventually - but the good thing about straight X blitting is that it seems to run perfectly smoothly even with generic video drivers.[/quote]
I just don't get this part, lexaloffle. Getting smooth scroll (no tearing) with default X backend seems to be impossible: X protocol just doesn't have a way to implement wait-for-vsync. You'd have to use an overlay or OpenGL for that.
SDL has several backends available in Linux: X11, openGL (not a backend but a context creation interface for openGL actually) , fbdev and directfb. Last two ones require a vesa-enabled kernel and all, so just ignore them (even if I DO use directfb to forve vsync on SDL games wich don't support opengl, I can't stand tearing).
Can you please explain it? :)
I shouldn't have said 'smoothly'. I mean, it still runs fast compared with opengl games that crawl along at several frames per second without video drivers. Not really a massive advantage, but nice to have as something to fall back on for Linux users that don't want to or know how to install vendor supplied drivers.
[Please log in to post a comment]
