twitterlonger

anonymous asked:

Any advice for indie devs looking to network a team to; get that two years of experience and a shipped game that most AAA companies require now?

Go to a game jam and practice working with a team and a tight schedule. Seriously, find one nearby and go do it. It’s that kind of environment that novice developers need to place themselves in because it’s similar to how professional development works. You have a set schedule to deliver something, you have to divide the workload up among people with different skillsets, you need to scope based on available resources, and you need to be sure of the team’s goal. These are the sorts of skills that hiring managers also look for in our candidates.

Don’t look at the “two years experience and one shipped game” as an absolute requirement. The reason that this exists is that most studios want candidates who have had to deal with the issues that often come up during development, because those same issues will probably come up again. They want to know that the candidate had to make decisions regarding gameplay in the past with regards to factors like technical limitations, scheduling, assets, and other requirements. They want to get meaningful answers when they ask about the stuff the candidate’s worked on and why decisions about the implementation were made. Most importantly, they want to know that the candidate can finish something they’ve started.

If you want your resume to get a second glance from recruiters, you need to show them that you can do the work. You can try wrangling a group of devs or doing things completely on your own, but you need to set a schedule, create a design document, and deliver the goods as best you can according to the schedule you set for yourself. You need to demonstrate that you have the qualities hiring managers are looking for - that you can make tough decisions, that you can choose efficient means of implementing features, that you’ve thought things through and can defend the choices you’ve made, and that you can finish what you start. Game jams are a great place to do this on a small scale, and you can build on the connections you make there to handle a larger scope project. 

Here are some links to places you can find game jams:


Got a burning question you want answered?

anonymous asked:

What's your take on the whole Mass Effect Andromeda animation debacle?

I’m back, I’m jet lagged, and people are being stupid on the internet. Whee.

Off the top of my head, here are a few thoughts on the matter:

#1. It is never ever EVER ok to harass somebody personally

This whole thing about a bunch of people harassing that former EA employee is horrible and should never have happened. It is never ok to go after somebody personally for what they may or may not have done in a professional capacity. There is no justification for it. Ever. If there’s a problem with the product, everybody shoulders the blame - that includes the publisher, dev team, marketing team, everybody. Even if there was one person who worked on one feature completely solo, that person still had a boss, who had a boss, who had a boss. There are so many people involved and so many moving parts that you really can’t blame any one person except the executive producer in charge of the entire project. The person in question is most assuredly not that executive producer.

#2. People comparing ME:A to the Witcher 3 are oversimplifying

There’s a meme floating around about how the Witcher 3 was created by a couple of Slavs as if it was done by a couple of dudes in a garage somewhere, compared to ME:A, which had a huge team from EA. That’s incredibly shortsighted and utterly ridiculous. The Witcher 3 cost over $80 million to develop, which is probably a bigger budget than ME:A had. CDPR had an internal team of 240 full-time professional devs and another 1200+ contractors working on it. The Witcher 3 is “indie” in the way that Star Citizen is “indie” - they didn’t work with a separate billion-dollar publisher because they had enough money to fund the project already. 

#3. From what I’ve seen, Mass Effect Andromeda has animation issues in general

From the cursory footage I’ve seen (I haven’t played the game yet since I’ve been out of the country), it looks like there’s a bunch of problems, most of which aren’t related to the facial animations at all. The characters have that weird slightly hunched-over broad-elbowed walk similar to how they walked in Dragon Age: Inquisition, and there’s something about how the elbows don’t quite sit right to me while the characters are idling. I also spotted a character in a T-pose in one clip which was a rather clear bug. The facial animation probably stands out most because players spend a lot of time in cinematic conversations, and that features the faces quite prominently. 

#4. Bioware is certainly aware of the issues

From what I’ve heard, there were team members who raised the warning flags internally as well, but the decision was ultimately above their pay grades. It’s really hard to say why they decided what they did without knowing the full context, and that isn’t likely to happen. The scope of the new Mass Effect game is different than before - this is the first game of the series on Frostbite, with a new lead studio helming development (Bioware Montreal), and with new team leadership (after the departure of Casey Hudson, Mass Effect’s former executive producer). There’s a lot of moving parts where things could have broken down during development, and we’ll likely never know. They’ll never share that information publicly… nor should they. Bioware the studio shoulders the blame for it, just like Bioware the studio owns any praise they get. 

Animation issues are often some of the hardest and most expensive problems to fix. Building animation rigs (skeletons) takes a lot of resources. Utilizing those rigs to build animations takes a lot of resources, even when you’re using motion capture data. Building animation systems to blend, layer and play those animations under the correct circumstances take a lot of time. Animation is one of the most expensive types of content to create - that’s why so many games reuse so much of their animation data. That said, Bioware also developed and released the extended ending to the last Mass Effect game for free in response to the fan backlash about the ending, so who knows? 


Got a burning question you want answered?

anonymous asked:

Do you watch any game analysts/reviewers/critics/game dev channels on YouTube? Any of them you particularly like or dislike?

There are a few youtube channels I do watch regularly, but I tend to bypass analysts, critics, or reviewers. I don’t really find that sort of content to be particularly useful to me, as I tend to look at games differently than most of them and would usually rather form my own opinion based on footage of the gameplay without their commentary. Stuff I tend to watch tends to be stuff that deals with development on some level, rather than finished products. Here are some of the channels I tend to watch:

  • [Extra Credits] - Most of you probably know what this is. Some of you probably found this blog through their kind mention of me. 
  • [3Blue1Brown] - A great place for understanding complex mathematical concepts visually
  • [GDC] - The youtube GDC video vault, where they post talks given at previous conferences.
  • [Kristjan Zadziuk] - An industry animation director that has some great videos on motion capture and advice on animation reels

There really isn’t a lot I dislike, because that requires a greater emotional commitment than I’m willing to give. I don’t necessarily dislike Total Biscuit, Angry Joe, Jim Sterling, Yahtzee, or whoever else, but that’s because I only give them attention commensurate with how much I care about their commentary: very little.


Got a burning question you want answered?

anonymous asked:

I know you're fielding a ton of "how do I become game" questions, I have some that are very specific. I code for work in C#, PHP and web stuff. I know my way around C++ but I'm not prepared enough to start applying for game gigs. My questions are: 1. Is there a good self service way to indicate what my current skill level is, comparatively against current industry standards? What is "ready"? 2. The best resources and ways to expand my C++/programming knowledge in a constructive way

I always appreciate specific questions. It’s a lot easier to give more specific and useful answers than hand-waving generalizations that are read and forgotten.

1. Is there a good self service way to check my current skill level?

Yes. I suggest trying programming challenge websites like [topcoder.com], [codility.com] and [codewars.com]. Make sure that you’re using C++ as the language of choice. Many of these sites also have lessons geared towards teaching you the concepts you’ll need to know. Do as many challenges as you can, and try to improve in the ways the automated code checkers suggest. There’s a large variety of tasks at each site that you can try tackling, with varying levels of difficulty. I suggest starting with the fundamentals as a refresher and working your way up.

2. Best resources and ways to expand your C++/Programming knowledge

