copperbadge:

memprime:

beesmygod:

greenapparatus:

highlandvalley:

A museum in Japan spends most of its day refusing entry to 2 cats trying to get in
@bijutsu1
https://twitter.com/jiffington/status/1062471505496469504/video/1

LET THEM IN

WAIT THIS IS THAT MUSEUM THAT MAKES THE INCREDIBLE TOTE BAGS BC OF THESE CATS

@copperbadge found a tote bag for you…

Oh man I want it on a poster!

My favorite part is the little caption. Just to make it clear what’s going on. 😀

The challenging decisions of game development, or how good people can end up making bad games

danlowe-blog:

The following scenario is a work of fiction and not based on any specific game I’ve worked on, or any specific experience I’ve had.


You’re sat in a meeting room with a bunch of other game developers; key representatives from every department that might be affected by animation. There are people from the design team, the engine team, gameplay programmers, AI programmers, the tools team, technical animators, animation programming, the animation director, and a producer. The meeting is about the future of your animation technology.

It’s relatively early in your project; the third game in a successful series, and the animation department wants to do a major upgrade to the core animation technology. Their argument is simple: The animation team has been using the same tools and tech for the last two games, and they’re concerned that if the animation technology isn’t improved, the animation will start to look bad compared to your competitors. There have been some minor improvements since the first game in the series, but no real major steps forward. Since the original tech was created, the rest of the industry has made some pretty major breakthroughs in animation technology; breakthroughs that this team would like to try and implement.

The big problem: The new technology is a paradigm shift. There’s no easy way to convert all the old animations and game code over to the new system, so doing this big upgrade to the animation tech, means pushing the reset button on all the gameplay and AI systems that were built for the last two games. Everything will have to be built up again from scratch.

It’s your job to decide whether or not they should do it.

The producer is the first to chime in…

“How long do you think it’s going to take to get the gameplay and AI back into a state where we can start playtesting and building levels?”

“I’m pretty confident that in 6 months we’ll be good to go”, says the animation programmer.

“Well… 6 months to do the tech and tools… it’ll be maybe another 6 months on top of that to rebuild each of the game systems to get things back to where they were”, offers up one of the technical animators. “I still think it’s worth it though. Once we have the new tech, it’s going to make producing new features way faster than before.”

“You have to bear in mind”,

says the Animation Director, “What we did on the last game is pretty much hitting the ceiling of our current technology. It was a real strain on the team. I really don’t want to go through that again on this one.”

“I’ll be honest, I have some concerns”.

Everyone looks towards the lead engine programmer.

“I thought the whole point of this next game was to try and push the cooperative experience. That’s what the directors said was their number one priority”, he nods towards the game director, “And I thought the publisher had already signed off on that. Weren’t they saying that’s what they were most excited about?”

“We can’t do both?”, says the game director.

“We’re probably going to have to rework a whole lot of the systems anyway if we’re going to make them replicate properly over the network,” says the lead gameplay programmer. “The first two games weren’t really built with that in mind. It could be a good time to do this as well since we’ll be rewriting a bunch of the systems anyway. That said, it does add to our workload.”

“And for you guys?”, the producer asks the lead AI programmer.

“It’s pretty much the same situation as gameplay”, she replies, “It’s a lot to take on. I have to say, I think 12 months is optimistic. Things always come up that we don’t expect. I’d say closer to 18 months. I mean… remind me, when are we supposed to be shipping again?”

“We’re aiming for 2 years from now”, says the producer.

“Well if it ends up being 18 months, there’s no way my team can work with that”, adds the lead level designer. “We can rough some things out, but gameplay needs to be solidified a lot earlier than that.”

“Well we could build the new system in parallel with the old system, and let people switch between the two”, says the animation programmer. “That way you can start building levels with the old systems, and we’ll switch it over further down the line when the new systems are in a better shape. It’s a bit more challenging to do it that way, but it’s doable. Honestly though, when I say 6 months for my stuff, I mean 6 months. I can get most of it up and running in 3, but I’m saying 6 to give us a buffer.”

“And how confident are you about the extra 6 months for building out the game systems”, the producer asks the technical animator.

“Reasonably… I mean it’s tough to say… it’s new technology. I’ve got nothing to refer to cause we’ve never done this approach before”, they reply, “6 months is my ballpark estimate, it could be 4, it could be 12. We’ll have a much better idea once the core tech is done and we start working on the first systems. Bear in mind, it’s not like we’d have nothing until that 12 months is up. Systems will be gradually coming online as we go. We’ll get core movement done in the first few weeks.”

