Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
I agree with most of your points, but I can't really agree with your logic on these. Hardware floating point support wasn't common until the 486 days. A lot of lower end CPUs used to omit support for division. That didn't stop C/C++ from including support for those features.
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it. They were probably left out originally to keep things simple in the early days of C. Now the standard committee seems very hesitant to make changes to the syntax of language, so they probably just look at these things as nice to have but not worth changing syntax over.
If a shared library is already loaded why would the system not reuse the reference to that library it already has loaded rather than attempting to ask the current file system view for to establish a separate reference?
Because that's how it's always worked in UNIX ? Some people think it's a good thing, and that's why this update in place stuff works.
If two programs running in separate memory spaces experience these kinds of side effects while communicating with each other this is a protocol design issue. Remember it is entirely possible to have local versions of shared system/runtime libraries that differ between application because of locally installed DLLs or DLLs within search path.
Ideally, sure. But I specifically mentioned bug fix cases. Stuff happens, things go wrong. You do have to deal with it.
The issue gets worse if on-disk data is involved. You've now got data files potentially being updated by different versions of a library, potentially leading to data corruption or loss.
Who writes an on disk format that changes between versions without properly versioning the file? Garbage In = Garbage Out.
Changing code that's in use = garbage in. I'm not talking things like a document file that's written once and closed, I'm talking files continually accessed by multiple processes.
For a specific example of this happening, back in the days when libc had major changes frequently (think libc5 -> glibc/libc6 days), it was pretty common to do a system update and end up with problems with utmp and wtmp caused by two versions of libc being in use. You'd get garbage output when you ran commands like "who". The problems went away when you rebooted to get rid of everything using the old libc.
It is OK on Unix because that replaced library still exists in memory and can continue to be used by the programs... running in memory!
Each new invocation of the programs that try to use that library will of course pick up the new version. It's not magic. I don't get why people can't grasp this.
But that's exactly why there is a problem!
Library version numbers generally change when the API changes. If a new version of the library is source compatible with the old one, the version generally stays the same. However, that doesn't mean the internal workings are compatible.
Let's say you've got a library that handles communication between applications. You've got Foo running with library version 1.2.3. The developers discovered a bug in the library's internal data transfer protocol. The bug is an implementation detail, not an application visible one, so they simply fix it and release version 1.2.4. It's 100% API compatible - taking advantage of the fix just requires updating the library. You update the library in place, with Foo still running using version 1.2.3. You start up Bar, which now loads library version 1.2.4. When the two apps try to interact, you're now going to get bugs or even crashes when they interact. They believe they're using the same library, but they're not. You've now run into a class of bugs that only exists because you updated a library that was already in use.
The issue gets worse if on-disk data is involved. You've now got data files potentially being updated by different versions of a library, potentially leading to data corruption or loss.
The index buffer is not updated every frame, just once.
That's not always true. Sometimes it's more efficient to just stick the vertex data directly into the vertex buffer as your frame is generated, then do your draw order sorting at the end by rewriting the index buffer.
Triangle strips require everything in one draw call to be connected. If you want to draw N quads, you have to make N draw calls, passing 4 vertices each time. There's a significant amount of overhead involved in a draw calls, so this is slow. With quad support, to draw N quads you can just make a big array of 4N vertices and process it all in one draw call.
I went from OpenGL 1.x over to OpenGL ES, so I don't know most of what modern OpenGL can do. But one glaring weakness is that OpenGL ES doesn't support drawing quads, only triangles. Yeah, the GPU processes a quad as two triangles internally, but if it supports quads, there's less vertex data to generate and pass to the GPU. You can somewhat make up for it by using glDrawArrays, which uses array indexing into the vertex list, but in a lot of cases (especially for 2D scenes), it's still less efficient than if you had quads.
Because 3rd party developers with early dev kit access were leaking details to the press. They thought it was better to announce it on their own terms than to have all the details leak out that way.
Without the GPL, they would have just used the existing implementation.
With the GPL, they're going to have to recreate the functionality themselves. Their implementation will probably be closed source. They might consider contributing it to the kernel with more permissive licensing terms, but considering how Alan Cox reacted to their request, I doubt it would be received well. Now we'll have duplicate, incompatible functionality being maintained by the kernel devs and NVIDIA. Either that, or NVIDIA will simply do without the feature and release inferior drivers.
The US picked NTSC when Pal was clearly the superior standard.
PAL is higher resolution. NTSC has a higher framerate. They each have some other minor differences. Which one is better depends on your personal preferences.
VHS won out even though Beta was better.
Beta had better picture quality, but suffered from short recording times. The longer recording times mattered more to people. VHS also had better licensing terms, which helped the people making the hardware and pre-recorded videos. VHS was better for most people.
Some felt HD was better than Blu-ray,
Blu-Ray was designed to be the best format possible at the time. This meant new manufacturing factories were required to make them. HD-DVD was designed to be a "good enough" format. It's big selling point was that the discs could be made at existing DVD factories with only relatively minor changes to the equipment. The software end of the specifications each have their pros and cons, but were similar enough that few people had strong feelings about it. Ultimately Blu-Ray won because Sony was committed to building out the manufacturing plants. Once they built sufficient plants, there was little reason to use HD-DVD.
At the time it came out Firewire then firewire 800 were clearly superior standards.
Firewire was great if you were using it for high end equipment that needed high speed data transfers. It was great for things like digital video cameras and external hard drives. It fairly expensive though, and much less flexible than USB. USB won out because it offered enough speed for most devices, was extremely cheap to include in a device, and allowed easy chaining of a lot of devices. For the average computer user, USB was a lot better. While Firewire was still faster than USB 2.0, it wasn't a significant enough difference to matter for many people.
NES games are still playable. The problem is the NES itself - the connector the cartridge slides into gets bent out of shape. It's easy to open the system up and swap the connector. The new part only costs a few dollars.
Blowing on the cartridges never actually did anything to make them work. What did help was simply taking the cartridge out and putting it back in. It would sit differently, and eventually it would sit well enough to make a solid connection with the bent connector.
Tivo has an iOS app. It allows you to do exactly what you want. Control the Tivo, browse TV listings, etc. It sucks to use as a remote as you have to look at it to make sure you're hitting the right button. It's also slower, as you can't just slide your finger around on the screen to get to the next button. With a regular remote, you usually quickly learn your way around it by feel and can use the common buttons easily without looking.
The listings don't work well on an iPhone - the screen is just too small. The guide on the TV screen works much better. It's easier to read and you can fit a lot more information on screen at once.
I haven't tried it on an iPad yet. I'm guessing the listings would be better, but the remote controls would probably be even slower to use with the larger screen.
"better automatic widget layout" - this made my day. I remember using GEOS as a boy, on a C64. It was a lot of fun going from text menus to an actual mouse-relevant UI, but sophisticated it was NOT. Automatic widget layout? There were 8 icons per window and if you didn't like where they were you could (a)bort, (r)etry, (i)gnore.
He was talking about the PC version of GEOS. You're talking about the C64 version. The only similarities between the two products are the name and some members of the development teams.
The PC version had a really sophisticated UI for the time. It was all multi-threaded with automatic control layout similar to how modern UI toolkits work. I found it a pleasure to code for. 15 years ago I was creating UIs much faster than I am today with modern tools.
So I don't need an invitation from an established member?
Missed that one... no, you don't need invitations on LinkedIn - at least not that I've ever seen. To cut spam, a lot of groups require approval to join. I think that simply means that a group admin looks at your LinkedIn profile and approves you as long as what you say in your profile looks somewhat relevant to the group. For most groups you'll get approved within a day or two.
I thought of that until I realized there were no chapters [igda.org] in Indiana. I'd have to take a bus to Chicago or Detroit and rent a hotel room.
Look for similar stuff. Lots of areas have other regular groups / conventions / etc.
That's my problem: I don't yet have a mainstream platform of choice beyond native development (that is, Windows).
Then just pick one. iOS and Android are easy to get into and in demand, so they're probably the best choices now. Make a few small games or apps and get them on the market. Don't think of them as money makers, think of them as resume pieces. The phone app stores aren't money makers for most people, they're mostly marketing pieces. Companies love to have apps to promote their business, and pay good money to have them made. Take that same approach. Release something to show that you're capable of it, then people will trust you to make what they want.
Except when it's an iPhone 4 and the product under development requires the larger RAM in the iPhone 4 and not the iPod touch 4.
Of course. Things like that are why I said "most of the time".
I wasn't aware of that. I thought there were so many job seekers that candidates without their own equipment were rejected outright.
An iPad or iPhone is cheap compared to a developer's pay rate. If you have a good resume and/or recommendations, then not having the exact device the project requires isn't a deal breaker. You're not likely to get a company to give you a Mac, but iPads aren't a big deal.
Which web site do you recommend for searching for video game development jobs near (say) Fort Wayne, Indiana?
GameDevMap.com is a start - it shows 4 companies in Indiana, including one in Fort Wayne.
Check the usual stuff. Craigslist has postings all the time. Check development boards for your platform of choice. Go to IGDA meetings or similar things and meet people there. Keep an updated LinkedIn profile, and subscribe to lots of relevant groups.
Can one do iPhone contract work with just a Mac and an iPod touch?
Works fine for me. Most of the time people say "iPhone" it's shorthand for "iOS devices". Obviously you can't do everything an iPhone can with an iPod, but you can do most things. If you're doing a project for a company, they usually won't have a problem loaning you a device you don't have. Not sure about iPhones, but borrowing an iPad usually isn't an issue.
Aren't smartphone games more for the adult casual gamer with some free time between the events that constitute their life and the nintendo handhelds more for young children with more free time than a life?
That was true in the GameBoy days, but the DS hit a different market. The Pokemon crowd carried over, but the DS blew away the GameBoy because it catered to adults as well. Brain Age and games like that were major sellers - enough so that they released the DSi XL, which was primarily aimed at older audiences (the "can you make the text bigger?" crowd)
They sold a ton, but the DS also has a traditional button layout surrounding the screen. Plenty of games don't use the touch screen for anything other than menu navigation.
Most Wii games aimed at traditional console gamers use buttons heavily.
Correct me if I'm wrong, but I understand that this involves building up tens of thousands of dollars on which to live while seeking a job; moving to Silicon Valley, greater Seattle, or some other area with multiple major video game developers; somehow landing a job with major video game developer; and working there for several years.
No, it doesn't. There's no need to work for a major developer. The closest small developer near you is fine. If you're looking to make handheld games they'll probably be happy with iPhone experience. There's tons of remote iPhone contract work available.
Getting a job at a game company isn't hard if you really are talented enough to deserve it. It's hard to find good people in the industry. Make a small, polished demo and send it with a resume. It'll take you far.
If you can make something of professional quality, it'll take you far. It's a great step in the door at any game developer. Publishers will at least listen to you if you have something decent to show.
The console makers basically care about two things: that you're running a legit business, and that you can finish a game for the system you're applying for. They don't want their dev kits and SDKs and confidential information getting out into the open, and they don't want to waste their time with people that aren't going to finish a game.
Finally, go to the Game Developer's Conference. Just about everyone important in the industry is there. It's not that hard to get some face time with the important people. The console makers all have booths and/or information sessions so you can find out how to develop for them.
You might not, but enough people do that you'll be impacted. You can do cheaper by having email support. But direct customer support isn't even the big concern - as I said before, think about games that interact with online servers. You need to maintain the servers and make sure they scale to match the userbase. If you're dealing with PC games, there will be compatibility issues you'll have to deal with.
The real point is: Are you better off selling 20 000 units of a $50 games or 2 000 000 units of a $0.5 games? The sheer visibility bonus of the second option alone makes me believe it's a better option.
Keep in mind that you now have to provide support for 100x the number of users. If you're making a simple iPhone game that doesn't interact with anything else it's probably not a big deal. If you try that on PC, or in a game with a significant online component, you're going to be overwhelmed by the increased support costs.
A $50 game at Gamestop translates to $22 wholesale. If the developer got 15% that means they only get $3.30 a game. They don't need to be selling the game on mobile at $50 to make back their money.
In an arrangement like that, the publisher is going to be funding development up front. The developer gets a small cut because the publisher is taking the financial risk. Even if that game bombs, the developer received enough money to cover operating expenses for the development cycle.
If the developer is willing to self fund, they can get a much better percent of the sales.
Don't know about the previous poster, but in a lot of the New York area you can get Cablevision. They offer 15/5 service for about $45/month. An extra $15/month doubles the rate. There's also 100Mbps down for something around $90-$100 a month. Those numbers all go down a little if you have the triple play package. The lowest end package is fine for me, so I never looked too hard into the specifics on the higher options.
Slashdot Mirror
To be able to publish on XBox Live Arcade, you have to have published at least 3 disc based games for the XBox 360.
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
I agree with most of your points, but I can't really agree with your logic on these. Hardware floating point support wasn't common until the 486 days. A lot of lower end CPUs used to omit support for division. That didn't stop C/C++ from including support for those features.
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it. They were probably left out originally to keep things simple in the early days of C. Now the standard committee seems very hesitant to make changes to the syntax of language, so they probably just look at these things as nice to have but not worth changing syntax over.
If a shared library is already loaded why would the system not reuse the reference to that library it already has loaded rather than attempting to ask the current file system view for to establish a separate reference?
Because that's how it's always worked in UNIX ? Some people think it's a good thing, and that's why this update in place stuff works.
If two programs running in separate memory spaces experience these kinds of side effects while communicating with each other this is a protocol design issue. Remember it is entirely possible to have local versions of shared system/runtime libraries that differ between application because of locally installed DLLs or DLLs within search path.
Ideally, sure. But I specifically mentioned bug fix cases. Stuff happens, things go wrong. You do have to deal with it.
The issue gets worse if on-disk data is involved. You've now got data files potentially being updated by different versions of a library, potentially leading to data corruption or loss.
Who writes an on disk format that changes between versions without properly versioning the file? Garbage In = Garbage Out.
Changing code that's in use = garbage in. I'm not talking things like a document file that's written once and closed, I'm talking files continually accessed by multiple processes.
For a specific example of this happening, back in the days when libc had major changes frequently (think libc5 -> glibc/libc6 days), it was pretty common to do a system update and end up with problems with utmp and wtmp caused by two versions of libc being in use. You'd get garbage output when you ran commands like "who". The problems went away when you rebooted to get rid of everything using the old libc.
It is OK on Unix because that replaced library still exists in memory and can continue to be used by the programs ... running in memory!
Each new invocation of the programs that try to use that library will of course pick up the new version. It's not magic. I don't get why people can't grasp this.
But that's exactly why there is a problem!
Library version numbers generally change when the API changes. If a new version of the library is source compatible with the old one, the version generally stays the same. However, that doesn't mean the internal workings are compatible.
Let's say you've got a library that handles communication between applications. You've got Foo running with library version 1.2.3. The developers discovered a bug in the library's internal data transfer protocol. The bug is an implementation detail, not an application visible one, so they simply fix it and release version 1.2.4. It's 100% API compatible - taking advantage of the fix just requires updating the library. You update the library in place, with Foo still running using version 1.2.3. You start up Bar, which now loads library version 1.2.4. When the two apps try to interact, you're now going to get bugs or even crashes when they interact. They believe they're using the same library, but they're not. You've now run into a class of bugs that only exists because you updated a library that was already in use.
The issue gets worse if on-disk data is involved. You've now got data files potentially being updated by different versions of a library, potentially leading to data corruption or loss.
The index buffer is not updated every frame, just once.
That's not always true. Sometimes it's more efficient to just stick the vertex data directly into the vertex buffer as your frame is generated, then do your draw order sorting at the end by rewriting the index buffer.
Triangle strips require everything in one draw call to be connected. If you want to draw N quads, you have to make N draw calls, passing 4 vertices each time. There's a significant amount of overhead involved in a draw calls, so this is slow. With quad support, to draw N quads you can just make a big array of 4N vertices and process it all in one draw call.
I went from OpenGL 1.x over to OpenGL ES, so I don't know most of what modern OpenGL can do. But one glaring weakness is that OpenGL ES doesn't support drawing quads, only triangles. Yeah, the GPU processes a quad as two triangles internally, but if it supports quads, there's less vertex data to generate and pass to the GPU. You can somewhat make up for it by using glDrawArrays, which uses array indexing into the vertex list, but in a lot of cases (especially for 2D scenes), it's still less efficient than if you had quads.
Because 3rd party developers with early dev kit access were leaking details to the press. They thought it was better to announce it on their own terms than to have all the details leak out that way.
Without the GPL, they would have just used the existing implementation.
With the GPL, they're going to have to recreate the functionality themselves. Their implementation will probably be closed source. They might consider contributing it to the kernel with more permissive licensing terms, but considering how Alan Cox reacted to their request, I doubt it would be received well. Now we'll have duplicate, incompatible functionality being maintained by the kernel devs and NVIDIA. Either that, or NVIDIA will simply do without the feature and release inferior drivers.
The US picked NTSC when Pal was clearly the superior standard.
PAL is higher resolution. NTSC has a higher framerate. They each have some other minor differences. Which one is better depends on your personal preferences.
VHS won out even though Beta was better.
Beta had better picture quality, but suffered from short recording times. The longer recording times mattered more to people. VHS also had better licensing terms, which helped the people making the hardware and pre-recorded videos. VHS was better for most people.
Some felt HD was better than Blu-ray,
Blu-Ray was designed to be the best format possible at the time. This meant new manufacturing factories were required to make them. HD-DVD was designed to be a "good enough" format. It's big selling point was that the discs could be made at existing DVD factories with only relatively minor changes to the equipment. The software end of the specifications each have their pros and cons, but were similar enough that few people had strong feelings about it. Ultimately Blu-Ray won because Sony was committed to building out the manufacturing plants. Once they built sufficient plants, there was little reason to use HD-DVD.
At the time it came out Firewire then firewire 800 were clearly superior standards.
Firewire was great if you were using it for high end equipment that needed high speed data transfers. It was great for things like digital video cameras and external hard drives. It fairly expensive though, and much less flexible than USB. USB won out because it offered enough speed for most devices, was extremely cheap to include in a device, and allowed easy chaining of a lot of devices. For the average computer user, USB was a lot better. While Firewire was still faster than USB 2.0, it wasn't a significant enough difference to matter for many people.
NES games are still playable. The problem is the NES itself - the connector the cartridge slides into gets bent out of shape. It's easy to open the system up and swap the connector. The new part only costs a few dollars.
Blowing on the cartridges never actually did anything to make them work. What did help was simply taking the cartridge out and putting it back in. It would sit differently, and eventually it would sit well enough to make a solid connection with the bent connector.
Tivo has an iOS app. It allows you to do exactly what you want. Control the Tivo, browse TV listings, etc. It sucks to use as a remote as you have to look at it to make sure you're hitting the right button. It's also slower, as you can't just slide your finger around on the screen to get to the next button. With a regular remote, you usually quickly learn your way around it by feel and can use the common buttons easily without looking.
The listings don't work well on an iPhone - the screen is just too small. The guide on the TV screen works much better. It's easier to read and you can fit a lot more information on screen at once.
I haven't tried it on an iPad yet. I'm guessing the listings would be better, but the remote controls would probably be even slower to use with the larger screen.
"better automatic widget layout" - this made my day. I remember using GEOS as a boy, on a C64. It was a lot of fun going from text menus to an actual mouse-relevant UI, but sophisticated it was NOT. Automatic widget layout? There were 8 icons per window and if you didn't like where they were you could (a)bort, (r)etry, (i)gnore.
He was talking about the PC version of GEOS. You're talking about the C64 version. The only similarities between the two products are the name and some members of the development teams.
The PC version had a really sophisticated UI for the time. It was all multi-threaded with automatic control layout similar to how modern UI toolkits work. I found it a pleasure to code for. 15 years ago I was creating UIs much faster than I am today with modern tools.
So I don't need an invitation from an established member?
Missed that one... no, you don't need invitations on LinkedIn - at least not that I've ever seen. To cut spam, a lot of groups require approval to join. I think that simply means that a group admin looks at your LinkedIn profile and approves you as long as what you say in your profile looks somewhat relevant to the group. For most groups you'll get approved within a day or two.
I thought of that until I realized there were no chapters [igda.org] in Indiana. I'd have to take a bus to Chicago or Detroit and rent a hotel room.
Look for similar stuff. Lots of areas have other regular groups / conventions / etc.
That's my problem: I don't yet have a mainstream platform of choice beyond native development (that is, Windows).
Then just pick one. iOS and Android are easy to get into and in demand, so they're probably the best choices now. Make a few small games or apps and get them on the market. Don't think of them as money makers, think of them as resume pieces. The phone app stores aren't money makers for most people, they're mostly marketing pieces. Companies love to have apps to promote their business, and pay good money to have them made. Take that same approach. Release something to show that you're capable of it, then people will trust you to make what they want.
Except when it's an iPhone 4 and the product under development requires the larger RAM in the iPhone 4 and not the iPod touch 4.
Of course. Things like that are why I said "most of the time".
I wasn't aware of that. I thought there were so many job seekers that candidates without their own equipment were rejected outright.
An iPad or iPhone is cheap compared to a developer's pay rate. If you have a good resume and/or recommendations, then not having the exact device the project requires isn't a deal breaker. You're not likely to get a company to give you a Mac, but iPads aren't a big deal.
Which web site do you recommend for searching for video game development jobs near (say) Fort Wayne, Indiana?
GameDevMap.com is a start - it shows 4 companies in Indiana, including one in Fort Wayne.
Check the usual stuff. Craigslist has postings all the time. Check development boards for your platform of choice. Go to IGDA meetings or similar things and meet people there. Keep an updated LinkedIn profile, and subscribe to lots of relevant groups.
Can one do iPhone contract work with just a Mac and an iPod touch?
Works fine for me. Most of the time people say "iPhone" it's shorthand for "iOS devices". Obviously you can't do everything an iPhone can with an iPod, but you can do most things. If you're doing a project for a company, they usually won't have a problem loaning you a device you don't have. Not sure about iPhones, but borrowing an iPad usually isn't an issue.
Aren't smartphone games more for the adult casual gamer with some free time between the events that constitute their life and the nintendo handhelds more for young children with more free time than a life?
That was true in the GameBoy days, but the DS hit a different market. The Pokemon crowd carried over, but the DS blew away the GameBoy because it catered to adults as well. Brain Age and games like that were major sellers - enough so that they released the DSi XL, which was primarily aimed at older audiences (the "can you make the text bigger?" crowd)
They sold a ton, but the DS also has a traditional button layout surrounding the screen. Plenty of games don't use the touch screen for anything other than menu navigation.
Most Wii games aimed at traditional console gamers use buttons heavily.
Correct me if I'm wrong, but I understand that this involves building up tens of thousands of dollars on which to live while seeking a job; moving to Silicon Valley, greater Seattle, or some other area with multiple major video game developers; somehow landing a job with major video game developer; and working there for several years.
No, it doesn't. There's no need to work for a major developer. The closest small developer near you is fine. If you're looking to make handheld games they'll probably be happy with iPhone experience. There's tons of remote iPhone contract work available.
Getting a job at a game company isn't hard if you really are talented enough to deserve it. It's hard to find good people in the industry. Make a small, polished demo and send it with a resume. It'll take you far.
If you can make something of professional quality, it'll take you far. It's a great step in the door at any game developer. Publishers will at least listen to you if you have something decent to show.
The console makers basically care about two things: that you're running a legit business, and that you can finish a game for the system you're applying for. They don't want their dev kits and SDKs and confidential information getting out into the open, and they don't want to waste their time with people that aren't going to finish a game.
Finally, go to the Game Developer's Conference. Just about everyone important in the industry is there. It's not that hard to get some face time with the important people. The console makers all have booths and/or information sessions so you can find out how to develop for them.
You might not, but enough people do that you'll be impacted. You can do cheaper by having email support. But direct customer support isn't even the big concern - as I said before, think about games that interact with online servers. You need to maintain the servers and make sure they scale to match the userbase. If you're dealing with PC games, there will be compatibility issues you'll have to deal with.
The real point is: Are you better off selling 20 000 units of a $50 games or 2 000 000 units of a $0.5 games? The sheer visibility bonus of the second option alone makes me believe it's a better option.
Keep in mind that you now have to provide support for 100x the number of users. If you're making a simple iPhone game that doesn't interact with anything else it's probably not a big deal. If you try that on PC, or in a game with a significant online component, you're going to be overwhelmed by the increased support costs.
A $50 game at Gamestop translates to $22 wholesale. If the developer got 15% that means they only get $3.30 a game. They don't need to be selling the game on mobile at $50 to make back their money.
In an arrangement like that, the publisher is going to be funding development up front. The developer gets a small cut because the publisher is taking the financial risk. Even if that game bombs, the developer received enough money to cover operating expenses for the development cycle.
If the developer is willing to self fund, they can get a much better percent of the sales.
Don't know about the previous poster, but in a lot of the New York area you can get Cablevision. They offer 15/5 service for about $45/month. An extra $15/month doubles the rate. There's also 100Mbps down for something around $90-$100 a month. Those numbers all go down a little if you have the triple play package. The lowest end package is fine for me, so I never looked too hard into the specifics on the higher options.
Even if it was inevitable, they made a hell of a lot more money before it got figured out.