In addition to practicing with coding challenges, I would suggest picking up [Unreal Engine] (which primarily runs with C++ instead of Unity’s C#) and using it to put together smaller projects with a clear set of requirements that you can accomplish. Once you have a clear goal within a scope you’re sure you can reach, you can actually do the tasks and make sure that you can complete them. Once you’ve gotten the correctness part down, you can try submitting your solutions to sites like [Stack Exchange’s code review section] and asking for feedback on the stuff you’ve written.

Remember, the general rules of completing a code task are:

  1. Make it work (It should do what you want)
  2. Make it right (It should handle edge cases gracefully)
  3. Make it fast (It should do what you want quickly)
  4. Make it pretty (Other engineers should not have any trouble understanding your code if you hand it off to them)

Start small and work your way up to bigger tasks as you go.


Got a burning question you want answered?

anonymous asked:

Is there a situation where input lag is purposely added to a game? Theres ongoing debate in the fgc about sfv having 6.2 frames of lag on purpose due to online play, and how it relates to how they use their cfn to allow crossplatform play between pc and ps4.

Yes, that’s actually pretty normal. If you want online play, you need some amount of input lag to serve as a buffer so that both players will get the same results at the same time. The amount of lag will vary depending on the game, but it’s pretty normal to have some amount of input lag to provide a buffer in order to allow for fair gameplay. Let me show you what I mean. Normally, when Ryu presses the roundhouse button, the signal from Ryu’s controller goes in, gets processed by the machine, then the move starts. In a lagless environment, this is a timeline example of what would happen:

However, when Ryu is fighting Ken online, there’s not one single timeline, but actually three separate timelines - one for what Ryu sees, one for what the server sees, and one for what Ken sees. The difference is that these are not synchronous by any means, because it takes time for Ryu’s game to tell the server that he pressed the roundhouse button, and then it takes time for the server to tell Ken that Ryu pressed the roundhouse button. So it actually looks something like this:

If it takes 50 milliseconds (3 frames) to transmit data from Ryu to the server, and another 50 milliseconds to transmit data from the server to Ken, then Ken won’t register Ryu’s roundhouse button press until 6 frames after Ryu pushed the button. Ryu likewise would also not see Ken’s moves until 6 frames later. Obviously, this isn’t so good. 

Imagine this scenario. Ryu and Ken are right next to each other. At frame 0, Ryu presses roundhouse (startup time: 5 frames). This means that Ryu’s roundhouse will hit on frame 5. At frame 1, Ken presses jab (startup time: 3 frames), hitting on frame 4. In a lagless environment, Ken’s jab would hit before Ryu’s roundhouse on frame 4. But what if this were online with 3 frames of latency between each player and the server? 

If this happens online, Ryu’s roundhouse button press signal wouldn’t reach Ken until frame 6 (pressed on frame 0 + 3 frames of signal travel time from Ryu to server + 3 frames travel time from server to Ken). Ken’s jab signal wouldn’t reach Ryu until frame 7 (six frames of total signal travel time), and suddenly you have three different stories going on. Ryu believes his roundhouse (pressed on frame 0, hitting on frame 5) cleanly beats the jab that was pressed on frame 8. Ken thinks that his jab (pressed on frame 1, hitting on frame 4) cleanly beats Ryu’s roundhouse (pressed on frame 6, hitting on frame 11). The server receives Ryu’s roundhouse at frame 3 (0 + 3 frames travel time), Ken’s jab at frame 4 (1 + 3 frames travel time), and thinks that Ken’s jab actually stuffs Ryu out of his roundhouse at frame 7 (1 + 3 frames startup + 3 frames travel time). If the server is authoritative (as it should be), that means that it sends the signal to both Ryu and Ken that Ken’s jab beat Ryu’s roundhouse, which will then happen on frame 10 for both of them (server says it happens on frame 7, but it takes 3 frames of travel time for the signal to reach both of them). This is probably super annoying for Ryu, who pressed the roundhouse button 10 frames ago and still gets stuffed by the jab he didn’t get until 7 frames later, when the server decides that Ken’s jab won.

Now let’s assume that there’s an input delay of 8 frames. The same input timing happens - Ryu presses roundhouse on frame 0, Ken presses jab on frame 1. What changes? Because there’s the delay in the moves actually starting, all three parties now have enough time to synchronize the events before anyone expects the attacks to happen. This means all three will see the same events play out on the same frame numbers.

With an input delay of 8 frames, Ryu knows his roundhouse won’t register until frame 8, and won’t go active until frame 13. Ken knows his jab pressed at frame 1 won’t register until frame 9, and won’t go active until frame 12. The server has enough time to receive the input data from both fighters and then update them both with enough time to spare so that both Ryu and Ken will see the exact same thing happen on their screens exactly eight frames after they pressed the button. This input delay allows the server to keep them both in sync. The better the connection, the fewer frames of input delay there has to be in order to arrive at the same result. In this particular example, we could probably shorten it to 6 or 7 frames of input delay to maintain parity. If we could decrease the latency between Ryu and Ken, the input delay could be reduced further.

So yeah. That’s how online play works for almost all games played in real time. Synchronization is hard. Signals aren’t instantaneous; it takes a non-trivial amount of time to transmit data across vast distances. The only real way to handle that is by keeping enough of a time buffer. There are various (and similar) other ways of handling this; the famous GGPO method actually stores the last few frames of the game that have already passed, and retroactively inserts button inputs into the past and recalculates the game state in order to make the present synchronize up. This is what causes GGPO’s weird false positives, such as your game thinking you KOed somebody (and playing the sound effect for it), only to receive game data that retroactively undoes that event and keeps the fight going.

“But why not keep offline play without any input lag and just keep it for online play?” you might ask. They did that in past games. Unfortunately, this means that the online play is a fundamentally different experience than offline play. That’s not good if you want to foster an active global competitive community, because it means that anyone who can’t get local competition will be at a huge disadvantage. Keeping the experience consistent for everyone online and off will allow all players to practice and improve at the same game.


Got a burning question you want answered?

anonymous asked:

There has been a lot of hoola over facial animations in ME: Andromeda, even media outlets like IGN are getting in on the action. Yet, there has never been an issue with games like Fallout and Skyrim. I was hoping you could provide some insight into why Bioware gets castigated for things other developers get away with? Do people hate gay characters that much?

I think the anti-LGBT scapegoating is what you get when you have a lot of jerks who are frustrated at a legitimate issue take it out on something or someone they dislike, even if that thing is only tangentially related. Political views have practically nothing to do with the implementation of animation systems or content, but humans have a a nasty habit of using the flimsiest of justifications to act like jerks towards people they dislike.

Regarding the facial animation thing, the main reason that Bioware takes flak for it over Fallout and Skyrim is that conversations and cinematics aren’t as large a focus in Skyrim or Fallout. It’s an uncanny valley effect - because the conversations in the Bethesda games tend to be so robotic, we know what to expect and forgive them for not having high fidelity animations. Most of the fun of Skyrim and Fallout stems from the emergence of the player’s story, doing all sorts of crazy things out in the wilderness. Seeing the characters speak and act like marionettes doesn’t really bother us because we don’t really see them a potentially human so much as game entities with personality quirks. 

Mass Effect and Dragon Age spend a large amount of screen time showing people talking to each other, and humans are extremely good at noticing weird stuff like that. Furthermore, Bioware’s cinematic designers also do a lot of camera manipulation and add a lot of emphasis on what happens during these cinematics. Because we’ve all been trained since childhood to understand the language of cinema and pick up on facial cues when other humans speak, we’re primed to look for that stuff when we see the content presented in a similar way. And when it’s almost all there the subconscious priming backfires and it’s painful for us to watch. It just feels wrong and off, and that’s why we have such a bad reaction to it. Basically, Bioware sets us up to expect it and Bethesda doesn’t. When our brains want to see something and don’t get it, we feel the loss more than if we didn’t have any expectations at all. 


Got a burning question you want answered?

anonymous asked:

Are cheat codes no longer in games because people making games realized that they can charge people for what cheats used to do, or are cheats gone because of achievements?

Uh… neither. First off, nobody sells what cheats used to do. I have no idea where you got that idea, but I can’t think of a single game that sells “god mode”, “no clipping mode”, or “infinite ammo” DLC. Second, cheats aren’t gone because of achievements either. Cheats still exist because the reason for cheats still exist. Cheat codes exist in order for the developers to test their own stuff quickly and efficiently.

Imagine that you’re a gameplay programmer, and you’re working on the combat system. You’ve been tasked with adding support for critical hits to spells - fire spells will need to activate an additional burning damage over time effect after a critical hit, frost spells will freeze the enemy, lightning spells will arc to another nearby enemy, etc. Suppose that you write some initial code, and you think you’re ready to test it. It’s not reasonable to ask that you go through the entire class selection process or leveling up of your character just to get the spells needed to test your code changes. That would take a lot of time. So, instead, you use some cheat codes - a combination of console commands and internal debugging menus to set your character to an appropriate level, grant your character the appropriate spells, and probably add god mode so that you don’t run the risk of accidentally dying to the enemy while you’re testing - in order to set up your test scenario in a matter of seconds, rather than minutes or hours. You do this because you will need to be doing this many times before you are certain your code works. 

Besides you, all of the other engineers - graphics, gameplay, network, etc. will need to test their stuff. The designers will need to test their stuff. The sound guys need to test their stuff. The artists need to test their stuff. If you multiply the time savings across every developer that needs to make sure their stuff works in the game, you start seeing why cheat codes (or perhaps the actual name - debug commands) become necessary. They exist to debug issues and can save the collective equivalent of months or even years of development time. 

As for why debug commands aren’t always available in the finished product, it’s primarily because we now have better tools with which to develop games. Rather than building in a secret button combination, we just remotely connect to the development console and input commands from there. We just lock those codes off for the release version, and make it so that achievements won’t fire when debug commands are enabled. PC games almost always have ways to enable the developer console, granting access to the debug commands. Console games don’t because players usually lack the hardware necessary to remotely connect to the game with a PC. That’s really all there is to it.


Got a burning question you want answered?

anonymous asked:

Some time ago you talked about things that get you excited in games (like the dialogues in Uncharted 4). There are any upcoming game this year that are you looking for?

Persona 5 in two weeks, hands down, end of story. There are very few games I actively look forward to - the majority of games are usually more of a “Oh, that’s coming. I’ll probably get it” type acknowledgement than anything else. I know how much work goes into AAA game dev, and I enjoy my time with them, but they don’t really excite me much. I like playing them, and they’re interesting, but I don’t feel like I’m missing out if I wait a bit and pick it up later (or sometimes not at all, like how I never purchased a WiiU). My exception to this is the Persona series. I’ve been a huge fan since playing through Persona 3 on the PS2, and I love it from so many different angles. It is the one series I actually get excited about.

For those who are unfamiliar with this series, it’s an utterly bizarre combination of Pokemon-style battle and collection gameplay, Visual Novel Scheduled Dating Sim character and relationship building, and randomly-generated dungeon crawler all wrapped up in an urban fantasy JRPG setting, and it is wonderful. I didn’t think that such disparate core gameplay systems could work so well together, but they synergize like peanut butter and chocolate in a way that got me hooked from the get go.

The metaplot moves forward through day-to-day scheduled gameplay, where the player’s protagonist character meets and befriends characters in a Japanese high school setting over the course of a school year. Each character relationship is represented by a specific tarot arcana, and the strength of your friendship with that character also affects the strength of the pokemon you can collect and summon of that tarot arcana. The pokemon are necessary to battle the enemies in the randomly generated dungeons, which you must complete in order to advance the plot, which opens up access to more of the individual character storylines, which let your pokemon get stronger, which makes the dungeons easier, which lets you advance the plot… and so on. The relationships you build with your teammates translate into improvements in battle. The pokemon you collect also help build closer relationships with your friends. The money and items you collect in the random dungeons are used to buy better equipment, but also gifts for friends and toys and books for stat increases. It’s a fantastic multi-level synergistic feedback cycle that kept me playing for hours because of how many connection points there are between the different core gameplay systems. 

From a developer’s perspective, Persona 5 specifically has got me very interested in their presentation and user interface design. The game is highly visually stylized, and that extends to the UI as well. But it isn’t something particularly basic either - the fonts, the color scheme, the lettering are all highly stylized as well. Just thinking about how they managed to get the fonts to work with that kind of stylization must have been a huge design challenge… especially because they knew they had to localize it to a whole different writing system, while still maintaining the style of the game. I’ve done localization before - fitting stuff from other languages into limited text space is already a challenge, but doing so while adhering to this gorgeous visual style guide is a super daunting task. Are they only rotating or highlighting specific letters? Is there some kind of special preprocessing pass for the the text? Is everything drawn separately and simply treated as a texture? My mind is abuzz with possibilities.

As a player, I love great character development, story development, and deep RPG combat systems. As a developer, I really like seeing how different and deep gameplay systems interact and intersect with each other. The Persona series has managed to keep me fascinated as both a player and a developer for quite some time. Combine this with the totally addictive genre-bending fusion score by Shoji Meguro and I’ve got a game that I’ll easily sink 80+ hours into without blinking and still go back for more. Persona is the only game series I actively avoid spoilers and marketing for, because I know for certain that I will be buying it and I want to remain as unspoiled as possible. 


Got a burning question you want answered?

anonymous asked:

Do you have any advice on managing lots of branching paths in a choose your own adventure game? Even things like remembering what has happened (using tags) and making use of those is really cumbersome!

There’s a lot of things you can do here to help keep things straight. Primarily, you need to keep everything as organized as possible, and that means taking a big problem and breaking it down until it is in pieces small enough to handle. How I would start is by creating an outline for each individual storyline from beginning to end by breaking it up into a flow chart of story beats. Each beat should contain relevant information like:

  • A list of characters involved in the scene
  • The scene location and relevant environment details (What does this area look like?)
  • All branching conditions and where the branches lead
  • How this scene handles the different branches that lead to this scene
  • A brief description of what happens during this scene
  • Any sort of other requirements for this scene (props, character models, voiced lines, environments, animations, etc.)

Then, based on how the separate plot lines interact with each other, I would tag the branches with unique tags so that I can see where they intersect from scene to scene. If the flowchart of connecting scenes starts looking too complicated, it’s a good sign that the story could probably use some cutting or simplifying.

Let’s go with an example. We’ll create a quest that has a dialogue, a choice, two mutually exclusive scenes that result from the choice (an optional quest branch), and then some results. Here’s a sample quest summary:

The player character meets an archer named Neelo who wishes the player to recover her bow from a nearby cave. The player goes to the cave entrance only to discover another character, a shifty bard named Desmal, already at the cave entrance. Desmal offers the player a sackful of gold for the bow, but only if the player kills Neelo as well since she doesn’t want to deal with Neelo trying to take revenge.

So let’s build a quest outline for this, shall we?

Here is an example of a simple breakdown of the quest progression. You can see how scene progresses to scene, showing all of the different possible paths by which the player arrives at the next scene from its predecessor. You could (in theory) add notes to each of these scenes for the important information for those scenes, and dress them up visually however you like. As an example, I differentiated the action and dialogue scenes with the different shapes of bubbles, and used different colored arrows to indicate mandatory transitions as opposed to those driven by player choices. Notice how the quest converges after the player makes the choice to speak with Desmal or not and, if so, whether the player chooses to accept the subquest. Let’s continue with the second half of the quest.

Then we can finish the quest up through these scenes. Fighting Neelo is an optional part of the quest, but only if the player has accepted Desmal’s quest back up above. As you can see, there are two clear paths that the player can take to the end of the quest. If we wanted to do so, we could expand the quest to allow the player to keep the bow, attack Desmal, or any number of other things. We could track the results of the quest at the end and use those values in another quest later on. 

The benefits to breaking up story beats in this way should be pretty clear. Each scene, be it an action or a conversation or whatever, is essentially a single self-contained block that has a finite number of ways of entering, a finite set of results, and one major thing that happens inside it. While there’s no limit to the complexity one can pile into a single scene, resist the urge. Keep scenes simple and straightforward. Maintain the purpose of the scene, or it won’t have the right effect. I can then add all of the relevant details to that specific scene and know exactly what is needed to build this scene without needing to keep the entire storyline straight in my head. All I need to remember is what variables are important entering the scene, the scene details itself, and how the scene will determine where to direct the player next. Because it’s self-contained, I have a discrete chunk of work that I can do by myself or hand off to another designer. Once it is complete, I can connect it to the other completed scenes to form a whole quest. 

By keeping the storylines as self-contained flowcharts of interconnected scenes, I can easily determine each storyline’s relative complexity and size at a glance. The more the storyline looks like a spider web, the more complicated it becomes. Furthermore, with some practice breaking scenes down and creating them like this, I can also start estimating how long a specific scene will take to complete. This means that I can take a look at an entire storyline and estimate, based on the number of scenes in it, how long the entire storyline will take to craft. I can put in scene budgets for storylines to keep them sane - a large or critical storyline might have a top end of 25 scenes, while a one-off throwaway quest would have to be done in under 10. Since I can presumably tell what my schedule looks like, I can then make some decisions like “I can make this bigger” or “This won’t fit, I need to cut something”. I can then determine which parts that can safely be cut, and where I can reference smaller self-contained storylines into larger ones for more engagement without adding too much complexity. 


Got a burning question you want answered?

darklng0  asked:

How do developers get animations incredibly fluid? Like Platinum Games for example, in Nier Automata the animations can be breathtaking at times. Is it only motion capture or do they use that in tandem with something else? Like let's say that a character has centipede like tendrils protruding from his back and most of his moves involve flips and feints of the tendrils in tandem with hand to hand combat. How does that work?

Let me try to answer your question in a slightly roundabout way. Let’s talk about motion capture for a moment. A lot of gamers seem to think that, for video games, animators will hire actors to wear the motion capture suits, record some data, and then just plug that data into the game and everything is great. This is not how it works. Mocap is only the beginning, not the entire process.

If you’ve read my [Animation Primer], you know that animation data is generally represented as a sequence of specific positions over time. Each of these sets of positions is called a frame. The character is placed in these positions in order. The speed at which the character changes position to match the frame is called the frame rate. However, frame rate isn’t just used for playback. Computers run things in discrete time steps, after all, and computers capture motion data. When we record motion capture, we record it at a certain number of frames per second too. Most motion capture data is recorded at much higher frame rates than we expect games to display - typically around 120 to 160 frames per second. Just consider - if we have 120 to 160 frames per second of animation data, how do we choose which frames to display for the game that displays at 60 frames per second?

We could do it the basic way - just show every other frame we recorded. 120 fps becomes 60 fps this way, and everything is played back at the same speed it was captured. But that’s assuming that the data we motion captured is enough, and assuming that real life motion is what we’re after. If we’re talking about a game like Nier Automata, for example, where the main character is an android with greater capabilities than a human actor who’s goal isn’t to actually hurt anyone during motion capture settings, things change. So who decides what frames of animation get put into the actual final product? This is where the animator comes in.

A lot of dealing with motion capture data is “cleaning it up” - chopping off the bits that lead to and from the reference pose, making it run to the target frame rate, and choosing frame data that looks right for the game experience. These changes can be subtle or they might be large. Sometimes you want a 1:1 rate with the original mocap data, and sometimes you want to slow something down, or speed something up so that it reads better or gives a different impression of the motion. There are even times where animators will adjust certain parts to be faster while others are slower. Look at the differences in the above animations - they might seem small at first glance, but the edited frame has a lot more emphasis of the action to the viewer. The raw mocap looks more like the attacker is simply walking up from behind and pushing the victim. While this might work in real life, it doesn’t read as well in a video game. In the edited animation, the attacker has some anticipation built in before the stab to make it look better. Look at the added pull back and then stab forward with the left hand and how the attacker grabs and maintains his hold on the victim’s mouth in the edited animation. See how the overall time is about the same, but some parts were sped up in order to make room for the added anticipation movements?

Motion capture suits also don’t have the extra bells and whistles of in-game costumes. Any extra bits like tendrils, robot arms, wings, tail, or clothing has to be animated separately. That typically means either some sort of simulation (usually via physics or some sort of procedural system), or hand-animating the extra bits. Some stuff lends itself more easily to procedural motion, like clothing. Physical features like tentacles, antennae, wings, or tails tend to be hand-animated, and that’s all about the animator’s skill at making legible motion.

The real answer to your question is that fluid-looking animation isn’t so much a question of the frame rate as it is a testament to animator skill. Animation looks fluid because the animators have carefully selected the right frames to string together to best convey the motion you’re seeing. This is the major difference between really good-looking animations and passable “ok” animations. It’s not a question of how many frames of animation there are, it’s what the animator does with those frames.


Got a burning question you want answered?

alexonyx64  asked:

Say you have an idea for a game and you want to make it. You currently have no useful skills that would be able to contribute to the development, just the idea, but if you're going to try to actually make the game you want to contribute to development in a tangible way rather than just trying to freeload as the "idea guy". What skills would you recommend learning before you try to assemble a dev team so you can actually be useful?

Honestly, your absolute best course of action in that situation is to choose an off-the-shelf engine like Unreal or Unity and learn how to use it. While engineering or design or art skills will all be useful over the course of the project, knowledge and experience with the engine and its limitations will be much more useful. By this, I mean that you must learn how to get outside assets like textures, models, animations, etc. into the engine, how to manipulate them within the engine and its tools, and then how to use the engine and tools to create the rules and systems for gameplay. 

In order to make a game, you need to build gameplay systems and assets. In order to build systems and assets efficiently, you absolutely need to know what is easy to do and what is hard to do. Because you will be limited in terms of time and resources, you will want to leverage as much of the built-in technology in the engine as possible. There’s little point in spending six months writing a UI system from scratch if the engine already has one available that can meet your needs. However, unless you know that the existing UI system will work, how can you realistically make the decision to use it? If the engine can’t meet your needs in a specific field, you are faced with a choice - either change your design, add support for the system yourself, or switch engines. But you can’t reasonably make that decision without first doing the research and making sure it will meet the requirements. That means you’ll need to do a lot of studying and experimentation with the tools.

There’s no real easy way to find out what the engine’s features and limitations are, other than reading documentation and using it. Unity, for example, depends a lot on code to handle anything dynamic in terms of animation. If you want to move the sprite of a dropped item from the ground into a backpack icon, for example, it will need to go through code and not through the animation system editor. Unreal has the Blueprint system, which alleviates the need for code in situations where you can use it. That’s great and can save a lot of time, as long as you know what the limitations of Blueprints are. How do you actually find out the limitations to the Blueprint system? You just have to try making stuff with Blueprints. Try doing each thing - create a basic UI, import a model, texture it, animate it, make a cinematic with it, build an environment, build a control system, build some crude game rules, and so on and so forth. Read the online tutorials, documentation, message boards, and watch video tutorials. Look for useful and free assets you can use in the asset store. Keep track of what is easy to do and what is hard. Think about what the engine can help you do, and note down where you need something the engine doesn’t provide. Compare that to your project’s design and feature list. What do you need that isn’t provided? How can you get those needs met?

Remember, ideas aren’t worth much if they aren’t feasible. The best way to separate the wheat from the chaff is to try to build them. The more experience you get, the easier it will be to recognize the winners. If you can build out a functional prototype, that’s great! Proving out an idea is real progress towards a playable experience that you can iterate on and improve. If it doesn’t work, that’s ok too - the idea might have failed, but you will have learned something just as valuable - why the idea didn’t work, which will improve future decisions and designs. Maybe you can adjust the idea and it might work better, or maybe you can think of an alternative that is better or different but still feasible. But it all starts with figuring out how to use the tools and what their limitations are.


Got a burning question you want answered?

anonymous asked:

Breath of the Wild has made me think a lot about emergent game design - particularly how several of it's mechanics such as weapon degradation and stamina, while iffy ideas on paper, kind of facilitate a sort of variance in challenge that would be necessary for players to be able to go and do whatever they want in an organic open world and feel rewarded. Do developers often think about having to add even the most minor elements that can be seen as "negative" to bring about a better experience?

Sure. We do it all the time. In fact, in a lot of games, drawbacks and negative elements are an excellent way to add texture to a play experience because they force the player to make decisions. In Breath of the Wild, there’s a whole world of ingredients, recipes, and items out there for players to find and use. However, encouraging players to use these items is the tricky part. 

What we usually want is for players to weigh options where they don’t always have a clear-cut solution. Breath of the Wild’s item degradation system does this - you can either use the item now for a temporary advantage, or hoard it for later. And, because players regularly get pretty awesome items, it behooves them to try them out and use them… at least a little. The hard part is encouraging players to do this without making it feel bad. They do this by making inventory space limited, thus encouraging you to use up your items in order to keep collecting and crafting new stuff. When it comes to games, I (like many) fall under the item hoarder side of things. I always want to keep the useful items I find in reserve “just in case”, and typically end up with an inventory full of potions, elixirs, revives, one-time stat boosts, and other consumable items at the end of the game because I just might find something better to use it on later. If I don’t use it now, I retain the possibility of using it in the future “when I really need it”.

This is a known psychological effect called “loss aversion”. The human brain is genetically wired towards loss aversion - humans hate to lose stuff they had more than they getting more stuff. Psychological experiments have shown this effect - people would much rather reduce their chance at loss than take a gamble that has a much higher chance of benefit.  There’s more than one element at work here - first, you’ve got all these things out there to pick up and try, and second, you can’t hoard them permanently so the subconscious loss-aversion parts of the human brain kicks in and says “Well, if you can’t save it, you’d better use it up so you don’t waste it.”

Because your animal subconscious says “I’d better use this because it’s the least interesting thing I have right now that I might need later”, you use it. You experiment it. And then you start having some fun with the experimentation, and you start thinking about other ways you can use your stuff. After all, if the metal sword can be used to conduct electricity in addition to stabbing things, maybe you can solve this puzzle in a different way…

That’s where a lot of the fun in BotW comes from. You find a lot of different toys to play with and some psychological encouragement to use it up to make room for more, and suddenly you have to make a bunch of interesting decisions on whether it’s worth using the last few charges of your thing to get to that island in the middle of the lake over there. Making decisions is interesting for a player only if they have to make a judgement on the results. In the case of Breath of the Wild, it comes to a question of “This item is really cool, but maybe I can get something else over there that’s even cooler”. By removing the option of getting both this item and that one from the player, it turns a trivial solution into a lot of interesting ones.


Got a burning question you want answered?

anonymous asked:

I remember your 5/20/80 rule and it was an awesome post to put perceived vocal audiences into perspective. I wonder if you'd be willing to revisit that idea from a different angle. Let's say the playerbase actually wanted to gain the ear of you/a gamedev to get something changed. What would be a meaningful way to get that to happen? I'm sure writing an angry message on my exit survey when I unsubscribe wouldn't be on the top of the list. Is there a way?

Sure there is. Devs love getting feedback, but we often have to sift the useful stuff from stuff that isn’t particularly useful. That’s one of the reasons we hire community managers. So here are some guidelines to making your feedback useful to us. Some of this might feel a bit counter-intuitive, but I guarantee you that this sort of feedback is the most useful to us.

#1. Speak for yourself

Don’t spend time telling us what the majority of our fans think. You really don’t speak for them and we have the data to prove it. But that’s ok! You don’t have to speak for everybody. Just tell us what you think. Believing you represent everybody else might make you feel like it carries more weight, but it really doesn’t unless you really do represent everybody. You’re already posting on a forum or social media or whatever, which already statistically excludes you from representing everybody. So just tell us what you think. I promise that we’ll listen.

#2. Speak honestly. Avoid hyperbole.

No, this feature did not give you cancer. No, this weapon is not the worst in the game. No, that other class is not our favorite pet class and we do not give them everything they ever wanted. The problem with parsing hyperbole is that it is basically hiding a grain of truth inside a ball of lies. When we have to sift out truth from the lies around it, it makes us grumpy.

#3. Speak about problems. Don’t propose solutions.

Players giving feedback often skip straight to their own proposed solutions and it doesn’t help very much. It isn’t that players who give feedback are bad or stupid - most of the hardcore players who provide feedback are very smart and analytical. The problem is that their proposed solutions often lack crucial context to make an informed decision. You don’t know the limitations we have to work within or the resources we have available. Just because some other game did it doesn’t mean we can do it too. It’s really hard for someone to come up with a feasible solution without knowing all of that information. Just tell us what you don’t like, why you don’t like it, and leave the solutions to us. We made the rest of the game, after all. Give us a little faith.

#4. Speak to a comrade, not an enemy

Remember that we all have something in common - we all like and believe in the game. We all want what’s best for it. Lashing out in anger isn’t going to make us more likely to do what you say. Threats are also not going to work. Threats to quit especially don’t work - the actual rate at which people who threaten to quit and follow through is so miniscule that it is almost unnoticeable. We are not trying to kill your family or destroy everything you hold dear. We want what you want - what’s best for the game. We are not your enemy, even if there are choices we made that you don’t agree with. We know that not everyone will agree with every decision we make, but nobody reacts favorably to being called names and told they’re stupid or incompetent.

#5. Speak with brevity

Refrain from posting enormous dissertations. Keep it simple and short. If you cannot explain the problem with a handful of sentences, you probably haven’t isolated it. This point tends to be related to #3 - usually, articulating a problem isn’t that difficult to get across in a sentence or three. It’s the solutions that tend to require a lot of explanation. Here’s the biggest issue with walls of text - the feedback will be distilled down by the community managers for the devs anyway. They’ll condense it all down to a list of bullet points and give it to us. So why not cut out the middle man and make it easier on them? They’ll certainly be happier if you do them the courtesy. 

#6. Speak without expectations

There is nothing you can do to guarantee that we will do what you say. You cannot argue us into doing what you want. You cannot force us to do what you want. You cannot “logic” your way into doing what you want. It is very likely that we won’t always acknowledge you individually, because there’s so many of you for each one of us on the forums that it’s just not particularly feasible. Also, don’t take dev or official responses to indicate the only posts we’re reading. The feedback that gets collected and passed on to us isn’t only gathered from those posts that garner official responses. The majority of the useful feedback won’t ever get an official response -most of us believe that the best way to acknowledge your feedback is to through the game itself (even though it is likely that changes are weeks if not months away… patches need to pass testing and cert, after all). 

And that’s basically it. I know that the fans that engage with the game’s community and developers are super passionate and only want what they feel is best for the game. If you didn’t care, you wouldn’t reach out. Believe me when I say that we devs feel the same way. Please believe me when I say that well-written, concise, and honest feedback is far more likely to reach us than anything else. I swear that’s the best way to get your feedback heard and considered.


Got a burning question you want answered?

anonymous asked:

Hi, not sure if you are interested in Bloodstained, but from the trailers / gameplay videos released so far (some new videos were released for E3 2017), the game does not look too good in my opinion. I can't exactly define what is bad / missing (maybe its a general lack of polish or the "slow" controls). Can you comment a little about this game and its current quality from a game developer perspective? Thanks!

For those who haven’t followed Bloodstained, it’s a new Metroidvania style game from longtime Castlevania producer, writer, and programmer, Koji Igarashi. It was successfully crowdfunded back in 2015. Here’s some gameplay video of Bloodstained in action, recorded at E3 2017:

So… what’s wrong with it? Why does it look bad? There’s two main problems I see with it and both are animation-related.

Problem #1: Everything takes a long time

I downloaded the above video and scrubbed through it frame by frame. The video was captured at 30 frames per second. Almost all of Miriam’s motions are stretched out over many frames of animation, making them feel like the overall game is slow. Her normal fast attacks have 4-5 frames of startup (anticipation, before actually striking) around 25 frames to complete. Heavy attacks with the Claymore sword have 14-15 frames of startup (not striking until half a second after the animation begins), and took 32 frames to complete (more than one second). Picking up a shard (which happened quite often in the demo) took five seconds. It takes two seconds to get a special item in Symphony of the Night.

This is the top of Miriam’s jump arc. Notice how she’s not changing height here at all, and yet there’s still a solid five frames of just floating along horizontally? These extra frames of animation make the player feel like Miriam moves more like a balloon than a slayer of evil. Her jumps feel super floaty because of all this extra time in the air. In comparison, Alucard from Symphony of the Night only spends two frames at the crest of his jump before descending. 

Here’s a sword attack from Bloodstained:

And a similar sword attack from Symphony of the Night.

They are both running at the same frame rate.

Bloodstained has all sorts of movement and combat animations that feel unnecessarily long, and the overall effect is that the game looks and feels floaty and sluggish. It’s a real problem for a game of this type, because the vast majority of the game is spent moving, jumping, and attacking. These motions must feel responsive and tight, and that means short, snappy animations that read well. Bloodstained is supposed to be a spiritual successor to Castlevania, but Castlevania had super responsive and tight controls, and that meant super responsive and tight animations that were played as a result of those controls.

Problem #2: Miriam’s body language is lacking

In most of the actions Miriam is performing, she doesn’t really convey much about who she is or how she’s different. In fact, most of her movements look very much like they were directly inspired by Alucard. The problem is that Miriam should be her own separate person. If you’ve ever played Overwatch, you can tell a lot about each character simply by the way they move. The body language gives you insight about the character. Tracer shows how expressive she is by sticking her arms and legs out all the time. Mei keeps her hands and knees together because she’s shy. Soldier 76 keeps his arms in tight to his chest because he’s old and grumpy, and so on.

What we expect from a slayer of evil would be a wider stance - feet firmly planted and spread apart for stability, facing her potential foes, arms loose and ready in case of trouble. It’s a comfortable stance that’s ready to rumble. Maria Renard (pictured) has a stance like that. Alucard has a stance like that. Miriam does not.

Miriam’s body language is kind of a mess. Her idle stance is this odd side-facing stance with knees together and one arm raised. She’s not facing her threats unless she attacks. Her knees and ankles are kept together, which makes her seem nervous. She has one hand lifted to her cheek as if she is about to sneeze. This pose is not comfortable at all. This visual does not depict a monster hunting slayer of evil. Overall, she looks more like she’s posing for a fashion photographer than ready to fight. If she’s supposed to look this way, then the normal combat animations certainly don’t show it. When she swings a sword, whip, or spear, she looks like she knows what she’s doing. But then she returns to this odd, unnatural looking idle pose and everything feels off. It’s this weird lack of consistency in her movements that throws things off kilter.

Overall, they could improve how the game feels simply by increasing the speed. As an experiment, go back to the youtube video shown above, click the gear icon and change the speed setting to 1.25x or even 1.5x. Now watch some of the gameplay. See how much better it feels? Then throw on some music for atmosphere, and it will feel a lot better. Depending on how final these assets are, there’s still time for them to improve on this. I’m sure the animators at the very least are aware of these problems. I just suspect that there’s somebody in a position of authority that likes it this way.


Got a burning question you want answered?

anonymous asked:

Why do console makers charge for online multiplayer? Do developers benefit at all from this? Or do only Sony and Microsoft benefit? How is pc able to be free multiplayer when I am constantly told servers cost money to run? Hoping you could shed some light on this. Thank you for your time.

Why do console makers charge for online multiplayer?

The general reason is because people are willing to pay for it. Microsoft tried it way back with the original Xbox and it turned out very well for them. Sony followed suit in the PS3 generation and players paid for it there too. People have gotten used to paying for it now, but it isn’t just for online multiplayer either. Players who pay for the service also get other kickbacks - free games, access to demo content, access to certain additional features, and so on.

Do developers benefit at all from this? Or do only Sony and Microsoft benefit?

We (devs) have benefited historically from paid online services (if a bit indirectly). A lot of the online features we’ve come to expect today were pioneered on the paid platforms like XBL and PSN - chat rooms, friends lists, achievements, DLC sales and distribution, and so on and so forth. Features like achievements were built by engineers on the platform side; the game devs were then supplied with a SDK full of new tools to use on our projects. Having that kind of support, especially in the 2004-2008 era was really helpful. Those features didn’t migrate to Steam until later.

That said, it’s practically impossible to take just the online platform as a discrete, self-contained thing because we really can’t. Part of any dev studio or publisher’s relationship with console manufacturers is via the certification process, and their online services are deeply intertwined with it. The online platform isn’t so much its own thing as it is an extension of the total console package.

How is pc able to be free multiplayer when I am constantly told servers cost money to run?

It’s mostly because the biggest service set up on the PC (Steam) is free, and everybody who followed couldn’t sustain a critical mass of customers while switching to a paid service. It’s really very similar to how Microsoft managed to establish the paid service early on.

The maintenance, development, and hardware costs for online play are always being shouldered by somebody. On Steam, it’s paid for by the publishers and devs who sell games on the platform. Steam takes roughly 30% of every sale, and some of that goes to paying for the service and any other endeavors Valve is taking (Steam Box, VR stuff, etc.). On the consoles, it’s paid for partially by the publishers, and partially by the user fees. Consoles also take around 30%, but that isn’t just for online services and game development. It  also pays for console manufacturing costs, R&D, administrative costs, continued development of the platform software, and so on. 

The business stuff can get really complicated really fast due to all of the different parts that can change. It could be possible that Microsoft decided to make XBL free, but that would result in a reshuffling of the overall allocation of funds. Microsoft could make up for the loss of subscription fees by raising the cost of publisher certification, or scaling back XBL development to be less expensive. If they raised the cost to the publishers, it could drive publishers to competing platforms, or it could mean that game budgets get adjusted down to defray the higher costs. If that were the case, it could mean that new games would ship with smaller scope or with more bugs, or any number of things. There’s no one single result from a change like this, but many possibilities depending on what each involved party decides is in their own respective best interest.


Got a burning question you want answered?

anonymous asked:

Based of your recent post on leveling where you explained everything that was wrong with the said system, could you go into depth about what makes a good leveling system?

This particular topic can be a real rabbit hole, but let’s try to keep it to the basics for today. At its core, a leveling system is a series of goals and rewards for the player. The player plays the game, reaches certain pre-determined requirements, and obtains discrete new rewards for doing so. Because this is a system that dispenses rewards to the player, it needs to meet a few criteria:

1. The rewards must be meaningful

There has to be some sort of tangible benefit to rising in level - the authorization to use better equipment, a new power or more currency to buy/improve powers, etc. This builds anticipation - leveling up should be something that the player looks forward to doing, and that isn’t possible if leveling up doesn’t actually do anything. A good leveling system will excite players and encourage them to keep playing - they want to get one more level, because they get something good at level N+1. 

Consider Dungeons and Dragons, the tabletop game. Each character level is a really big deal in D&D - you get significant choices to make at each level that will (usually) greatly affect your character’s power. On the opposite side of the spectrum, Castlevania: Symphony of the Night for the PSX had an almost-useless leveling system. The primary methods of gaining power in that game stemmed from collecting useful items from defeated foes, while leveling up provided small incremental amounts of HP and magic power. The character level in that game was practically vestigial. Nobody who played that game looked forward to leveling or cared what level they were.

One of the biggest things that a system designer has to do when creating a leveling system is to come up with a variety of rewards for the player to look forward to. Stat improvements, authorization for new equipment, new or improved powers, new visual effects, and opening up new areas to explore are the most common rewards for leveling, and it makes sense because the player should naturally be interested in obtaining these things. Furthermore, there has to be a good variety of rewards to leveling up, or else the player will get bored. More HP and MP at each level without any other benefit stops being appealing really quickly. If you vary the rewards and keep them interesting enough that the player will look forward to them, you can keep interest for a lot longer.

2. Rewards must arrive in a timely fashion

A good leveling system must take timing into account. Earning a level should be a fairly uncommon experience - players need time for the anticipation of the next level to build or it won’t feel meaningful. If a player gains a new level every few seconds, that player will quickly grow indifferent toward leveling because of how often it happens. On the opposite end of the spectrum, we designers also cannot let the player go for too long without a reward either. If a task seems too difficult, troublesome (especially if it lacks a reward befitting the effort), or like it takes too long, players will tune out and won’t bother with or pay attention to it. The reward must be delivered somewhere in that sweet spot between, where the player feels like they have accomplished something, but not so far away that they feel it isn’t achievable. This time length is informed by a number of factors - the type of game (e.g. leveling a champion in League of Legends vs leveling a character in WoW), the platform (mobile vs console vs pc), and even the length of the game.

3. Rewards must be earned by player action

Rewards exist to encourage players to do things actively in the game. Experience points are just smaller rewards that build up to earn larger ones (levels). The designer uses these smaller rewards for completing in-game tasks, like defeating enemies, completing objectives, winning matches, and so on. The nature of experience point rewards does two things - it provides a sense of scale for the value of each action/objective relative to others, and gives the player a sense of progress towards the bigger goal of leveling up. If the player just passively earns experience by standing around or is disproportionately rewarded for completing repetitive tasks (e.g. grinding), it can short-circuit the sense of accomplishment that they would get by playing the game as intended. It’s important to keep this in mind - a good leveling system preserves the sense of player accomplishment by rewarding different player actions.

So how do we actually bring all of these concepts together practically?

Design principles are all well and good, but how does this actually translate to designing an actual leveling system? This is where system design’s mathematical nature kicks in. We start by asking ourselves questions and choosing answers for them. As we start answering them, we can start building up a mathematical system to generate the specifics. Here are some of the questions we need to ask ourselves:

  • How many levels do we want at maximum? 

This decides how many different level rewards we have to create or assign.

  • How long should it take to reach maximum level, on average? 
  • If this is a single player game, at what point in the game do we expect the player to reach maximum level? How many hours do we expect that to be?

These questions combined with the other question above determine how long we expect each level to take. If we have 30 levels distributed over 60 hours of gameplay, then we expect each level to take two hours on average to earn. That might feel a bit long, so perhaps we can make 40 levels and a new level every hour and a half instead, assuming we have enough rewards. This gives us a target levels per hour (or LPH) value to earn X levels in Y hours. 

  • How many LPH should the various activities provide?

Remember, we have a specific target value of LPH in order to reach maximum level by the end of the game. We can decide that breakdown here. Maybe killing things is the most efficient means of leveling. Maybe it’s completing quests. Maybe it’s exploring. What factors might affect this? In World of Warcraft, for example, grouping up will split the experience earned from kills among group members, lowering the LPH from killing things. We have to make sure that we tune the LPH of the various activities in aggregate to match the target LPH for the full game. We can then break down the components for the activities… traveling, interacting/talking with NPCs, fighting, etc. as well. Having a target LPH can also be used to check for efficiency - if an activity has a higher LPH than average, it can potentially be used to advance faster than we expected.

Let’s assume we have a 40 hour game with 40 level rewards to distribute, we can expect one new level roughly every hour. This means that our level-appropriate activities should add 1 LPH. If we want a quest-centric game, we could make quests provide +0.75 LPH and the mob killing associated with it provide +0.35 LPH (and have most of the quests require killing stuff), so the player can do both at the same time. If we wanted to emphasize the killing, we could make quests only +0.2 LPH and the killing 0.9 LPH. We can adjust these ratios as we like in order to direct the gameplay experience that we want for the player. You might have noticed that I had these examples add up to over 1 LPH at perfect efficiency. That’s intentional - we don’t expect players to be perfectly efficient, so we build in a bit of buffer for them. 

If we decide we want 1000 experience to gain a level, this means that we’d want quests in a quest-heavy game to provide 750 experience per hour and killing things 350 experience per hour. If we then extrapolate that to mean that we expect the player to complete 10 quests per hour and kill 70 things per hour, then we can figure that one quest should reward 750 / 10 = 75 exp per quest, and killing 10 things should yield 350 / 70 = 5 exp per kill. We can then try these values to start with for our playtests and see how they feel.

You may have realized that what we’re basically doing here is working backwards from our goal to calculate what the exp reward values should be. That’s no coincidence; it’s the core of systems design. We’re starting with the sort of play experience we want the players to have on a macro level, and breaking it down into systems and formula by using math. This is what systems designers do - they look at the large scale goals and the experience that they want the player to have, and break it down into a bunch of numbers and formulas that will take the players to the goal. Unsurprisingly, this means that there’s often a lot of spreadsheet work involved with these calculations. The actual math here isn’t particularly difficult, but it can be very fiddly because of all of the potential factors involved. The math also is not the end-all and be-all of it. It gives us a point to start with - tools with which to work. Once we’ve built the foundation with it, we can then play with and tune them until the experience feels fun and engaging. That’s a critical part to it too. It’s like constructing a cyborg - you need both the mathematical robot aspects of it as well as the human feeling parts to make it really live.


Got a burning question you want answered?

anonymous asked:

Why does it seem like some games just can't get gun sound effects "right"? As in, they don't sound "powerful" or are so "light"/high pitched, they sound like airsoft guns? Are they unable to use actual recordings of gun sounds, so they have to attempt to recreate them from other sources?

Here’s the issue: Whenever you give the player a bunch of different guns, you need them to feel distinct. They have to exhibit different behaviors from each other or it won’t matter which gun you use. A large part of the gameplay is how the gun makes the player feel, and sound design is integral to that. Normally with weapons, we can differentiate them in the way they look. Animation, weapon model, etc. are all big on making them feel different. However, realistic guns are a little different. They are hard to see from a distance, and most gun-wielding animations are the same. Thus, in order to differentiate guns from each other, we tend to lean more heavily on sound design.

Most guns sound pretty similar to each other in reality. This is primarily because they all fire some standard ammunition.  the game just feels better when the more powerful bolt-action rifle has a deeper, more resonant sound than the rapid fire submachine guns or the assault rifle. Good sound design can help mentally solidify the gameplay differences of the different weapons, even if it isn’t particularly accurate. Your brain associates the game’s sounds with the behavior of the gun in the game, because most gamers lack real life experience with a CZ 75, Steyr Aug, or a FN P90. The amount of damage and kick you expect from a rifle is subconsciously affected by the sort of sound it makes when you fire it.

Because of how difficult it can be to parse the sounds, players also usually won’t be able to tell what sort of guns their opponents are using. One of the most important elements of game design is presenting different types of things to the player such that their brains can immediately differentiate them. This is done by using multiple bits of information to the player that are processed almost subconsciously - movement, silhouette, sound, color, vibration, etc. Even though the sound effects we use aren’t the most accurate, it’s not intended to be. We could get the real recordings if we wanted, but it’s far more important to make them all sound different for gameplay purposes.


Got a burning question you want answered?

anonymous asked:

So in the recent Pokémon direct, a lot of people are upset that the new Pokémon Ultra Sun and Ultra Moon games are coming to the 3DS and not the Switch. From a game developer and a business point of view, why would Game Freak or the Pokémon Company release their new main games on an old platform instead of putting it on the Switch where they could make more money?

There are a few reasons why I think Pokemon Ultra Sun and Ultra Moon targeted the 3DS:

  • I don’t think they will make more money by bringing it to the Switch. There’s 60+ million 3DS units in circulation and less than 5 million Switches.
  • The engine, code, assets, tools, and support infrastructure is already in place for the 3DS, meaning they could create significantly more new 3DS content and features than spending that time porting the game to the Switch.
  • Many of the people who will buy Ultra Sun and Moon already have game data saved for Sun and Moon. They will be very displeased if there’s no way to bring that data over.

I think that the Pokemon Company might consider the Switch for Pokemon’s 8th generation, but I don’t think anything will happen until after they finish with the 7th first.


Got a burning question you want answered?

anonymous asked:

How does game optimization work, particularly for PCs where you can never know what combination of specs the player has? Is it interwoven to every stage of game development or is it only done at the very end right before the game is published?

Optimization generally comes in two flavors: speed and size. Since we have finite time to do things, we want things to run faster in order to do more things in the same amount of time. Similarly, we have finite memory to hold data so we want to make as much use of the limited memory we have as possible by keeping the things we load as small as possible. Most of the time optimizing for speed trumps size because disk space and memory is easier to add than computing speed… but we always want to pack as much as we can into both, so that we can deliver the most game that we can.

At its core, optimization is a question of avoiding unnecessary work. For example, let’s say that we’re working on a first person shooter and the player turns to change the camera. We have a list of all of the entities that exist in the world. We need to figure out whether each entity needs to be drawn. We can simply go through the list and ask “Is there anything in between you and me to stop me from seeing you?” and get an answer, but let’s say that doing the specific check takes a while. If we have to do it for every entity in the game every frame, this can eat up a lot of resources.

But let’s say that we also have a pretty fast condition we can check - let’s say we can ask the entity “Are you behind the player character?” and it will have to answer “yes” or “no”. Suddenly, we can start ignoring a lot of these world entities. After all, if our player can only see what’s in front of her, there is no way that she could see something behind her, right? This means that we should ask this question to every entity that we might see, because it will avoid doing the more expensive “check whether anything is in between us” operation when we don’t have to do it.

Let’s extrapolate on this concept further. One common optimization is using “LoDs” - levels of detail. The idea is that an object that’s very far away from the viewer is hard to see and is only a speck on screen, so we don’t have to render it at full detail because the player can’t see those details anyway. Therefore, we can get away with rendering fewer polygons on the far-away models, and a lot more on the up-close ones. This means that we have to load multiple models for the same entity (each level of detail needs one), but it also means that we are cutting down on the number of polygons the system needs to draw at any given time.

Let’s take this further. Another way of optimization is by minimizing the number of loads we have to do from disk. Hard drives hold a lot of data, but it takes time for the cpu to load the data from them. The reader in the hard drive needs to seek the right position, magnetic disk needs to spin to the right place to be read, then the data needs to be read from the spinning disk and written into memory. This can take a relatively long time. Let’s say that we have our LODs, but we need to load textures for them. Low detail models only need low detail textures, after all. But we want to avoid the set amount of time it takes to load a file. How do we speed it up? What we can do is take all of the textures for the all of the different LOD models and put them all into one big texture. Since we know we’re probably going to use all of the different LOD models, we might as well load all of their textures at the same time too. This means we don’t have to wait for multiple separate loads. These are called Mipmaps.

If you haven’t noticed, these kinds of optimizations apply to all platforms because they are all computers and generally behave the same way. Whether it’s a PC, mobile device, or console, it still has to load stuff from disk, it still has a CPU that runs at a certain speed, and it still uses main memory to load stuff. Don’t get me wrong, there are optimizations we do that are specific to the platform as well, but those tend to be more specific. Most dev teams start optimizing the general stuff as soon as they can, because optimization is part of the planning process too. The goal of optimization is to minimize the resources we use in an intelligent manner. That way things can run faster. Sometimes it means being smart about where to spend our time, and avoiding the expensive operations if we don’t need to do them. Sometimes it’s about using up resources we can spare (such as memory) to save time from loading. Sometimes it’s about trading resources we can spare (like memory) for resource we need (like lowering the number of polygons we have to draw each frame). But it’s all to make things perform more efficiently and that’s always a worthy goal.

Further Reading:


Got a burning question you want answered?