Not everyone is a born game dev, it seems ;)

View this comment - View article - View full comments

Sounds fairly interesting. Faeria was a blast to play (think I spent 80h on it), so I'm eager to try out this one.

View this comment - View article - View full comments

Quoting: Areso

Quoting: TheSHEEEPA survival game completely without co-op?
Weird. To say the least.

But to promise multiplayer as a stretch goal is just completely beyond amateurish.
Every developer worth his money knows that multiplayer is a framework decision, not something you can just "add" later on.
Doesn't exactly inspire confidence in the developer in this case.

Don't Starve. A survival game completely without co-op.

Yeah, and quite boring after a few hours (at least for most players which is why Don't Starve Together has like 4-5x the player count).

Quoting: AresoDon't Starve. Single player game, where multiplayer was "added" sometime later. (As well as Goat Simulator).

Well, Don't Starve Together is a standalone game, and most likely because they weren't able to do it via a simple patch (or DLC).
And Goat Simulator... come on. That game is so simplistic, they probably really only needed to install the networking plugin and a bit of code around it ;)

View this comment - View article - View full comments

Quoting: Mountain Man

Quoting: tuubiYay. American handegg. "It captures the sport’s essence" eh? Does it simulate doping? How about brain injury due to repeated concussions? /troll

Since you admit to trolling, I assume you're aware that the incidences of brain injury in football players (and injuries in general) have been overblown by liberal activists and the mainstream media.

Let me rephrase what you just said:


Thank you for your insight.

View this comment - View article - View full comments

A survival game completely without co-op?
Weird. To say the least.

But to promise multiplayer as a stretch goal is just completely beyond amateurish.
Every developer worth his money knows that multiplayer is a framework decision, not something you can just "add" later on.
Doesn't exactly inspire confidence in the developer in this case.

View this comment - View article - View full comments

Yeah, no disagreement here. I don't get any real benefit from static linking, either. It's just more cumbersome to update anything.

But in the Atom case, I don't think it is a problem of static linking. I'm pretty sure the folders would be just as big if Atom was dynamically linked - which it maybe is, I don't know. Either way, the problem is developers being messy, not the linking type.

View this comment - View article - View full comments

I might have worded that poorly.

I know WHY all the data is there, what I find generally unpleasant is how much of that is redundant data and just general developer carelessness. Take Atom, for example. That editors seems to store all its previous versions since original installation (and all of them are about 400MB).
After deleting all those folders, Atom worked just as well, so all of those folders were completely useless, just hogging up GBs of space.
You cannot blame the OS for that, it really is on the developers. That's what I meant.

View this comment - View article - View full comments

Quoting: ShabbyXLast year I bought an SSD. It was expensive and I got a 256GB one. On windows, I consistently see about 100GB~200GB of OS+programs storage while on Linux all my OS+programs (that is everything excluding /home) takes about 20GB. So yes, that _is_ an issue still. I'm not talking just about games.

Do you honestly think all those data is multiple versions of the same library?
That's utterly ridiculous.

I have about the same amount of SSD usage and regularly use WinDirStat to check what is taking that space.
By far the largest chunk is the user data directory, as every single program (unfortunately usually not configurable) stores its data there. And usually redundant data, too. Browsers, email clients, Windows installer caching nonsense, those are the evildoers.
I don't really have an explanation of why on Windows every programs just spams that folder (while on linux it doesn't?), but it has very little to do with duplicate libs.

You also forget that applications might share the same library, but certainly not the same version. So if 20 apps used the same library, it is pretty likely that they have been built against, let's say, 10 different versions. So even on linux, you will have 10 different library versions lying around. Not that much of a difference any more.
Again, storage is cheap. Except SSDs (for now). If you install all your programs on your SSD instead of just vital data (save games, coding profiles, etc. just usage data) - well, that is your fault.
I install everything on my non-SSD drive (given a choice), and it works just fine, since I'm not running a toaster and if you can afford a rather large SSD, chances are you aren't running one either.

Quoting: ShabbyX- Security: If the library fixes some bug, 20 applications (on windows with 20 different updaters) have to update that dll. We all know (on windows) that not all of them will do it, and the buggy library will end up remaining on your pc.

Not wrong, but you are talking about bugs so important that applications HAVE to update. When does that actually ever happen? Once per year?
Usually, dependencies aren't updated simply because they don't need to be. Because most software doesn't actually deal with security issues.

Quoting: ShabbyX- File System Cache: If the library was shared between the 20 applications, then loading one application after the other would be much faster given that the same .so files are either already in RAM or likely at least in the file system cache. Each application shipping a separate copy of its .so files mean slower application start.

Not wrong, but I think the last time I was actually bothered by an application starting up taking more than a few seconds must have been Win XP. Or one of my first smartphones.
I am a VERY impatient man, and if I'm not bothered, it really isn't bad. Another non-issue.

Quoting: ShabbyX- Memory: Unless the OS does a byte-to-byte comparison of the whole .so files, it cannot know that the applications are using the same .so file, which means running multiple of those applications results in the same .so files loaded multiple times in RAM, resulting in higher RAM usage, as well as worse CPU cache usage.

I'm not really convinced the CPU cache argument is correct. Won't it actually be faster if each program runs its own version of a library as the data will be closer together? At least as a general rule, redundancy improves speed at the cost of space.
The RAM usage... my main PC has 12 GB. I have never seen that filled, and I do work some heavy applications regularly. My laptop even has 16GB. So, yeah... another non-issue.

View this comment - View article - View full comments

This looks like Blood Bowl!
But only with the human team... and a severe lack of blood. Meh.

View this comment - View article - View full comments

[quote=ShabbyX]

Quoting: TheSHEEEPThat aside, the real problem is in fact that they try to force a windowsish distribution on an operating system that has a proper package manager. The libraries on linux actually have pretty decent abi versioning, which means multiple libraries can co-exist and each application would choose to higjest compatible version. Dependency-hell may be an issue for packagers, but the end results are damn nice for users.

Imagine for a moment if Linux games were also packaged like the rest of the system... No more 100 duplicates of .so files like on windows!

First of all, those duplicates were an issue many years ago when disk space was a problem. It simply isn't any more. This is a non-issue. Games nowadays can take any amount of space from 100MB to 60+GB. A few MB more in dependencies simply will not matter.

Also, yes that package managing stuff is nice. But only in theory, where it actually works.
In practice, games (and other software) are not constantly developed and updated with latest versions of libraries. And they shouldn't! Don't change a running system.
So at some point, version X of a dependency WILL rotate out. And then users have to find custom solutions, which is annoying as hell and will cause more people to switch to Windows for the product than it will cause them to fiddle around with their system. Fiddling around is nice for us proggers, but not for average users. This has happened SO MANY TIMES with open source libs that actually are maintained by someone - and so many times more by closed source software.
So either package maintainers have to carry ancient versions of their libs around (possibly even fixing critical bugs in them still if they appear) - and with that outlook, who still wants to maintain packages "properly"? Nobody.
Or developers are forced for a life long update-my-dependencies-game, including possible API changes and whatnot. Hooray.

No, I'm sorry. This package managing stuff may have noble goals, but in practice it is a terrible crux for developers that are actually paid for their work. And it throws more than just a few stones in the way of spreading linux.

View this comment - View article - View full comments