Slashdot Mirror
Where Can I Find Linux Porters?
David asks: "Many small software developers would love to get their software up and running on Linux, but where can competent Linux porters be found? I ask because, a while ago, I released a shareware game called Lugaru. I developed it for Mac OS with the intention of porting it to Windows and Linux. I was able to easily find several developers willing to port it to Windows at a reasonable cost (a fair portion of the sales) but I am clueless about how to find people with the Linux expertise. It is frustrating because I get many emails and forum queries asking me about a Linux version. I really want it to happen and am willing to pay - the problem simply is that I don't know how to go about finding Linux developers. So, I ask Slashdot."
I have a small team of Linux developers that are looking for some work of this nature. We would be more than happy to help you. Send me an email or message on /.
I'll update my profile to have my current email address. krakrjak at gmail dot com
He made it clear this is a commercial project, so Sourceforge is obviously not where he should be looking for help. For those out of the know, Sourceforge only assists those who have open source projects.
Linux trains
Linux cruise ships - plus you can learn how to code in Perl at the same time on a cruise.
But seriously, just because you want to port something doesn't mean other people want to port it, so you would be better off trying to contact people interested in your game in the first place, who can code for Linux or who have ported before, as they are most likely easily "rewarded" by special insights into how the game works, or you could also reward them with special game tokens (like having an island named after them or a building in a standard or Linux-only map) or other things.
Hope this helps.
-- Tigger warning: This post may contain tiggers! --
Ask Icculus.
Ryan C Gordon is the one to thank for the Unreal ports, and a Linux game porter community surely exists at his site.
Check out http://icculus.org/
The game already uses SDL, OpenGL and OpenAL. I doubt this guy needs QT nor wxWidgets.
A couple thoughts.
/dev/dsp is always going to be the sound card and /dev/js0 is always going to be the joystick. If you want to detect them, great, but let the user specify.
/dev/js0 on a particular boot and /dev/js1 on the next boot.
First, I've seen various system-specific mailing lists be used by people who are interested in hiring someone to do a job. Perl-specific mailing lists, SDL-specific mailing lists, and so forth. This is one way to find people familiar with a system.
Second, if you are doing a closed-source game for Linux, be aware that binary compatibility is a *bitch*. I have done a fair amount of work on getting older Linux binary games that I've purchased to work, and I'm pretty much convinced that it's not reasonable to just ship "a Linux binary" in the same sense that one ships a Windows binary that one simply expects to work. In the past, companies that have attempted to do Linux ports of their games have generally not had a binary that continues to work for more than a year or several. The Linux world is not really oriented around guaranteeing binary compatability -- vendors do not generally feel constrained to make sure that software written for their distro a few versions back continues to work. This is *not* a minor undertaking. Much as I love Linux, I would suggest that a better target for a "second platform port" would be the Mac. You appear to have done that, and if you're really pleased with the results, you've made your money back and all, then it might be worthwhile to consider Linux. In general, though, folks attempting to do commercial Linux releases have not done very well -- I understand that Jagged Alliance 2, for instance, shipped something like a couple hundred copies in the first few weeks. That was a pretty high-profile game with a solid port, and no fancy requirements (3d, etc).
Third, be aware that the state of 3d under Linux sucks. I'm sorry, but that's how it is. ATI and NVidia ship binary drivers that produce friction from the kernel folks. The fastest cards with open-source drivers are some of ATIs, and those drivers are *not* rock-solid. Linux was actually better off in the 3d arena a couple of years back, when Matrox had good open source support and ATI was allowing open source drivers -- the state of Linux 3d has actually regressed.
Fourth, if you do this, if at *all* possible, use the existing standard libraries. SDL is the closest thing to a standard game development environment out there across Linux distros. SDL_image and SDL_mixer are also good sidekicks. SDL has lots of oddball competitors that are more or less a pain to get running on various systems.
Fifth, take a look at the strategies that Loki and the other Linux game developers used for deploying patches, for dealing with shared/static libraries, for handling installation/uninstallation, and so forth. The installer world for Linux is not currently suitable to do a Windows-style "download this file and use it" and vendors currently aren't really set up (with the possible exception of Linspire) to provide for-sale applications through their package management system.
Sixth, *let users specify devices*. Nothing is more annoying than some random developer who decides that
Seventh, be aware that Linux currently is not capable of maintaining joystick orderings, so if the user has two joysticks, one may wind up being
Eighth, furries rock. Good job.
Nineth, while this almost certainly isn't appropriate for your game or your scale of operation, be aware that some of the most technically successful cross-platform vendors have built VMs and then targetted that VM. Sierra's AGI and SCI engines, Lucasarts' SCUMM, Infocom's Z-engine (and the free competitor, TADS) all made for generations of highly-portable adventure games (yet none of these games were extremely sluggish or technically limited for their day).
Tenth, let your users toggle between full screen and wi
Any program relying on (nontrivial) preemptive multithreading will be buggy.
The source compatibility mode is not restricted to x86 machines!
You take the source code for the program to be 'ported' and the source to wine (available under the LGPL) and compile them both on your target machine. The result is a binary (with the WINE libraries compiled in) that will run on any (non-x86) architecture running Linux.
That's how it works in theory (your real life experience may differ).