5 ms·

"But changing gameplay from 2D to 3D had a major impact on overall development cost (we found out a little too late)" Not to pile on, but this was very surpris

"But changing gameplay from 2D to 3D had a major impact on overall development cost (we found out a little too late)" Not to pile on, but this was very surprising to me... how could you not know that this would have a major impact?

valarauca1 11y ago
>Passion and commitment are not a substitue for experience The author explained more or less. Inexperience.
- jeremiep 11y ago
  I say the exact same thing about Agile practices, "methodologies and procedures are not a substitute for knowledge and experience." That message is a LOT harder to get through than it seems.
  - karlkatzke 11y ago
    Digressing a little from the central topic -- Yeah, it's actually amazing how hard that message is to get through. And you even see a dichotomy where the HR side of a company will understand that and will go out of it's way to hire experienced people and retain them, but Product/Project Managers will completely discount them to the point of driving experienced people out of a business when the knowledge and experience says "Build it X way or you're in a world of hurt a year from now. I lived that once and I don't want to live it again." Or, put another way, "Security is not a feature the business needs at this time in this PII-heavy project."
  - Cthulhu_ 11y ago
    OTOH, if they embraced the agile methodology, they could've said "We do not know how long it will take, it depends on our velocity which we haven't yet established". $72K for a team of 6-10 developing an AAA-level game is just unrealistic.
    - jeremiep 11y ago
      I really don't like velocity as a metric. It's about as useful as counting lines of code to judge a project's completion. I don't think I could explain it as well as Dave Thomas says it, so here's a link to his fantastic keynote: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M
      - mikekchar 11y ago
        Unfortunately the link is a little longer than I have time to view today, but I will put it on my to-watch list ;-) As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process. The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes. However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem). In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes. That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on). Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.
bluedino 11y ago
Bit off more than they could chew? Didn't have an extensive background in game building? Perhaps they just never built a 3D game before? It's kind of like when some of the first 3D games came out, modelers would model a brick then build a wall out of them, instead of just modeling a brick wall other ways, like putting a brick texture on a regular wall. They probably just couldn't come up with a good way to 'cheat' 3D collision detection that worked for them. Approximating is a huge part of game algorithms even with the power of today's hardware.
- tinco 11y ago
  Because from a distance it actually doesn't seem like so much work. The assets get crazy expensive, but they already had that covered. 3D collision detection and resolving is a solved problem, you can just get off the shelf components (for free), the real problem isn't gettin the game to work, the problem is in the polish. Jumping over fences, AIs chasing over 3d terrains, making sure people don't get stuck in random stuff. Everything needs weird edge-case stuff that's not in a generic physics engine. Perhaps they should've first made a 3d game with 2d physics, those games look great and the overhead is much more manageable. But hindsight is 20/20 and from what I've gathered they actually got really close to a great game.
  - pmelendez 11y ago
    > the real problem isn't gettin the game to work, the problem is in the polish Exactly this... Pareto principle (applied to time) is really relevant in this case.
- a-nikolaev 11y ago
  Agreed, game development is the art of making illusions. Proper simulation, or any kind of complex machinery working behind the scene rarely adds a lot of value to the resulting game (sadly). And moreover, I'm certain that relying of cheap tricks is the greatest virtue in game development. And there is nothing derogative or ignoble about that. Knowing where to cut corners is an extremely valuable skill, and it requires a lot of intelligence, experience, and careful planning. Computer games are a lot like real-life magic. The best results are achieved if you do cheap tricks, but you do them well..