“I’d feel much more confident about it if we had another technical animator on the team”, says the animation director.

“I’ll ask if that’s possible but we’re close to our headcount limit, and tech animators aren’t the easiest to hire, so I wouldn’t count on it”, says the producer. “Remind me again, what we’ll be gaining for all this work?”

“It’ll be much faster for us to put animations into the game, and then easier for us to tweak and bug fix them”, says the technical animator. “In general, faster iteration time should also mean the quality of the animation will go up. Basically, it’ll be easier for everyone to do their best work.”

“I think we all want that, but it’s a lot of risk to take on with only a 2 year timeline”, says the lead engine programmer, “there are other teams besides animation who are also proposing some pretty ambitious tech goals as well. We’d maybe have to make some concessions there if we want to go with this”.

“Does anyone really think that it’s going to be 2 years though?” says the animation programmer. “Looking at the scope of this game, it’s probably going to end up closer to 3, with or without the animation system”.

“I can only tell you what I’m being told now, but the publisher seems pretty adamant about it being a 2 year project”, says the producer.

“So what are we going to do about this? Are we going to push ahead with this or not? What’s the call?”


This is what game development is like.

Should the team go with the new animation system? Everyone makes good points. It’s a tough call. You have to think about the people in the room: How confident are you in the projections of each person? Are some people known for being overly ambitious? Are others known for being too conservative? How much is the value of the new animation system versus the cost of building it? How many extra-people will you be able to get to work on it? Will other departments suffer if you put development effort here? Will the game really come out in two years, or is it more?

In one potential future, you decide to go ahead with the new animation system. Things are rocky at the beginning, but with some hard work and late nights, the animation programmer and technical animators manage to hit their estimates without too much disruption to other teams. The game scores highly, and is praised in particular for it’s strong animation.

In another potential future, you go ahead with the new animation system and it’s a train wreck. The animation programmer was low-balling their estimates because they were excited about working on the new system, and expected the release date to be knocked back a year (it wasn’t). The technical animators were genuine when they gave their estimates but didn’t account for the complexity of making the same systems work in an online cooperative game; something they’d never done before. The difficulties with the animation system caused problems for other teams, especially for the designers, who had a tough time making fun systems and levels, as bugs in the animation system made it difficult for them to play the game throughout development.

Another potential future has the team saying no to the new animation system. It ends up that even without the new animation system, the scope really was too big in other areas, and the game ends up being released after 3 years instead of 2. By the time the game is released, the animation does look horribly outdated, despite the best efforts of the animation team. The issue is specifically called out in reviews.

Then there’s the future where the team says no to the new system, making it much easier for the team to hit the 2 year deadline. It’s a struggle, but the animation team is still able to produce some decent results, and it turns out gamers were more interested in the new cooperative features anyway, leading to great reviews and great sales.

On any game there are a thousand calls like this. Some are big, some are small, and many can lead to the success or failure of your game.

The process of making a game has so many moving parts it’s incredibly difficult to account for every eventuality. It’s about the technology you’re working with, it’s about your ideas and your ability to execute on them, it’s about what the rest of the market is doing, and most of all it’s about the people on your team: Who they are, how they work, and what else might be going on in their lives.

The point here, and stop me if you’ve heard this one before, is that making games is really fucking hard. You’re faced with so many of these kinds of decisions, the answers to which are highly subjective. It’s likely not every person in the meeting room comes to a consensus, and when a game comes out with some aspect that players don’t enjoy, more often than not there were a whole lot of people on the dev team that argued for the exact same thing that the players are arguing for.

It’s been said many a time before, but it’s true nonetheless: No-one sets out to make a bad game. In the cases where someone on your team was faced with one of these difficult subjective decisions, and made a bad call, they agonize over it. If you have empathy, you look at that decision and say, “That’s not necessarily a bad developer. It was a tough call. It could have gone either way, and it could have just as easily have been me”.

Of course, this doesn’t mean that gamers shouldn’t still be free to critique the games they spent their hard-earned money on. At the end of the day, it’s our job to entertain. Just please, remember that games are made by real people who are running a gauntlet of very challenging problems. 

The answer to “why did this game suck?” isn’t always as simple as “because the developer sucks”, or the even more cringe-worthy “they were just lazy”: It’s because making games is really fucking hard.