I remember a game that lasted me six months, singleplayer on civ V (biggest map, slow time). But not every game is like this.

Usually, playing with your friends as an ally is less boring, as they can see your troops.

This is also a good candidate as a "mail-chess"-like (see freeciv 2's website).

A bit sad to hear this. Would love to hear the complete technical analysis of what happens here. The function names, actual differences, etc.

Is it floating point related, RNG related, other? Wine doesn't seem to have a problem with this. Wouldn't using some parts of winelib help? (It is LGPL, so definitely linkable against).

View this comment - View article - View full comments

Looks very interesting, I will however personally pass for now, as my graphics card died a few weeks ago, and I am considering a full upgrade, which won't happen very soon. Yet, I wish the best to the developer. 0.3 FPS is certainly not sounding ready for release, but at least it works :P

We love retrospectives on ports, it would be nice to have one.

View this comment - View article - View full comments

That makes perfect sense to me. In fact, I have been wondering about this rule for some time.

That, and free games (although there are some valid reasons to allow them, in this case).

_____
Edit two hours later, as it doesn't seem to be that obvious, and to elaborate a bit:

There are some costs associated with Steam. They need to pay for the development of the Steam client, website, infrastructure, store, support the ecosystem by submitting patches to the engines (Steam VR, Steam Audio, Steamworks). This admittedly doesn't cost much more if some developers try to game the system. The real issue is probably with the CDN: maintaining Terabytes of games and saves in various datacenters around the world, and handling support for various issues has a cost, however. The more games/people, the higher the cost. And it isn't fair to other developers to try to avoid Valve's cut (as it would result in a higher cut for the others).
Just to give an idea of the size of the infrastructure, according to Gabe Newell, in 2013, dota 2 updates accounted for 2-3% of the worldwide IP traffic when they were going live.

This is still valid for free games; although developers don't make money on these, so this is less profitable, and less unfair to other developers. But free games still drive gamers to the steam platform, and that may help Valve reach economics of size on their CDN, as well as gathering new people to market to. Moreover, there are often tradings cards or other involved, which can generate revenue (and this is probably not a coincidence). Free to play games are technically paid games.

View this comment - View article - View full comments

If you're a fan of strategy games involving lots of units, like Total Annihilation or Supreme Commander, you should seriously take a look at this.

Speaking of which, I wouldn't mind a port for either game :)
supcom 2 runs pretty well with wine, but I never bother.

I will have to check this out, though I tend to dislike the grid placement I could see in the trailer.

View this comment - View article - View full comments

Quoting: Perkeleen_VittupääIt's wonderful for them to provide these old classics truly available. We don't miss too many classic SW titles no more! Episode I: Racer would be nice...

I am still longing for a star wars Galactic battlegrounds port...

View this comment - View article - View full comments

Quoting: gqmeloMost libraries will break with major updates, so you should bundle almost all your dependencies. But there are some libraries that should not be bundled, you should just use what the system provide instead. This page was not updated for a long time but it's still relevant: https://freegamedev.net/wiki/Portable_binaries#System_libraries_that_cannot_be_bundled [External Link]

I worked on a company that developed OpenGL applications and using this approach we were able to build on CentOS 5 and run on Ubuntu 16.10, for example. That's 9 years of backward compatibility.

"Bundling" can be interpreted differently form statically linking, though. I usually agree with "bundling"/providing the shared libraries along with the executable (and maybe a LD_LIBRARY_PATH "hack" in a launcher script), but not with static linking.

The only "valid" reason I can think of for statically linking executables is to distribute your program as only one binary. But even then, there are better options (sfxs, flatpack-like files with an embedded filesystem image or archive), and it only concerns a very nice portion of all applications (usually, portable ones).
Link time optimization and other optimizations are another reason it could be useful, but that's not true in practice (and ld can perform lto on shared objects as well, IIRC).

But yes, carefully pick the libs you bundle. To me, the general rules are:

• Libs everyone have (double check everyone *is* everyone). Don't bundle them, dynamically link.


• Libraries provided by a third party as part of a special contract with your studio/company: provide them as .so


• Internal libraries developed by your studio/company: statically link them, perform a monolithic compilation with them or provide them as .so depending on your needs or update/modding/debug policy


• Relatively common libraries that are well maintained: provide them with a .so, but prefer the ones on the system (query ld folders, add them to LD_LIBRARY_PATH, then add the folders they are in to LD_LIBRARY_PATH, essentially what Steam is doing)


• "wild" libraries that are not very well maintained, or can break the API (early development version, for instance): avoid them, you will probably run into problems a few years down. If you must use them, provide them, don't statically link them but prefer them to the host libraries. That way, you make it possible to tinker with them if it stops working, but they should work the same way regardless of the system.


• Prefer open source libraries whenever possible (still avoid the previous case): generally well maintained, people can fix them easily if they are broken a few years down the line, or write wrappers for them in the worst case.


• Whenever possible (and that's usually a more general software rule), avoid complex dependencies. Both for the libs you choose (they should depend on a minimum of other libraries) and for your application. Bonus points if you can enable/disable some dependencies via a config file (though you may have to manually load your libraries. It's not *that* complicated, and as a bonus, you can gracefully fallback and disable features)

Do you agree with those, or would you change/add something?

View this comment - View article - View full comments

Do not lose hope just yet. RCR had a NES port!
(I believe it started as a homebrew NES project, actually)

View this comment - View article - View full comments

This would set a nice precedent. I hope we'll eventually get all star wars games :)

(OK, I'm dreaming a bit, but hey)

View this comment - View article - View full comments

Looks quitte Nice, it's a shame it probably requires Linux 3.11, though...

View this comment - View article - View full comments

Quoting: GuestGreat article Liam,

One of my worries for Linux is how should developers code their programs and place all their folders and files so that 5 years down the line with newer hardware, kernel and distro and any updates associated, it can still be guaranteed that our purchased software will still be forward/backwards compatible and run? I personally find it annoying when your system is running fine for 2 years or so and just works, then have to do an update to the latest distro to get game x to work just to find you have to hunt down and figure out how to install xyz library or package to get an old game or software running again.

I'd like to point out that the community is great generally and with a little googling and patience one generally finds answers to solve your problems, for myself I guess I should save all those sources of help and index them all in a text file of sorts.

I second this. Usually this can be achieved by NOT STATICALLY LINKING the libraries (which is one of the reasons to have them in the first place). The libraries get updated (especially if they are open source), and make the games run in their new environment. This is why LGPL/zlib2 (iirc) is such a great thing :)

View this comment - View article - View full comments