gdulli 11y ago
Seems like an inevitable side effect of making fundraising an impulse buy that circumvents due diligence. Not that it's inevitable to happen every time, or that crowdfunding can't succeed, just that the odds of a really basic sort of failure that could have been surfaced early on are a lot higher.
pmelendez 11y ago
I worked once for a (non-Indie) game studio and HQ asked us to change our engine from 2D to 3D to accommodate some 3D art(in the middle of production). It implied a lot of work but the studio had the means to put some very experience people focused just on abstracting that pipeline. This is harder that our case because it involves gameplay, so there were some naiveté from their part but I can see how from an abstract perspective it can be understimated.
lost_name 11y ago
For what it's worth, I'm not sure that line communicates the change correctly. Judging from the kickstarter video and the Steam store page, it looks like it was always a 2D game in a 3D world (glorious 2.5D).
wpietri 11y ago
> how could you not know that this would have a major impact? Anybody starting a major project will be ignorant about some important things. It's impossible to do anything interesting and know everything up front; if you could know everything, then that would mean it had been done a zillion times before and therefore not be interesting. There's also a strong selection bias. The kinds of people who don't take chances? They don't become entrepreneurs. They don't bet years of their lives on projects in hit-driven industries. Those who do take chances already know that so many of the things that previously seemed impossible or dangerous to them worked out to be fine. So nobody should ever, ever, ever not start something because they don't know everything. The trick to successful entrepreneurship is to test your big risks early, so that your failures are small and recoverable, rather than late and fatal. Here their mistake wasn't underestimating the impact of 3D. It was in not testing their assumption before the public launch of the Kickstarter.
- RogerL 11y ago
  All you have to do is look at the budget, schedule, and people count of any game ever. This is not secret information (big picture numbers, anyway). Okay, so maybe EA is non-optimal due to corporate hoo haa, and a lean team can do more. That doesn't begin to account for a budget of 50K replacing a 100+ person, 1+ year death march effort.
  - shawn-furyan 11y ago
    I get the sense that the author considered AAA games to be largely overwrought and needlessly complicated, which for his purposes was probably true. I suspect that the team mistook "can be simpler" for "can be simple". In that light, I think the error in judgement is understandable. Humans have multitudinous ways of tricking themselves into believing the things they would like to believe.
    - rebekah-aimee 11y ago
      One has to be very careful about conclusions based on the assumption of someone else's ignorance. There are a lot of people who spend lots of money doing something in a stupid way (look at big software companies), but even they have an underlying reason: it's difficult to pick good programmers and value them accordingly unless all your managers are also programmers (and who picked them?). When you say, "The normal approach to X is stupid; we're going to do things differently," you have to understand how the normal approach came about so that you can avoid ending up there yourself regardless, and also so that you can avoid whatever problems it adapted to avoid. There are situations when assuming by default that other people are reasonably intelligent is a bad or dangerous idea--while driving, for instance, or during basically anything involving casinos or Black Friday. But when a market governs a motivation as powerful as money and is sufficiently discerning, you'd better start really questioning whether those people are actually stupid or you just don't understand what they're doing.
grok2 11y ago
One thing I've learned over the years is that sometimes people who succeed are sort of ignorant about the scale of the problem they are trying to solve -- they succeed over tremendous odds. It's not correct to think everyone sees things rationally every time and should've seen the obvious.
kraig911 11y ago
This is common in any project. Optimism is like a 9 year old boy at a cake/pie buffet. You should expect there to be vomit.
dragontamer 11y ago
They didn't go full 3D. They went 2.5D, akin to "Streets of Rage" or "Maximum Carnage". There might have been a problem with expectations. 2D Games sell level design and platforming. 2.5D games however are often done with excellent combat. No one complains that Super Mario 3 has horrible combat. Of course not, its a 2D Platformer. By changing from 2D to 2.5D, everything about the game changed. From customer expectations, to platforming, to collision detection. 2D to 2.5D looks like a simple switch. It's not full 3D and it is a natural extension to 2D games. But really, so much changes that it was definitely a mistake for them to attempt to make that switch mid-development.
Scuds 11y ago
"But changing gameplay from 2D to 3D had a major impact on overall development cost (we found out a little too late)" You and every other developer making the transition from SNES to PS1 in the mid 90's.
- deaddodo 11y ago
  The irony here is that the publishers/developers working on Sega platforms DID understand 3D development, thanks to Sega's arcade business. They just weren't given the hardware to do so...
