Jump to content

Why is AAA development so insane? And is there an alternative?


Recommended Posts

4 hours ago, Alex W. said:

In film, you made decisions like this at the pre-production stage or earlier. Like, The Matrix had to invent its version of Bullet Time and an entire visual language, but those were done before they had actors and crew standing around on set. Where decisions like this haven’t been made before production starts, it’s usually a sign that production is catastrophically dysfunctional - like Alien 3’s abandoned dog-in-a-costume effects and sets that were designed for a different script. Tales of studio execs or directors asking that fundamental  things be redone on set in production are considered exceptional, not the norm. Yes, movies go back and change things after previews, and these days a movie might basically be “designed” in reshoots but even that is after completion, and an eye to not redoing the whole project.

 

I suppose the other comparison we could make is to the music business. There are loads of stories of bands coming to the studio with some songs completely unwritten, so they spend studio time and money writing, when ideally they would be recording things that had been written, arranged, and rehearsed in advance. Or of scrapping everything and redoing it from scratch, sometimes going halfway round the world to redo it in a different studio. (The most extreme and infamous - and relatively rare - examples being things like Guns n Roses' Chinese Democracy and The Beach Boys'/Brian Wilson's Smile.)

 

Obviously there's a difference in scale. If you have to pay people to hang around doing nothing while they wait for the artist to overcome writer's block, then as long as you're not paying for a whole orchestra, then presumably it's less expensive to do that in a music studio than it is on a film set or at a large game developer!

Link to post
Share on other sites

I remember reading about the problems Destiny had where the content creation pipeline wasn't set up to work efficiently with a game that is supposed to be updated regularly. A small lighting tweak or adding a new object meant having to a full re-render of the entire level overnight. It seems like that should be the first thing you sort out. 

 

Continuing the film analogy it's like realising you used the wrong camera after you've already shot the film, or the microphones weren't turned on so have to redub everything. Which does happen I suppose, seemed like Robert Downey Jr redid all his dialogue in that Dr Dolittle film 

Link to post
Share on other sites
Quote

People outside the games industry CANNOT POSSIBLY IMAGINE how much time and effort is spent building and rebuilding the 'First Time User Experience' - i.e. first 15 minutes of gameplay.  Easily an order of magnitude more effort than any other content.

 

No. I can not possibly imaging. The first 15 minutes of AAA is usually some boring cut scene I can't skip. The next 15 minutes usually specialise in not showing off why the game's in any way worth my time.

Link to post
Share on other sites

Great thread. I need to spend some time reading the responses so far because there's excellent stuff in here.

 

I think a lot - not all - of these issues still pop up because many in the  games industry are either still wary or resistant to user research. I have been doing games user research - or games UX research - for years now and the primary market for this kind of work is mobile free to play. Because those developers are laser focused on the FTUE, and on retaining players over the course of the first week. And the nature of the competition too, perhaps (as in, if you want players to give up their time for your game above the other free games out there, it had better be a bloody smooth onboarding experience). 

 

But games user research is still a bit too focused on methods that require a playable prototype (or more). I've always tried to push for methods that can be used even before that: competitor analysis, wireframe (or pen and paper) UX analysis, stakeholder interviews, etc. It's just that the old methods and ways of working are hard to break. Developers (and sometimes more importantly publishers) usually 'get' playtests at least, so they're the first port of call, but that happens so late in the development process when it's dependent on a playable prototype, and the devs often won't let it happen until they feel that the game is representative of the full experience. And I always say, it doesn't need to be: we're testing mechanics, fully recognising that the magic stuff will come later on.

 

Link to post
Share on other sites

The game I'm working on now has had some talk of significant user research (from the design team), but our publisher won't give us the money to do it or the time to implement the findings if we do manage to get some done.

 

The AAA games where you hear of it being done are always the ones that take years and years to make and generally get a "when it's done" treatment by the publishers. And still end up with significant crunch. There's a good TLOU2 video/article floating around somewhere where a level designer talks about how they used user research and constant playtesting to nail a level. That single level ended up being revised multiple times, taking more time and having more artists working on it than are on my entire (non-AAA) project right now.

 

I think you've got a fair point about being resistant to let the game out of our hands until it's representative, but on my part it comes because even within studios, you can hand a build to someone and ask them to test the puzzle mechanics, and the feedback you get in return is that the movement isn't good enough and you suddenly find yourself in a position where you've got to stop working on the puzzle mechanics and totally redo the movement because the studio head's concerned that the publisher will be unhappy when you deliver the milestone that's supposed to prove out puzzle mechanics. Which leads to wasted work when, months down the line, it turns out that your original idea for the movement was better after all, and it just wasn't ready yet.

 

That's not a hypothetical, by the way. I've had that exact thing happen. And if you swap out the two systems I've mentioned above for others, I've had it happen multiple times at multiple studios.

 

If that's what happens within studios, what will happen with external tests? If I need to isolate that one mechanic and build a playground for it, that's also time that's got to come in pre-pro, and pre-pro schedules are insanely tight as it is.

Link to post
Share on other sites
21 minutes ago, Scribblor said:

The game I'm working on now has had some talk of significant user research (from the design team), but our publisher won't give us the money to do it or the time to implement the findings if we do manage to get some done.

 

The AAA games where you hear of it being done are always the ones that take years and years to make and generally get a "when it's done" treatment by the publishers. And still end up with significant crunch. There's a good TLOU2 video/article floating around somewhere where a level designer talks about how they used user research and constant playtesting to nail a level. That single level ended up being revised multiple times, taking more time and having more artists working on it than are on my entire (non-AAA) project right now.

 

I think you've got a fair point about being resistant to let the game out of our hands until it's representative, but on my part it comes because even within studios, you can hand a build to someone and ask them to test the puzzle mechanics, and the feedback you get in return is that the movement isn't good enough and you suddenly find yourself in a position where you've got to stop working on the puzzle mechanics and totally redo the movement because the studio head's concerned that the publisher will be unhappy when you deliver the milestone that's supposed to prove out puzzle mechanics. Which leads to wasted work when, months down the line, it turns out that your original idea for the movement was better after all, and it just wasn't ready yet.

 

That's not a hypothetical, by the way. I've had that exact thing happen. And if you swap out the two systems I've mentioned above for others, I've had it happen multiple times at multiple studios.

 

If that's what happens within studios, what will happen with external tests? If I need to isolate that one mechanic and build a playground for it, that's also time that's got to come in pre-pro, and pre-pro schedules are insanely tight as it is.

 

I agree with pretty much all of this. I think what you're highlighting too is the immaturity of user research for games, and the GUR industry (well, such as it can be called) in general. If you've been handed back a research report I'd generated - either from an internal department or an external agency - and it's gone so wildly off-piste from your research question that it's influenced your higher ups, than that's my fault. I've seen it happen from the other end too (in terms of the actual report generated, rather then the fallout for the dev). For me, I think it's up to me as the research lead to recognise that you haven't had the time or resources to build a demo/playground around a single mechanic or feature to be tested, and isolate it as part of the process (and if I can't, be super clear about it up front).

 

