"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?
Not to pile on, but this was very surprising to me... 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.
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.
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.
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.
Exactly this... Pareto principle (applied to time) is really relevant in this case.
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..
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.
The author explained more or less. Inexperience.
That message is a LOT harder to get through than it seems.
Or, put another way, "Security is not a feature the business needs at this time in this PII-heavy project."
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
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.
What I don't like about velocity is that it encourages the gamification of the process. Developers start caring more about their velocity than the quality of their code and before long nobody has any clue of the big picture and the project starts going down the drain.
Working in the video game industry, I see the striking difference between playing games and developing games first hand, every day :)
You and every other developer making the transition from SNES to PS1 in the mid 90's.
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.