deaddodo 11y ago
I don't understand the use of 3D in 2D/2.5D platformers, as it is. Just use vector art. It's cheaper, looks better and is simpler to code for.

valarauca1 11y ago

>Passion and commitment are not a substitue for experience The author explained more or less. Inexperience.

jeremiep 11y ago
I say the exact same thing about Agile practices, "methodologies and procedures are not a substitute for knowledge and experience." That message is a LOT harder to get through than it seems.
- karlkatzke 11y ago
  Digressing a little from the central topic -- Yeah, it's actually amazing how hard that message is to get through. And you even see a dichotomy where the HR side of a company will understand that and will go out of it's way to hire experienced people and retain them, but Product/Project Managers will completely discount them to the point of driving experienced people out of a business when the knowledge and experience says "Build it X way or you're in a world of hurt a year from now. I lived that once and I don't want to live it again." Or, put another way, "Security is not a feature the business needs at this time in this PII-heavy project."
- Cthulhu_ 11y ago
  OTOH, if they embraced the agile methodology, they could've said "We do not know how long it will take, it depends on our velocity which we haven't yet established". $72K for a team of 6-10 developing an AAA-level game is just unrealistic.
  - jeremiep 11y ago
    I really don't like velocity as a metric. It's about as useful as counting lines of code to judge a project's completion. I don't think I could explain it as well as Dave Thomas says it, so here's a link to his fantastic keynote: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M
    - mikekchar 11y ago
      Unfortunately the link is a little longer than I have time to view today, but I will put it on my to-watch list ;-) As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process. The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes. However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem). In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes. That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on). Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.

bluedino 11y ago

Bit off more than they could chew? Didn't have an extensive background in game building? Perhaps they just never built a 3D game before? It's kind of like when some of the first 3D games came out, modelers would model a brick then build a wall out of them, instead of just modeling a brick wall other ways, like putting a brick texture on a regular wall. They probably just couldn't come up with a good way to 'cheat' 3D collision detection that worked for them. Approximating is a huge part of game algorithms even with the power of today's hardware.

tinco 11y ago
Because from a distance it actually doesn't seem like so much work. The assets get crazy expensive, but they already had that covered. 3D collision detection and resolving is a solved problem, you can just get off the shelf components (for free), the real problem isn't gettin the game to work, the problem is in the polish. Jumping over fences, AIs chasing over 3d terrains, making sure people don't get stuck in random stuff. Everything needs weird edge-case stuff that's not in a generic physics engine. Perhaps they should've first made a 3d game with 2d physics, those games look great and the overhead is much more manageable. But hindsight is 20/20 and from what I've gathered they actually got really close to a great game.
- pmelendez 11y ago
  > the real problem isn't gettin the game to work, the problem is in the polish Exactly this... Pareto principle (applied to time) is really relevant in this case.
a-nikolaev 11y ago
Agreed, game development is the art of making illusions. Proper simulation, or any kind of complex machinery working behind the scene rarely adds a lot of value to the resulting game (sadly). And moreover, I'm certain that relying of cheap tricks is the greatest virtue in game development. And there is nothing derogative or ignoble about that. Knowing where to cut corners is an extremely valuable skill, and it requires a lot of intelligence, experience, and careful planning. Computer games are a lot like real-life magic. The best results are achieved if you do cheap tricks, but you do them well..

gdulli 11y ago

Seems like an inevitable side effect of making fundraising an impulse buy that circumvents due diligence. Not that it's inevitable to happen every time, or that crowdfunding can't succeed, just that the odds of a really basic sort of failure that could have been surfaced early on are a lot higher.

pmelendez 11y ago

I worked once for a (non-Indie) game studio and HQ asked us to change our engine from 2D to 3D to accommodate some 3D art(in the middle of production). It implied a lot of work but the studio had the means to put some very experience people focused just on abstracting that pipeline. This is harder that our case because it involves gameplay, so there were some naiveté from their part but I can see how from an abstract perspective it can be understimated.

