Interesting perspective! You bring up a lot of different points:
- There are tons of positive "post mortem" [http://www.gamasutra.com/features/postmortem/] write ups on gamasutra, but the ones with problems are usually more valuable. One recent example of "doing it right" I remember was the XCOM:Enemy Unknown remake. Check their GDC talks!
- One thing that makes games special is pushing the envelope. Yes, you can make a game on a very solid stack. But it won't stand out.
- Game coders think service people are mad also: How can you use a database that you do not fully understand? You don't even have the source? Using a framework or library or cloud that you do not 100% understand seems "cowboy" to them.
- Games are "fire and forget". That means technical debt is very different. It is bad at the start of a 3 year cycle, but at the end it is totally ok.
- Not mentioned by you but important to point out: While working on games is great for learning and unlike anything else it is also a terrible industry for coders. Insane crunch time. Low pay.
- Games are "fire and forget". That means technical debt
is very different. It is bad at the start of a 3 year
cycle, but at the end it is totally ok.
There is also a big difference between AAA, online, mobile, social, casual, etc. f2p games for example are expected to live & be actively supported/updated for many years if successful.
Clash of Clans was released 2.5 years ago and will likely continue to get active support for many more years. FarmVille was released almost 5 years ago. WoW more than 10, for a different kind of game that also isn't fire and forget.
They get a lot of flack for other reasons but engineering wise companies like zynga get a lot of stuff right.
You are absolutely right.
I was intentionally polarizing. But thinking about it more, one thing still stands out: Even long running mmos are planned "for the next 10 years". There is an end in sight. Facebook, Google, Uber, Bitcoins, Most Startups - it's open ended! I don't think it's easy to say one approach is better - but it is useful to understand that they are fundamentally different.
Personally as an engineer I like the coding approach of game dev a lot more.
> Game coders think service people are mad also: How can you use a database that you do not fully understand? You don't even have the source? Using a framework or library or cloud that you do not 100% understand seems "cowboy" to them.
Not to mention widely used on-premise enterprise software with weird upgrade-paths and hidden costs. If you look behind the curtain there is a lot of legacy cruft in COTS. Customizing such installations seems cowboy-ish to others. SaaS/cloud is better and hide ugly details but may off limits for high confidential data.
Game programmers often reinvent the wheel but learn from others through post mortems (former Game Developer Magazin). Enterprise devs often cook their own customized solution based on COTS. You can still install and play almost all PC games on modern hardware with Win 7+ 64-bit. Try that with old SharePoint, Exchange, SAP, Oracle/Sun, Novell, etc. software and not to mention the troubles to restore an old backup.
As someone who saw both camps, I would say both sides can learn from the other side.
All true (and as someone who spent years building solutions around the various SP releases, I know about its internal problems all too well). Also, while I will use SQL Server without a second thought for most of our development simply because its easy, does its job without problems and our tooling fully supports it, I also know if I have speed issues I'll just throw another server or a ton of RAM at it until the problem goes away; something game devs obviously can't do.
One thing that makes games special is pushing the envelope. Yes, you can make a game on a very solid stack. But it won't stand out.
I know what you're saying, but I wonder how true that is, and my analogy is the movie and music industries. You can make a very successful movie or album without pushing any technical envelopes, infact there are people who consciously and deliberately use "obsolete" tools and techniques.
Game coders think service people are mad also: How can you use a database that you do not fully understand? You don't even have the source? Using a framework or library or cloud that you do not 100% understand seems "cowboy" to them.
Is that really true? When a team uses an engine licensed from another company, do they really take the time to fully understand its source?
There are two factions, groups that license a third party engine and mainly work on the game content and groups that work on an in-house engine and on game content. If you want to make a game that stands out you are generally better of with an in-house engine. Otherwise you have to make compromises and do it a specific way that may hurt the end result. Most Unity and Unreal 1-3 engine based games can be identified as such literally from 50 feets away. In-house engines have downsides as well, and some hobby projects never advance to the gameplay content creation stage.
- There are tons of positive "post mortem" [http://www.gamasutra.com/features/postmortem/] write ups on gamasutra, but the ones with problems are usually more valuable. One recent example of "doing it right" I remember was the XCOM:Enemy Unknown remake. Check their GDC talks!
- One thing that makes games special is pushing the envelope. Yes, you can make a game on a very solid stack. But it won't stand out.
- Game coders think service people are mad also: How can you use a database that you do not fully understand? You don't even have the source? Using a framework or library or cloud that you do not 100% understand seems "cowboy" to them.
- Games are "fire and forget". That means technical debt is very different. It is bad at the start of a 3 year cycle, but at the end it is totally ok.
- Not mentioned by you but important to point out: While working on games is great for learning and unlike anything else it is also a terrible industry for coders. Insane crunch time. Low pay.