41–50 of 59 posts
Earlier quoted context omitted.
This advice is super generic.
No more generic than "Make something people want" or "Listen to your users." And yet most companies get these wrong, just like most game companies fail to playtest their ideas.
Earlier quoted context omitted.
apparently they aren't though. People porting from PC to other platforms are still finding huge perf issues and have to refactor tons of code. I thought this gen (PS4/XboxOne) were going to be easy ports but from every team I've talked to they aren't
A lot of the criticisms I've seen for failed ports describe the exact type of behavior you would expect from an emulated system. The ports you reference behave like game systems that used to occupy 100% or almost 100% of the resource capacity of a dedicated system failing to execute correctly when they're running in a non-dedicated environment. They also had the advantage of targeting an exact set of hardware specifi…
"To avoid schedule slippage, game developers need to spend more time to plan out all the work that needs to be done so that no tasks are overlooked when giving estimates. By planning out tasks, you can also estimate each task individually, and give a more accurate prediction, instead of an optimistic one." When things don't work out according to the schedule, there are generally two reactions : 1. We didn't estimate…
I think you're talking about "first year of work" levels of experience. Estimation is hard - but a major goal of Agile development is to make it possible. I thought the same thing as you, but a month ago someone explained it to me in a way that makes a lot of sense https://news.ycombinator.com/item?id=11641316 Actually a lot of the comments about this PDF can be summed up with "practice Agile development"
Earlier quoted context omitted.
The Warcraft 3 engine was flexible enough to implement Dota, just like the Unity engine was flexible enough to implement Rust. By your criteria, Rust is a mod, even though it's clearly not. It's better to say that mods are games and to treat them the same than to try to differentiate them. The same design process that yields a successful mod will yield a successful game.
Rust is not a mod, but is a clone of a mod of Arma2 called DayZ.
But the second half is completely false. Rust has nothing whatsoever to do with DayZ, except that it's vaguely in the same genre.
Earlier quoted context omitted.
No more generic than "Make something people want" or "Listen to your users." And yet most companies get these wrong, just like most game companies fail to playtest their ideas.
Why do you say "and yet" - since such generic "advice" is useless so is the conclusion " and yet they get it wrong!" (I told you something useless - why doesn't it help?)
Playtesting isn't useless. It's how fun games are made.
Perhaps people are disagreeing with this because they haven't tried to make a game. A curious phenomenon.
"To avoid schedule slippage, game developers need to spend more time to plan out all the work that needs to be done so that no tasks are overlooked when giving estimates. By planning out tasks, you can also estimate each task individually, and give a more accurate prediction, instead of an optimistic one." When things don't work out according to the schedule, there are generally two reactions : 1. We didn't estimate…
I think you're talking about "first year of work" levels of experience. Estimation is hard - but a major goal of Agile development is to make it possible. I thought the same thing as you, but a month ago someone explained it to me in a way that makes a lot of sense https://news.ycombinator.com/item?id=11641316 Actually a lot of the comments about this PDF can be summed up with "practice Agile development"
Isn't agile the #2 option quoted above? Agile in game development means being able to estimate how long it'll take to add fire damage to a weapon. It's not a means of being able to budget out 3 years worth of development, let alone hit a shipping date that far out.
Earlier quoted context omitted.
How does that possibly solve the problem being discussed here? Are you the god who can define ALL tasks (in the agile meaning, a sprint consisting of a number of tasks) that a large project consists of up front, all the way to the end of the project 3 years later (for example)? Agile delivers because it doesn't attempt the impossible.
The problem seems to be that although companies want to pretend that they are all agile, the business and planning side really is not, because resources are not unlimited. So if you can't (even if admitting that it's faulty) put a number on time and effort, someone else higher up the ladder will do, and then it will hurt you. I think that toolchains should have better support for estimated vs used time and then learn…
Of course budgets and deadlines has to be set. Agile is not a way to ban those, it's a way to allow them, even if forecasting is impossible. It's about saying, well at that date I can promise to have kept under budget, and will have something that more or less reaches the goal of the budget. It will not, however, be what anyone is imagining right now, let's have fun discovering what it'll be.
> When looking at games developed for one platform versus games developed for multiple platforms, we found a few advantages and disadvantages to choosing one over the other. First, 46% of developers that used multiple platforms listed art as something that went right, while only 33% of developers that used a single platform listed this. Additionally, 15% of the developers that used a single platform listed this as so…
Some games have targeted consoles, created a bunch of console-resolution textures and other art, then ported to PC and been slated for the low-resolution textures and art. Or at least, that was the case last time I read the gaming press about 10 years ago. I don't know if it's still an issue these days.
Only now consoles seem to be speeding up, possibly because of increasing competition like Steam Machines.
Another problem were interfaces. Too many developers cut corners and didn't develop separate interfaces for controllers and keyboard & mouse. This resulted in very bad UIs.
Earlier quoted context omitted.
Why do you say "and yet" - since such generic "advice" is useless so is the conclusion " and yet they get it wrong!" (I told you something useless - why doesn't it help?)
Because if you follow this advice, you're more likely to yield a successful product. Playtesting isn't useless. It's how fun games are made. Perhaps people are disagreeing with this because they haven't tried to make a game. A curious phenomenon.
Funny sidenote: the paper mentions a game titled Age of Ornithology under 5.1.g (Scope). Naturally I got excited at the idea of a game where you play some kind of bird collector, or an intrepid late 19th-century magnifying-glass-and-butterfly-net explorer and cataloguer of birds. But unfortunately this title is some kind of cruel joke: http://www.phobe.com/sfi/ornithology.html http://www.gamasutra.com/view/feature/13…