QuoteAnother thing I want to mention, our game required Mono, but most of the users didn't have it installed or had an incomplete version and many actually had a corrupted installation. We solved that problem by providing a special bundled-mono with the game. But that was one hell of a task to overcome. Which again, doesn't make supporting Linux easy. However, there might be some improvements in this regards after merge between Microsoft and Xamarin.

You should always bundle everything your game needs (except libstdc++ which is installed everywhere and forcing your version prevents users from using updated gpu drivers or breaks them completely). You don't want your user to have to deal with missing dependencies, or updated libraries that no longer work. So they were actually forced to do the right thing, they just don't know about it.

View this comment - View article - View full comments

Very much reminds me of Eschalon, a game I enjoyed quite a bit.

View this comment - View article - View full comments

Since when is Unreal Tournament an open source game?

View this comment - View article - View full comments

I started playing NS2 a few months ago (unfortunately just on Windows) and I have to say I enjoy the game very much, especially when there's a decent team in which people communicate with each other (you need to pick good servers and don't be afraid to change them when there's no communication going on in your current team). It is a great tactical game, not a mindless shooter. The developers also stated they return to the game and plan big changes to revive the user base, which is great as well:
http://unknownworlds.com/ns2/alright-mates/
http://unknownworlds.com/ns2/dev-update-new-communication-channels/

However, it's very sad that the Linux support is so problematic. On opensource radeon driver, I can't play this game at all, it crashes during map loading. After some debugging, it seems that the game runs out of memory (just 4GB available for the process, because it's a 32bit game). Mesa drivers are extremely memory hungry when it comes to shaders, and this game uses lots of them. I don't want to be too hard on devs for this though, because on Windows the game uses just about 500MB of memory, almost nothing. This is a technical issue in mesa drivers, not the devs fault. Still, 64bit version would help a lot with this, sure.

Quoting: scaineLoading was too slow

That got improved massively recently:
http://steamcommunity.com/games/ns2/announcements/detail/42015035008941986
Changing the map or connecting to a different server is now matter of 5-10 seconds on my machine.

View this comment - View article - View full comments

Well, if you intend to do a crossplatform game, pick crossplatform tools from the start. It's as simple as that. I feel sympathy with them, but it's still developers' fault, not middleware's fault.

View this comment - View article - View full comments

Quoting: tuubi

Quoting: ripperThe question is how developers can verify that their games don't rely on external dependencies.

Wouldn't simply testing on a fresh install of SteamOS do the job?

No. SteamOS is just another Debian installation, it still has many system libraries installed. Many of those libraries might not be available on other distributions, at least not by default. Of course, yes, this would verify it works on SteamOS well, but just on SteamOS. According to Valve reply, SteamOS compatibility is not enough, there has to be no dependency on the host system (which is a great message for us, they don't care just about SteamOS, they want the game run out of the box everywhere).

View this comment - View article - View full comments

This is good news. Games should rely on Steam SDK and their bundled libraries, but nothing else. This does not stop Java or any other games from working, they just need to bundle Java or any other runtime with their game. That's not difficult to do and it makes the game work everywhere, and not randomly work on some systems a not work on others. There are of course certain concerns about bundling, but there's no better solution that would be universal and generally working, especially across distributions, so bundling it is. Games losing the SteamOS/Linux logo is a great motivation for developers to make things right.

The question is how developers can verify that their games don't rely on external dependencies. I'm no C expert, but I think using ldd on the binary and comparing with Steam SDK libs and bundled libs should be enough and quite easy. Alternatively developers could override LD_LIBRARY_PATH to point just to Steam SDK and their bundled libs (and avoid system libs directories) and try whether their game works. I'm sure Valve devs can supply an easy howto guide to game developers (and quite possibly already did somewhere in their guides collections).

View this comment - View article - View full comments

Quoting: ripperIn any way, I can tell you in a few days whether it fixed itself or not :) Who would have thought that simple calendar generation can be so tricky...

OK, so at least in my case, all new events (with UID 309 and newer) display properly. The older events still display over 2 days, even though their LAST-MODIFIED time has been several times updated. In Evolution everything shows up fine. I also tried completely different Google account, but the problem is present even there. I give up, I have no clue why. It's either a bug in Google Calendar or they use some very aggressive caching that I don't know how to override.

I think we'll need to conclude it's "good enough". It's going to look good in the future, and we'll need to get over the existing two-days events. Thanks for all your work and your patience, Liam.

View this comment - View article - View full comments

Quoting: liamdaweEdit: Fixed, mixed up my ; and : in the actual file, shows fine in Evolution cal for me now.

This problem now seems fixed in Google Calendar, but only for new events. For example, "Chaos Reborn" is displayed properly as a full-day event, and it has UID:309, which is the last UID in the file, so I assume it was added today. But all other events (which already existed before all the changes) still display 2AM->2AM. I believe that's because LAST-MODIFIED:20151014T000000Z is used for all of them - Google does not refresh them, because it thinks there were not modified since midnight (and it apparently has some caching, because deleting and re-adding the calendar doesn't help).

I assume this issue will solve itself in the future once you modify the calendar again (from 20151015 onward), because the LAST-MODIFIED timestamp will get updated (I assume you replace all those lines any time you edit the calendar). But it also means that any changes to events will get delayed for at least one day (if my theory is correct). Alternatively, you can implement precise timestamps for LAST-MODIFIED, and that should hopefully fix it. The easiest solution would be to change all LAST-MODIFIED lines in the .ics file to "now" (e.g. 20151014T151104Z). The more correct solution would be to adjust just the line for that particular event you edited.

In any way, I can tell you in a few days whether it fixed itself or not :) Who would have thought that simple calendar generation can be so tricky...

View this comment - View article - View full comments

Quoting: liamdaweDoing it like so
DTSTART;VALUE=DATE:20151015
DTEND;VALUE=DATE:20151016

Makes it not validate, and it also won't import into my Evolution, so I'm really not sure what's going on.

Looking into the ics file, you have used a colon instead of a semicolon:
DTSTART:VALUE=DATE:20151015
DTEND:VALUE=DATE:20151016
^^^^^^^^ semicolon should be here

If I fix that, I can import into Evolution just fine. How do you validate it?

View this comment - View article - View full comments