Your definition is the way I originally learned the terms too. People often have trouble understanding these definitions - particularly the fact that beta is feature complete. They don't get that if you're making suggestions at beta time, you're way too late. That's what the alpha stage is for.
The way I sometimes put it is: "If you test your beta, and you can't find any bugs, then that's what you ship."
That never happens of course, but it gets the point across:)
It must be a nightmare living with you, with you walking round all the walls in your home, pushing at them and grunting, on the off-chance you'll find a chainsaw:-)
They said that porting it across platforms found bugs.
As I said, this is true. The question is, whether this is the best use of your time, especially if you're developing for a platform that you won't ship the game on. (In the case that you're developing on PC, Xbox and PS2, I fail to see how adding another platform like Linux into the mix is going to help anyway.) You seem to be saying that because you find bugs when you port a program to another platform, then that is the best and most efficient way to find bugs. I don't believe this is the case.
They primarily developed on Windows and spent almost a year beyond the Windows discovering that the sound library actually had a version for Linux.
I don't think I understand what that even means. It took them a year to discover that the sound library they were using was also available on Linux? Huh? If that's true, then it's just dumb - it has nothing to do with whether or not you develop on Linux or not.
If the quality of the average program on Windows is any indication, Windows is an awful platform to develop on.
By the same token, I could say that Linux, Mac OS X, etc are awful platforms to develop on. Most software sucks.
By developing on multiple platforms you reduce bugs.
This can happen, but are you suggesting that game developers develop for Linux just to reduce bugs, and not because they will ship on Linux? There are much more efficient ways of spending your time if you want to reduce bugs.
There will be fewer stumbling blocks porting from Linux to Windows than Windows to Linux.
Why is that then? Or is it just received wisdom?
It is all too easy to use a library on Windows that has no correspondence on another platform.
Many game developers are working on projects for which the finance runs to millions of dollars. They do actually think about these things. If they choose a library that is specific to Windows, it's usually for a reason (often financial). I sometimes think that some people think games developers use DirectX to develop for Windows, but then try to port to other platforms, only to find DirectX isn't supported, like a bolt out of the blue. "Oh no! No DirectX for Mac or Linux?! How were we supposed to know that? We thought DirectX ran on everything!"
The developement kit is running Linux on the PS2. The case of taking something already running on Linux over to the PS2 is simplified somewhat.
Oh please - nobody uses the Linux devkit for PS2 outside of some mad Japanese developers and the occasional masochist. The Windows tools are poor enough, without wanting to use the Linux ones...shudder. Besides which, that's like saying that if I code my game on Windows, that'll make it easier to port it to the GameCube because all the GC dev stuff runs on Windows.
Also it requires a bit of vision to go I want to develope for multiple platforms, what is the best way to do this, rather than a short term how do I maximize profit.
When you say 'vision', you mean extra cash, because it costs extra. You seem to be grasping, as if developing for Linux is in some way self-righteous, and inherently just better than developing on Windows.
If you're writing cross-platform games, your (current) platforms are basically PC, Xbox, PS2 and GameCube. I don't see how developing your game on Linux is going to help you achieve that. If anything, on Linux you'll end up with the same problems as you do on Windows - i.e. resource usage too high (because PCs are big and powerful - huge hard drives and RAM), which leads to code/architecture which crashes and burns when you port to a console. Or using fancy features like rampant C++ template/STL usage which you find won't compile for consoles, or frags the (fixed size) heap like hell.
You can overcome these problems by developing first on consoles, but I prefer to develop the game primarily on the platform with the best tools, and apply some engineering discipline and structure, rather than develop the game for a platform that it will never ship on.
No, it's the sheer variety of Linux setups/distros.
If we did a Mac OS version, we could say 'it runs on Mac OS X'. I doubt a game would even need any specific features of the point upgrades to Mac OS X, so you probably wouldn't even need to specify 'Panther' or whatever.
Constrast this to Linux - which distro are you running? Is it in X, or some frame buffer mode, or what? Just thinking about all the distros we'd need to test on and support made me want to run away.
And if we just picked some limited set of distros, we'd probably end up with net negative PR from all the Debian/Slack/Gentoo/whatever fans who'd shout at us for not supporting their fave distro.:)
Also, try to convince the publisher's marketing dept that you can sell copies of the game on an OS which they've probably never heard of.
And so on.
Essentially, it comes down to the same things that most business decisions come down to: cost, and hence profit.
Actually, if companies were smart, develop on Linux then port to Windows and Mac.
Why would they develop on Linux first? Surely basic risk management would dictate that you ensure that you develop for your primary platform, e.g. Windows (compared to Mac/Linux). I'm assuming from your use of the word 'companies' that some kind of profit is intended to be involved.
It is even comparably easy to add support for say the PS2.
Comparably easy in what way? I'm not aware of having met anyone who's developed for PS2 that would use the word 'easy' to describe it.
I'm not sure that fits in with the Apple way of thinking:)
I thought the iMac hockey puck mouse was, to quote a wise man, the suckiest bunch of suck that ever sucked. Sure you can look at the mouse to work out which way is up, but if Microsoft had produced a mouse that required you to look at it whenever you wanted to move it, people would be (quite rightly) bitching like hell.
Of course you are right. There must be some other reason why they bought HL2 and didn't pirate it like the other games. How foolish of me to think otherwise.
BTW, I looked at a couple of the HL2 cracks recently, in light of the recent Valve server problems. "Too much hassle" was definitely an accurate description of the ones I saw.
Yes, because if you're going for the whole 'Mac experience', what you really want to do if you have issues with the supplied keyboard or mouse is attach some $5 piece of shit to replace it.
Re:Brings up an entirely different issue
on
Steam Users Steamed
·
· Score: 1
Ah, there it is -- if you have a problem, turn to piracy. You can either condemn or condone piracy, you cannot do both.
In the scenario given, the guy already has a legit copy of HL2, he just can't play it due to Valve not existing/caring about HL2.
I fail to see how using a crack to play software you bought is piracy. Using the crack to play HL2 when you haven't paid for it is software piracy.
I think you're referring to the circumvention of copy protection.
Sorry, just not true. I happen to know a fair few people who simply pirate games when they come out.
When HL2 came out, almost all of them just bought it. I believe this to be a combination of the fact that they thought it would be a good game and the fact that they knew about Steam/authentication etc.
The first factor definitely had something to do with it, but the 'just too much hassle to pirate' factor definitely had an effect, believe me.
Anecdotal, certainly, but it qualifies for your 'in the slightest' criterion.
The core work of most modern games is done on a single thread. A lot of games use a thread to read input, but that's about it.
Do you know of any examples of games (other than, I believe, Quake 3) that use threads to actually divide real work, as opposed to a minor scheduling convenience?
Slashdot Mirror
Oh, and I forgot this, of course :)
You mean like this or this?
They're heading for some disappointment.
Your definition is the way I originally learned the terms too. People often have trouble understanding these definitions - particularly the fact that beta is feature complete. They don't get that if you're making suggestions at beta time, you're way too late. That's what the alpha stage is for.
:)
The way I sometimes put it is: "If you test your beta, and you can't find any bugs, then that's what you ship."
That never happens of course, but it gets the point across
You're right.
I think there is a world market for maybe five new command line applications.
So...as good as Halo then? :)
It must be a nightmare living with you, with you walking round all the walls in your home, pushing at them and grunting, on the off-chance you'll find a chainsaw :-)
As I said, this is true. The question is, whether this is the best use of your time, especially if you're developing for a platform that you won't ship the game on. (In the case that you're developing on PC, Xbox and PS2, I fail to see how adding another platform like Linux into the mix is going to help anyway.) You seem to be saying that because you find bugs when you port a program to another platform, then that is the best and most efficient way to find bugs. I don't believe this is the case.
I don't think I understand what that even means. It took them a year to discover that the sound library they were using was also available on Linux? Huh? If that's true, then it's just dumb - it has nothing to do with whether or not you develop on Linux or not.
By the same token, I could say that Linux, Mac OS X, etc are awful platforms to develop on. Most software sucks.
This can happen, but are you suggesting that game developers develop for Linux just to reduce bugs, and not because they will ship on Linux? There are much more efficient ways of spending your time if you want to reduce bugs.
Why is that then? Or is it just received wisdom?
Many game developers are working on projects for which the finance runs to millions of dollars. They do actually think about these things. If they choose a library that is specific to Windows, it's usually for a reason (often financial). I sometimes think that some people think games developers use DirectX to develop for Windows, but then try to port to other platforms, only to find DirectX isn't supported, like a bolt out of the blue. "Oh no! No DirectX for Mac or Linux?! How were we supposed to know that? We thought DirectX ran on everything!"
Oh please - nobody uses the Linux devkit for PS2 outside of some mad Japanese developers and the occasional masochist. The Windows tools are poor enough, without wanting to use the Linux ones...shudder. Besides which, that's like saying that if I code my game on Windows, that'll make it easier to port it to the GameCube because all the GC dev stuff runs on Windows.
When you say 'vision', you mean extra cash, because it costs extra. You seem to be grasping, as if developing for Linux is in some way self-righteous, and inherently just better than developing on Windows.
If you're writing cross-platform games, your (current) platforms are basically PC, Xbox, PS2 and GameCube. I don't see how developing your game on Linux is going to help you achieve that. If anything, on Linux you'll end up with the same problems as you do on Windows - i.e. resource usage too high (because PCs are big and powerful - huge hard drives and RAM), which leads to code/architecture which crashes and burns when you port to a console. Or using fancy features like rampant C++ template/STL usage which you find won't compile for consoles, or frags the (fixed size) heap like hell.
You can overcome these problems by developing first on consoles, but I prefer to develop the game primarily on the platform with the best tools, and apply some engineering discipline and structure, rather than develop the game for a platform that it will never ship on.
To me, this is pretty basic risk management.
No, it's the sheer variety of Linux setups/distros.
:)
If we did a Mac OS version, we could say 'it runs on Mac OS X'. I doubt a game would even need any specific features of the point upgrades to Mac OS X, so you probably wouldn't even need to specify 'Panther' or whatever.
Constrast this to Linux - which distro are you running? Is it in X, or some frame buffer mode, or what? Just thinking about all the distros we'd need to test on and support made me want to run away.
And if we just picked some limited set of distros, we'd probably end up with net negative PR from all the Debian/Slack/Gentoo/whatever fans who'd shout at us for not supporting their fave distro.
Also, try to convince the publisher's marketing dept that you can sell copies of the game on an OS which they've probably never heard of.
And so on.
Essentially, it comes down to the same things that most business decisions come down to: cost, and hence profit.
I can guess - it's real easy. Because virtually no-one will pay them to develop GC titles any more.
(If you want to moan at me, feel free, but that's the reality.)
I'm an actual game developer, and I looked into the feasibility of a Linux version of one (PC/Mac) game I was working on.
:)
My conclusion was that it would be a goddamn nightmare in terms of QA and support.
You may now ask your questions
Why would they develop on Linux first? Surely basic risk management would dictate that you ensure that you develop for your primary platform, e.g. Windows (compared to Mac/Linux). I'm assuming from your use of the word 'companies' that some kind of profit is intended to be involved.
Comparably easy in what way? I'm not aware of having met anyone who's developed for PS2 that would use the word 'easy' to describe it.
They could have done with Paxman doing the interview instead, really.
"Did you threaten to remove Netscape?"
:-)
That's not fair - there's hardly any Unix users anyway! :)
Yeah, stupid users - that must be it!
:)
I'm not sure that fits in with the Apple way of thinking
I thought the iMac hockey puck mouse was, to quote a wise man, the suckiest bunch of suck that ever sucked. Sure you can look at the mouse to work out which way is up, but if Microsoft had produced a mouse that required you to look at it whenever you wanted to move it, people would be (quite rightly) bitching like hell.
"Does it run MS-DOS?"
What, the URL itself? I'd have to agree with that.
Awesome! :-)
Of course you are right. There must be some other reason why they bought HL2 and didn't pirate it like the other games. How foolish of me to think otherwise.
BTW, I looked at a couple of the HL2 cracks recently, in light of the recent Valve server problems. "Too much hassle" was definitely an accurate description of the ones I saw.
I expect that's wrong too though.
Yes, because if you're going for the whole 'Mac experience', what you really want to do if you have issues with the supplied keyboard or mouse is attach some $5 piece of shit to replace it.
In the scenario given, the guy already has a legit copy of HL2, he just can't play it due to Valve not existing/caring about HL2.
I fail to see how using a crack to play software you bought is piracy. Using the crack to play HL2 when you haven't paid for it is software piracy.
I think you're referring to the circumvention of copy protection.
Sorry, just not true. I happen to know a fair few people who simply pirate games when they come out.
When HL2 came out, almost all of them just bought it. I believe this to be a combination of the fact that they thought it would be a good game and the fact that they knew about Steam/authentication etc.
The first factor definitely had something to do with it, but the 'just too much hassle to pirate' factor definitely had an effect, believe me.
Anecdotal, certainly, but it qualifies for your 'in the slightest' criterion.
The core work of most modern games is done on a single thread. A lot of games use a thread to read input, but that's about it.
Do you know of any examples of games (other than, I believe, Quake 3) that use threads to actually divide real work, as opposed to a minor scheduling convenience?
I'm not able to parse that in a way that makes sense.
Plus, you're still speculating. (Again, not surprised.)