You probably don't know this. Epic have had more than just one hit game.

First released game appeared in 1992 as Epic (and one before that in 1991 with another company name) I really dare you to put out a full blown release of a game software product running on just one platform, even with today's free tools and git-ware. It takes a lot more time than you can imagine.

In Those 30 years, the tiny company Epic managed to outsmart Id, Sony, Nintendo, Electronic Arts, Valve, Microsoft, Ubisoft, Crytek, Take2, Vivendi, Infinity Ward, Bioware, Capcom, TT, SquareEnix Sierra, Dynamics, Microprose, ActiBliz, Rockstar, Naughty Dog, Mojang, Dice, Treyarch, Bethesda and many more. That's a hell of lot of industry competition to handle. They did not simply manage, they were setting the rules at every step of the way.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F...

Holy shmoly,

Your comment brings a smile to my face :) I'm curious how deep this rabbit hole still is. As for ownership/ads, yeah I read ages ago that /. got sold in a package deal of sorts. I'm too lazy to look it up right now :)

Kr, .i

Truly sorry to hear about all of you losing a good friend. Sad. Take care of yourself.

Actually this kind of 'disaster' cancelling occurs quite often in other companies as well. Typically it goes something like:

The company reaches a point like: "We made a few games, we know our trade, we have the cash, now let's do something interesting." Then they throw all their best ideas onto a huge pile, and the game-design sanctioned people try to make sense out of it. At this point, a lot of creativity is already out of the door, since of course, the huge undertaking has to play safe ball to ensure success, and who knows better than anyone else how huge games work except game designers, right? In parallel, work starts on pre-production, concept art, prototyping, level design, game play mechanics, effects, you name it. After a while, it turn out that the really fun bits are not fun at all, no matter how much you tweak them, and everything starts to look like a tech-demo, because everyone is focusing on just a small fraction, and there's no coherence whatsoever. How could there be. Of course by then we're 2 year after the project starts, and canning it is starting to sound expensive. In the end, it comes down to a financial gamble: releasing crap can mean the end of the company (ahum: Destiny). You can sell crap once with success and maybe break even or profit, but you shit most of your loyal fans in the face, and usually they tend to not take that lightly. Or you can cancel, and swallow the loss and work on something that holds the promise to bring more grit (of which, of course, there is no proof yet).

If there's one team that has the money and the minds to work on very ambitious projects, it's Blizzard. And apparently the teams values their future productions and fan-base as more important than selling Titan. That said, Titan did look impressive from the setup, so I hope the tech and team survives.

Not wanting to start a war on anything:

I fully agree with the argument that professional development applications such as 3DMax still have not cut it into the UX realm, except from the usual suspects like Gimp and Renderman. Developing games for other platforms could easily be supported on Linux - ps development - if only the tools were up to par. Meaning: saving time rather than costing it.

That sort of givens automatically drive your decision making process as to what platform you'll be using when developing games. There are alternatives. Like there are alternatives in choosing your workforce, or spending lots of training to convert to Maya or Houdini, but that is not the cheaper solution, and it kind of voids the whole argument.

That said, I really think most of the arguments are really quite minor, except for maybe 1: a regression suite that can detect hardware incompatibility problems.

Another one that would be easy to come up with is a test-suite that streamlines the development of application configuration through both command-line and GUI. Helpful, but not crucial.

Reading the other items, I had an idea: What if distro's refer to a sort of xml configuration file with a shared / common format that specifies how exactly each distro has to set up it's files and dependencies, such that such configuration grief and the fact that 'each distro organises things differently' could be overcome in true linux style: maintaining uniqueness of the software (kernel) AND being flexible about the details (data).

All yours for the bashing..