That seems so wasteful and challenging, anyone from the industry care to comment on how a studio would get itself into a situation of effectively zero reuse of their code?
That seems so wasteful and challenging, anyone from the industry care to comment on how a studio would get itself into a situation of effectively zero reuse of their code?
It also doesn't help that due to the structure of the industry (e.g. work hours, low pay etc.) they have trouble retaining developers and instead replace them with fresh grads. A huge percentage of people I know left the industry before they hit 30 (myself included). This leads to a lack of experienced engineers.
Ass properly covered, I'll be real: I'm never surprised to see this because "code reuse" is generally the sign of reasonably advanced developers and I don't know a single person in game development I would hire for a role outside of it. It's not just NIH--that's a problem but one slowly going away. It's more just a fundamental lack of understanding of software engineering and building Good Code. As time goes on I've seen gamedev acquaintances poorly reinvent most of the wheels that the rest of the world takes for granted--even something as simple as serialization for save data and network transport (but no schematic validation, because "schemas suck") was trumpeted to me as this Big Crazy Great Thing. Which contextually it may be, but I kind of feel like the state of the art for stuff not involving pointer munging is about a decade behind everybody else.
So, code reuse? Gotta make good code first.
I worked in a company that went from doing software gigs in general to be full mobile gaming company. Before it was quite standard Agile style company: Scrum, code reviews, TDD, cross-functional teams (front end devs knew how servers works in general), focus on quality over quantity (one dev, rotated weekly or biweekly, focusing on fixing bugs), separate concerns.
After going full game-oriented, company hired couple of people from gaming industry into higher positions - tech leads, project managers etc. Over couple of months, people with many years of experience in those big companies dismantled what was standard for me, using combination of two arguments:
- big names don't do it, so it must be wrong - it's a waste of time
Before I quit, there were no longer code reviews (waste of time), all testing was to be handled by QA team (waste of valuable dev time), ship with issues (waste of time to fix minor bugs when can add features), single system responsibility (one dev to write code for client server protocols, one dev for UI, one dev for assets etc, that's gow big names do it).
At one of the last talks with "industry veteran", when I mentioned those things - and how negative, in my opinion, those changes are, his response was "so you are saying that whole gaming industry dev practice is wrong". At that point I thought he's right and I sound full of crap, now I believe that yes, AAA companies are simply bad development practises shops.
My guess as to why is because AAA is very strongly driven by deadlines and marketing, where you cannot simply delay release (Christmas shopping spree is coming). This idea I saw articulated on HN first and I agree with it.
For example, look at Assassin's Creed - will the bad launch cause people to avoid AC in the future? Maybe, but probably not.
I could see arguing here with myself that AAA games are usually "ship and forget", with some bugfixes only. Maybe because company I was working in was not AAA, but small (by industry standards) f2p mobile shop, where applying AAA ideas is not that great (in my opinion). I mean that's where your product is more along lines of web apps - you are going to constantly add content, update code base, refine features, so focusing on quality in long term is better. This, thought, I was not able to articulate clearly and properly to AAA veterans.
I feel like not all ideas from current practises can be applied to big gaming studios, but saying that I believe it can be improved. This may need time and risk that companies that are big enough to be called AAA are not willing to take.
Why two companies you mentioned failed? I think we can assume there might be more reasons to that than only being Agile, maybe their games were just not that good, or IP was boring? Still you sound like you have more experience than me here, I'm trying to wrap my head around whole AAA industry thing. I'm ranting about it so much because making games was way more entertaining than web/mobile, but the industry is so poisonous for pure developers that I had to quit to regain my sanity :)
>This may need time and risk that companies that are big enough to be called AAA are not willing to take.
Infinity Ward, the original home of $1B+ games, had about 100 people at the time of the split from ATVI and founding Respawn. It's about the same size now as well as the Respawn. Media Molecule is just a few dozens. Size does not make a AAA studio.
And you don't even need to show the best practices right at the AAA level - start small and if it's any good people will copy you or, at least, you should be able to grow yourself.
>Why two companies you mentioned failed? >I think we can assume there might be more reasons to that than only being Agile
Indeed, it would be naive to blame Agile on destroying multi-million businesses. Agile seems to be just a symptom. It could be that the management sees that the development process is failing and tries to improve it with a well advertised technique, for example. Or that some Agile enthusiast gets too much power due to the weakened culture. What I was trying to say is that very few AAA studios practice it now and the ones that did in the past are not in the business any more.
Also, there is no single AAA development way. For example, Valve's practices are very different from Bungie's, which are different from the R*, which are different from ATVI's COD teams etc.
Shitloads of money. Massive institutional knowledge of public relations and marketing. Direct lines to Sony and Microsoft. Every kind of benefit of economy of scale you could want.
It's not like the idea of a barrier to entry is a new concept.
It's pure meritocracy here, if you are good then getting a publishing deal is not a problem.
The core of an "AAA studio" is a big fat wallet. It's essentially definitional. You're not actually saying anything with respect to them in any of your posts.
AAA do get a lot of money but it's the effect of them making games that sell well. There are dozens of startups in SF that cannot make even mobile games with their piles of cash and hundreds people. Money do not make you a AAA studio.
The problem is not whether or not game developers know how to reuse code but whether or not it makes sense or are allowed to reuse it. One big challenge when you are going to reuse code is not having a stable set of requirements (which in gaming is almost non existing even in the late stage of a project) and when you take that and join it with tight and unreasonable schedules you would have a huge mess as result.
The state of the industry is very unhealthy in my opinion and I wouldn't be surprise if there is another dark age for videogames coming up.
Add to that that each framework has its own standard and way of doing games (event-base, component-base, etc.). The worse part I think is the game logic is generally enclosed in framework-specific objects like events in as3, components in unity, etc.
Virtualizing that would be expensive, tricky and costy in terms of performance.
The difference between engine optimized for certain platform is simply massive. We're talking at in the worst case 10x the performance difference.
Why is this? Let's take modern console game for PS4. It uses mantle like API where you can simply spam drawcalls like no tomorrow. Port that to DX11/OpenGL and you'll choke.
Or move a simple OpenGL game from PC to mobile, it does nothing fancy and uses ES2.0 subset of OpenGL so it should work nicely? Not quite. All your scenes are built using effects that cause massive performance penalty in tile based renderers. Sure it works fine on Tegra K1 but everywhere else it's horrible.
On the other hand there is a way of doing multiplatform development. It means using Unity (or other multiplatform engine), limiting yourself to a common subset and leaving the optimization part to be the headache of the engine developers. However even if you use Unity you have to manually consider the effects you are using on per platform basis.
After the Amiga/Atari/Commodore/etc era when games were ported on every platforms came the PC age (which was relatively divided from the consoles during a long time). Now heavy crossplatform is back again.
That's amazing.
So you do the safe thing everyone else is doing, Cocos2D and Objective C. You'll worry about porting later, if the game does well. Maybe you'll just pay someone else to do it.
They could have used AIR on mobile to re-use the AS3 codebase. Alternately, they could have done c++ on cocos2d-x instead of objective c, so that would have been pc portable.
They would just have to write it twice, in that case. However, if you are a group of AS3 devs jumping to mobile, they probably picked the best sounding thing at the time - which was cocos2d.
Keep in mind android wasn't really a game platform in 2011, so choosing cocos2d in obj-c over c++ wasn't really a bad call.
Basic, C and Pascal were the Python and Ruby back then.
So porting studios appeared, specializing in porting the games to specific platforms. The porting industry came to life.
Fast forward 30 years, you still need to write quite hardware specific code if you wish to squeeze out every possible ms out of the machine, which opens the door for all kinds of shortcuts.
This of course only matters when doing AAA games.