lost_name 11y ago

For what it's worth, I'm not sure that line communicates the change correctly. Judging from the kickstarter video and the Steam store page, it looks like it was always a 2D game in a 3D world (glorious 2.5D).

wpietri 11y ago

> how could you not know that this would have a major impact? Anybody starting a major project will be ignorant about some important things. It's impossible to do anything interesting and know everything up front; if you could know everything, then that would mean it had been done a zillion times before and therefore not be interesting. There's also a strong selection bias. The kinds of people who don't take chances? They don't become entrepreneurs. They don't bet years of their lives on projects in hit-driven industries. Those who do take chances already know that so many of the things that previously seemed impossible or dangerous to them worked out to be fine. So nobody should ever, ever, ever not start something because they don't know everything. The trick to successful entrepreneurship is to test your big risks early, so that your failures are small and recoverable, rather than late and fatal. Here their mistake wasn't underestimating the impact of 3D. It was in not testing their assumption before the public launch of the Kickstarter.

RogerL 11y ago
All you have to do is look at the budget, schedule, and people count of any game ever. This is not secret information (big picture numbers, anyway). Okay, so maybe EA is non-optimal due to corporate hoo haa, and a lean team can do more. That doesn't begin to account for a budget of 50K replacing a 100+ person, 1+ year death march effort.
- shawn-furyan 11y ago
  I get the sense that the author considered AAA games to be largely overwrought and needlessly complicated, which for his purposes was probably true. I suspect that the team mistook "can be simpler" for "can be simple". In that light, I think the error in judgement is understandable. Humans have multitudinous ways of tricking themselves into believing the things they would like to believe.
  - rebekah-aimee 11y ago
    One has to be very careful about conclusions based on the assumption of someone else's ignorance. There are a lot of people who spend lots of money doing something in a stupid way (look at big software companies), but even they have an underlying reason: it's difficult to pick good programmers and value them accordingly unless all your managers are also programmers (and who picked them?). When you say, "The normal approach to X is stupid; we're going to do things differently," you have to understand how the normal approach came about so that you can avoid ending up there yourself regardless, and also so that you can avoid whatever problems it adapted to avoid. There are situations when assuming by default that other people are reasonably intelligent is a bad or dangerous idea--while driving, for instance, or during basically anything involving casinos or Black Friday. But when a market governs a motivation as powerful as money and is sufficiently discerning, you'd better start really questioning whether those people are actually stupid or you just don't understand what they're doing.

grok2 11y ago

One thing I've learned over the years is that sometimes people who succeed are sort of ignorant about the scale of the problem they are trying to solve -- they succeed over tremendous odds. It's not correct to think everyone sees things rationally every time and should've seen the obvious.

kraig911 11y ago

This is common in any project. Optimism is like a 9 year old boy at a cake/pie buffet. You should expect there to be vomit.

dragontamer 11y ago

They didn't go full 3D. They went 2.5D, akin to "Streets of Rage" or "Maximum Carnage". There might have been a problem with expectations. 2D Games sell level design and platforming. 2.5D games however are often done with excellent combat. No one complains that Super Mario 3 has horrible combat. Of course not, its a 2D Platformer. By changing from 2D to 2.5D, everything about the game changed. From customer expectations, to platforming, to collision detection. 2D to 2.5D looks like a simple switch. It's not full 3D and it is a natural extension to 2D games. But really, so much changes that it was definitely a mistake for them to attempt to make that switch mid-development.

Scuds 11y ago

"But changing gameplay from 2D to 3D had a major impact on overall development cost (we found out a little too late)" You and every other developer making the transition from SNES to PS1 in the mid 90's.

deaddodo 11y ago
The irony here is that the publishers/developers working on Sega platforms DID understand 3D development, thanks to Sega's arcade business. They just weren't given the hardware to do so...

deaddodo 11y ago

I don't understand the use of 3D in 2D/2.5D platformers, as it is. Just use vector art. It's cheaper, looks better and is simpler to code for.