I mean, also, the other failings with GUR is that we're not great at explaining what it is we do, and that the agencies out there price themselves at a level that only makes them viable for developers attached to bigger publishers. That TLOU2 example is very Sony (or similarly ubisoft) who have their own massive testing setups and resources, but although I think such intensive work on a single feature or level can turn out great, it's a case of massively - ridiculously - diminishing returns.

Link to post
Share on other sites
4 hours ago, ChewMagma said:

 

I wonder if this is still true today in the UK film industry today though?

 

I have a friend who works in the art department on the Fantastic Beasts films and he has straight up told me that the reason so much film industry stuff gets done in the UK now is because we are not as heavily unionised as the US equivalents and we have enough loopholes in our labour laws that most people in the industry are signing away all of their working rights.

 

And if it's someone with enough clout, they'll just do what they like anyway because they're never held to account for it. A real eye-opener when you read praise of blockbuster directors consistently coming in under budget.

Link to post
Share on other sites
On 18/12/2020 at 13:25, monkeydog said:

 

No. I can not possibly imaging. The first 15 minutes of AAA is usually some boring cut scene I can't skip. The next 15 minutes usually specialise in not showing off why the game's in any way worth my time.

 

Was my first thought as well. :lol:

 

I dread starting any kind of 'AAA' game now, as the intros are invariably padded out with boring cinematic stuff and clumsy tutorials that teach you the mechanics in the least natural way possible, despite modern games all basically having the same control schemes anyway. Super Mario 64 was a lot of people's first experience of a 3D game, or at least of controlling a game in that way, yet Nintendo had enough confidence in players to simple drop you in the Castle Gardens and let you discover the mechanics yourself. Same with Liberty Island in Deus Ex. I don't buy the idea that modern games are vastly more complicated than older games (they're not) or that players now are less willing to learn through experimentation and so need more hand holding.

Link to post
Share on other sites
8 hours ago, ChewMagma said:

Reminds me of Mario 64 - I don't know if it apocryphal, but apparently they started that with just a tech demo of Mario moving in a more or less empty space because how fun his movement is was going to be critical to how much people enjoyed the game.

 

You can also imagine that is how BOTW started - "let's make world traversal super fun and everything else in our open world will follow."

 

But for kitchen sink AAA now how would it work? People want massive, fully realised open worlds with TV quality narratives but with complex RPG systems, great gunplay, realistic driving simulation etc etc. How can one studio achieve all of those things in one game?


It isn’t unusual to have this sort of thing, test levels just to try things.  On Fable 2 we had a sim test level with the basics of our simulation to try out so we didn’t have to wait for the real regions to develop things.  Similarly we had combat arenas for testing out the combat ai.  But even then there’s be issues in the actual levels that wouldn’t come up in the test levels.  If you look at making ofs for various games you can see this type of thing of a lot of them, especially is they’re combat or movement focused.  Even if you don’t have those you’ll have debug commands to get into the situation you need.

 

I think Damion’s thread deals with this but the conversation around crunch recently highlights to me is there’s a lot of people who think games are made in a linear fashion - you know what you want to make and you make it.  That’s simply not the case, there’ll be a few exceptions as usual, but no game I’ve worked on has ever been that.  There’s always changes, maybe it works on paper but not in reality, maybe it just doesn’t work with the other systems, maybe it’s just not fun enough, etc, etc.

Link to post
Share on other sites

Is part of the problem that most AAA games are trying to make everything as photorealistic as possible? As soon as you’re aiming for that any issues with the physics, or interaction with other characters and environment just seems to be amplified. 
 

Cyberpunk is a proper mess but if they hadn’t aimed for that hyper realistic world, the issues wouldn’t be so pronounced. 

Link to post
Share on other sites
8 hours ago, Alex W. said:

I’m less confused by the cuts - which are fully understandable - than by how late they are. It would be, like you say, having a scene written, shot, lit, and gone through most of post production before anyone realises it is garbage and has no prospect of being used. It’s a wild level of inefficiency.

You know this happens all the time when they make films, right? 
 

Scenes and sometimes whole plot threads get cut or reshot during the making of most films.

 

Art is not always efficient, as it’s ephemeral. If there was a formula, everyone would just do that. 
 

Another aspect about throwing away work and prototyping - sometimes you do have more time to prototype, but there’s a huge danger that the prototype slowly but surely stops being a proof of concept, and becomes the the core code - although the code is usually a bit crap cos it was hacked together to prove the concept as quickly as possible. This then leads to either having to ultimate rewrite the entire code base from scratch down the line (which could cause delays/costs) or butching it out with the original code base, and risk the whole thing collapsing in a buggy mess just before you ship. 
 

Neither solution is ideal. Of course the best solution is to start building as our it’s the final product, but this takes more time, and people are often unwilling to take that time and cost, just to prove an initial concept. 
 

TLDR; Good games are hard to make. 

Link to post
Share on other sites
8 hours ago, squirtle said:

Just on this... Why would you not have all your values in a table or something and use something like an enum to keep track of what is being controlled? As soon as the device being controlled changes, you pull the different physics values from the table and plug them in to your control system. Alternatively, have them assigned to the vehicle or object itself and as soon as that is being controlled, take those values and plug them in to the control system. Why would you be changing global variables?

 

With a game engine (or at least Unity, as I've no experience with others) the physics engine is a bit too much of a black box without going and creating a lot of bespoke behaviour. Hence if you're quickly spinning something up using some of the stock controllers, they're all hanging off the same physics system which is getting updated all at once at a time not entirely of your choosing. Your time for grabbing fitting parameters has past.

 

In my experience, that leads to the horrors Broker talks about. And the way to avoid it is to create bespoke code, rather than relying on some all-purpose physics engine. A person behaves differently to a car, and you'll get better results working from that principle than hoping to shoehorn in one system that works for two very different things.

 

(Apply this to every other aspect and it sums up why I prefer writing games in Monogame instead of Unity)

Link to post
Share on other sites
6 hours ago, Nate Dogg III said:

They're all miracles, even the bad ones.

This is pretty much the reason most people who work in and around the industry still do it, isn’t it? You get to see, or help, will these pocket universes into existence.

 

I’m not going to set out my soapbox and go off on one about project management, I’ve done that enough already and I like my job and I understand why people make the decisions they do a lot more now.
 

I will say though, that sometimes you sit and prototype the product out, and you have the whole thing proved out in record time, and management cuts it because the prototype isn’t sexy and they’ve got some huge boondoggle to ship. Or you prototype, but you scale up and some hideous issue you could never predict emerges. Or you have a creative lead with a firm hand on the tiller, and they never let an idea get too far along without deciding they want to keep it.

 

It’s not a solved problem by any means. I do think people need to drown their ugly babies a bit more often though.

Link to post
Share on other sites
2 hours ago, Fry Crayola said:

 

With a game engine (or at least Unity, as I've no experience with others) the physics engine is a bit too much of a black box without going and creating a lot of bespoke behaviour. Hence if you're quickly spinning something up using some of the stock controllers, they're all hanging off the same physics system which is getting updated all at once at a time not entirely of your choosing. Your time for grabbing fitting parameters has past.

 

In my experience, that leads to the horrors Broker talks about. And the way to avoid it is to create bespoke code, rather than relying on some all-purpose physics engine. A person behaves differently to a car, and you'll get better results working from that principle than hoping to shoehorn in one system that works for two very different things.

 

(Apply this to every other aspect and it sums up why I prefer writing games in Monogame instead of Unity)


That’s a Unity thing, everything is a black box even their engine unless you’re paying a shitload for code access.   So much of Unity development is working around their limitations.  It’s a right exercise in frustration, their excuses is the licenses they have for all the third party APIs but Epic can manage it… For every good thing there’s a shitload of frustration, and I say that as someone who started using it in 2012, and had exclusively used it for the last 6 years - I’ve a real love hate relationship with it.

 

You can use an all purpose physics solution, but doing it yourself isn’t the same as using the wrapper Unity has around PhysX.  It’s just a tool and solver, you still need to do a lot of integration and set up, and custom physics models and rag dolls, etc, etc.  You’ll need a physics coder, tech artists, and so on.  (For example on Black & White 2 we used Math Engine but our physics coder had to implement frag meshing for breaking the walls, I remember him with the SIGGRAPH papers)  Just using stuff straight never gives the best result - remember all those UE3 games that looked the same, slightly too shiny, cause they just used the base shaders.

 

Hell, I’ve even written a fixed point physics engine to use instead of Unity’s, cause apparently I hate myself.

 

Unity’s been great for the accessibility of game dev, but man the way they tell newcomers to do things are generally some of the worst ways.  And to get the best out of it you have to fight it.

Link to post
Share on other sites
2 hours ago, Fry Crayola said:

 

With a game engine (or at least Unity, as I've no experience with others) the physics engine is a bit too much of a black box without going and creating a lot of bespoke behaviour. Hence if you're quickly spinning something up using some of the stock controllers, they're all hanging off the same physics system which is getting updated all at once at a time not entirely of your choosing. Your time for grabbing fitting parameters has past.

 

In my experience, that leads to the horrors Broker talks about. And the way to avoid it is to create bespoke code, rather than relying on some all-purpose physics engine. A person behaves differently to a car, and you'll get better results working from that principle than hoping to shoehorn in one system that works for two very different things.

 

(Apply this to every other aspect and it sums up why I prefer writing games in Monogame instead of Unity)

I get that, but I still wonder why you world be altering global values when you change what you control. Unless I've misread the original post. 

Link to post
Share on other sites
3 hours ago, jon_cybernet said:

You know this happens all the time when they make films, right? 
 

Scenes and sometimes whole plot threads get cut or reshot during the making of most films.

 

Art is not always efficient, as it’s ephemeral. If there was a formula, everyone would just do that. 
 

Another aspect about throwing away work and prototyping - sometimes you do have more time to prototype, but there’s a huge danger that the prototype slowly but surely stops being a proof of concept, and becomes the the core code - although the code is usually a bit crap cos it was hacked together to prove the concept as quickly as possible. This then leads to either having to ultimate rewrite the entire code base from scratch down the line (which could cause delays/costs) or butching it out with the original code base, and risk the whole thing collapsing in a buggy mess just before you ship. 
 

Neither solution is ideal. Of course the best solution is to start building as our it’s the final product, but this takes more time, and people are often unwilling to take that time and cost, just to prove an initial concept. 
 

TLDR; Good games are hard to make. 


yeah I’m a writer like many of us on here and I’ve deleted entire scenes, characters, plot threads, settings, you name it. Well, saved to an Orphan folder in case it works in something else. A lot of that involved rewriting other stuff that depended on the stuff I deleted, can’t imagine what it must be like with code instead of just words and storytelling

Link to post
Share on other sites
1 hour ago, squirtle said:

I get that, but I still wonder why you world be altering global values when you change what you control. Unless I've misread the original post. 

 

I understood Broker's post to be about the settings for the physics engine when it's updating, which you don't have direct control over. Like if a certain value for gravity* works well for on-foot controls but makes vehicles unrealistic when you add them. So you go back and tweak that and find then that helicopters need something else.

 

My reading could be wrong, though.

 

*this is an example as it's a trivial thing to change on a per-object basis in Unity

Link to post
Share on other sites
21 hours ago, Cosmic_Guru said:

What do we expect of the forthcoming Fable, the Obsidian one, Elder Scrolls VI, DA4 and Mass Effect?  Are people inevitably going to be disappointed? 


Fable is really exciting because the team have extensive experience of triple A but mostly they’ve made racing games. I’m really interested to see what they do, although I hope it’s not too twee and ARRY POTTA.

 

The obsidian one will be interesting but hideous, the new elder scrolls will be unique in scope but broken to shit and poorly written, DA4 and Mass Effect will be boring rip offs of recent popular games because that’s all BioWare do now.

 

20 hours ago, squirtle said:

Just on this... Why would you not have all your values in a table or something and use something like an enum to keep track of what is being controlled? As soon as the device being controlled changes, you pull the different physics values from the table and plug them in to your control system. Alternatively, have them assigned to the vehicle or object itself and as soon as that is being controlled, take those values and plug them in to the control system. Why would you be changing global variables?


I’m not really sure exactly how the physics engine works to be honest, but I do know that changing it’s values feels different to changing the ones on my character. When I’m making a platform type prototype, there’s a difference between altering the gravity scale of the world and the gravity on my individual character, and I’ve got no real idea why, but generally I’m changing both and balancing them until the jumping feels nice. Then I try to add something else later and it feels horrible with the gravity, so I save the gravity settings I had for my jumping and go back to tweaking. I see that it would be good to know what I needed and save a list beforehand but the problem there is that your project quickly fills up with lists and variables that you think you might need at some point but never do, and every time you go to add an enum you’re scrolling past the 30 you wrote that aren’t actually implemented in code yet and it’s confusing as shit.


Much like my structures, where the advice is to know exactly what variables you want to store in them before you make them, I often have no actual idea what I’ll need before I’m making it. Sometimes I start again from scratch and rewrite the entire thing once I know what I need, and it’s always better and neater and more efficient that way, but the further in you get the less viable that is, and the more risk you run of ending up with systems that work but you’re not totally sure how and don’t want to do them again because designing a controller driven menu in UE4 is a nightmare and it works now.

 

20 hours ago, petrolgirls said:

 

It's strange to me that other publishers can see how well Nintendo's games play and how that translates into huge financial success for them and yet won't emulate their methodology. 

Need that cash by next quarter though, otherwise shareholder bonuses won’t be as big.

 

20 hours ago, deerokus said:

I remember reading about the problems Destiny had where the content creation pipeline wasn't set up to work efficiently with a game that is supposed to be updated regularly. A small lighting tweak or adding a new object meant having to a full re-render of the entire level overnight. It seems like that should be the first thing you sort out. 


Destiny is the Chinese democracy of games. They hired Paul Macartney to record an entire album for the soundtrack that they decided not to use in the end. The realised six months before release that their story was rubbish and had to rewrite it from scratch using the bits they already had randomly Frankensteined together. The hired Tyrion and only gave him time to do one pass on each line of dialogue, while he was asked to record hundreds per hour with absolutely no context about what was happening when his character said those things. That project is like watching people pour money into a fire. 

 

15 hours ago, the_debaser said:

Is part of the problem that most AAA games are trying to make everything as photorealistic as possible?


It certainly doesn’t help keep teams smaller, and the more people you have the harder they are to wrangle. 

Link to post
Share on other sites
10 hours ago, The Bag said:

Unity’s been great for the accessibility of game dev, but man the way they tell newcomers to do things are generally some of the worst ways.  And to get the best out of it you have to fight it.

Oh Lordy, the fun I've had with Unity. I think it's a great product and some superb titles have come along because of it, but all the tutorials teach you these incredibly inefficient ways of doing things, full stop. Then you get their technical advisors in to help get your title up to snuff and they tell you the secret "correct" way. All the little indie/ student projects out there that suck because they did things the way they were taught to.

 

This is all back before they implemented the job system mind. I should go and have a shot at building something with it now.

Link to post
Share on other sites

One of my favourite talks at Unite every year is Ian Dundore (a Unity employee) telling you everything they tell you is wrong and this is how you should do it.  Highlights include him getting the audience to heckle Unity’s UI lead at the back of the hall for the the decisions made in that system. :lol:

Link to post
Share on other sites

I've not worked in professional game development, but I have been a software developer for over 20 years now.  I think a few of the game devs here have explained the process now, but perhaps not the origins.

 

The origins are rooted in Agile development ( https://agilemanifesto.org ) where as developers we want to iterate quickly on a product (or an area of a product) to improve it, whilst focusing exactly on what the end user wants. 

 

To do that we make a quick and dirty prototype based on what the customer told us they wanted. We're able to let the QA dept test that, show it to the customer. The customer then feeds back 'yeah this bit is good, but this needs tweaking like this' and we iterate and repeat the process.

 

At some point this great idea either makes it through to the final product, or if it's not going well it will be scrapped. The whole idea of fast iteration like this though is that you get the valuable/important bits done first, and if something isn't working as expected you find out sooner than later.

 

As developers this is however much MUCH more preferable to the old way we used to do things, which was the 'waterfall' methodology where all the decisions were made up front and set in stone.

 

https://manifesto.co.uk/agile-vs-waterfall-comparing-project-management-methodologies

 

The danger of the waterfall method where decisions are made early is that the cost of changes later in the lifecycle are INCREDIBLY expensive and often times impossible (short of a complete rewrite).  An analogy might be if you were a building architect and just as you've finished the building and putting the carpets in, the client comes back and says 'I want a balcony there'. If the foundations can't support that dream, you either scrap it and start over or smash their vision.  For software it's not so much different.

 

If you're a professional dev and haven't come across any of this before (or perhaps are new enough to not have experienced the nightmare of waterfall based development) then I can highly recommend this video by Ken Schwaber : https://www.youtube.com/watch?v=IyNPeTn8fpo

Link to post
Share on other sites
18 minutes ago, The Bag said:

One of my favourite talks at Unite every year is Ian Dundore (a Unity employee) telling you everything they tell you is wrong and this is how you should do it.  Highlights include him getting the audience to heckle Unity’s UI lead at the back of the hall for the the decisions made in that system. :lol:

:lol: Totally justified! Oh the stories I could tell about Unity UI frameworks.

Link to post
Share on other sites
25 minutes ago, Wizcat said:

An analogy might be if you were a building architect and just as you've finished the building and putting the carpets in, the client comes back and says 'I want a balcony there'. If the foundations can't support that dream, you either scrap it and start over or smash their vision


I broadly understand what you’re saying about agile, and it totally makes sense, but I’m not sure I understand why it precludes making decisions about the scope of the work at the beginning? Your example above illustrates this - if a balcony wasn’t originally in scope it’s very easy to identify why a huge time and resource investment would be needed to redesign and build from scratch. 

 

I’m a project manager so I have a natural bias against scope creep and deviations from spec, but both are completely reasonable so long as everyone involved understands that changing the scope later implies delay and increased cost. 

Link to post
Share on other sites
1 hour ago, Broker said:

It certainly doesn’t help keep teams smaller, and the more people you have the harder they are to wrangle.


There’s got to be something to this. 
 

Mario 64 was built in 2 years with a dev team of 15 people. It’s crazy when you compare the time of development and team sizes now and the experience in 3D which people have. And the games still aren’t any better. 

Link to post
Share on other sites
24 minutes ago, Spacehost said:

:lol: Totally justified! Oh the stories I could tell about Unity UI frameworks.


Bane of my fucking existence, I currently work with 2 of the best UI artists I’ve ever worked with but duck me what they want to do regularly pushed unity’s ui to breaking point.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Use of this website is subject to our Privacy Policy, Terms of Use, and Guidelines.