anonymous asked:

Is there any particular reason simulated physics in games usually feels so floaty/bouncy? Floppy ragdolls, swords sliding down hills, table settings prone to pop off the table, it just seems really difficult for physics in games to be made to feel right. What's up with that?

Mostly it’s because physics simulation is just an approximation, and that physical objects moving in reality have a whole lot more properties than the approximations can handle.

If you’ve ever taken a physics class in school, you must have noticed that the material tends to do things to simplify, such as assuming that the objects are in a vacuum, or that the velocity is applied instantaneously, and so on. These all serve to simplify the equations for the sake of teaching a principle. Real world physics are extremely complicated. There’s air resistance, friction, qualities of the materials that are involved, objects touching objects touching objects, and so forth and so on. There is also no cap on computing power for the real world to run at a high frame rate.

When a sword slides down a hill in a game, it’s because there’s some kind of gravity being applied to the object on an angled surface. Most game physics simulations just take basic properties into account like mass, various forces, and the (basic) properties of the material it’s on. We make approximations such that most visible things don’t behave super weirdly. Our physics simulation formulas are often incomplete - they work most of the time, but under the right conditions, for example, falling objects can steadily increase in their acceleration. This is why, in Skyrim (sometimes), objects falling and bouncing down a hill can get launched off into space - it’s because their physics simulation didn’t account for all of the factors at play in that situation.

Most of the issues stem from simplifications and assumptions we make to ensure that the physics simulation isn’t so complicated that it affects the frame rate. If you remember my old [Corpse Volcano story], there was always a noticeable performance hitch when I shot the bodies because there were suddenly dozens of physics objects (corpses) all exerting force on each other at the same time. I suspect that, as processing power improves, physics simulation will also continue to improve. We devs get more annoyed about the weird physics artifacts that we see than you do, because we are the ones who spend our time trying to make it look right to begin with.

Got a burning question you want answered?


  Today was the first day I’ve ever played around with Linux. The Distrobution I have installed is Ubuntu. I’m getting comfortable navigating around in the terminal. Anyone here know Linux well? How do you feel about Linux as apposed to Windows or any other OS?


Update on a VR project I’m doing! This is the first (almost) finished scene, a locker room.

Guess what the game will be about :D

I’m very excited about this, though. My main line of work is being a programmer, so dusting off the modelling skills and being able to do such a room, that’s the dream!

The wall object has some 14k+ tris, but I’m not worried because it will be just this room in this scene. For future improvements, though, I will have to take a look at the texture sizes; they’re too small for the floor and the walls and maybe too big for other objects. Also, I’m not totally in love with the locker color or the blackboard scratches.

See you soon!

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?

Game development started as a hobby; about two years ago I made some simple renditions of classic arcade games with Pygame before I got my first job. But lately, I guess this hobby is starting to get serious. xD

The Ultimate Guide to Video Game Writing and Design

Video Game Storytelling: What Every Developer Needs to Know about Narrative Techniques

Game Programming Patterns

Drawing Basics and Video Game Art: Classic to Cutting-Edge Art Techniques for Winning Video Game Design

anonymous asked:

I was watching a speed run of Prey (2017 version) where the speed runner managed to beat the game mostly by pushing into corners to glitch through walls/ceilings. My question is, why are the corners of rooms in video games so often full of holes to outside of the level geometry?

There’s a variety of possible answers to this question, and each is reasonably likely. It could be the level geometry itself, it could be the simulation/collision system misbehaving. I’ll try to give a condensed explanation for both.

Remember, level geometry isn’t like a real building. There’s no inherent sense of physicality to anything placed in the world, no gravity, nothing actually attached to something else. Everything is just polygons with pictures painted onto them, so it is up to the level designers and environment artists to make sure everything is placed properly. In early 3D games, these sorts of mistakenly-unconnected seams were called leaks. This was because there was no such thing as dynamic lighting, so the lighting for each level had to be calculated at compile time and couldn’t be done properly if the geometry leaked. If the lighting engine detected a leak, it meant that the lighting would be all wonky and the designer would have to fix it. It’s very easy for a leak to slip through - I can’t count the number of games I’ve seen with objects floating off of the ground by an inch or two, or wall decorations floating near a wall. Level designers and environment artists place a lot of objects and polygons; making sure that they are all flush isn’t an automatic process and can cause trouble. Some tools have settings to snap edges together to protect against this, but it isn’t always on and can be turned off for some cases. Accidental geometry placement often cause another common problem - getting stuck in a falling state. Often when you have a lot of geometry nearby that is steep and lacks a flat spot wide enough for a player to stand, the player can get stuck perpetually falling and unable to escape.

Another issue could be the way the engine handles pushing against solid objects. Part of this is due to the nature of how computers work - nothing is actually handled continuously, but over a series of discrete time steps. Every time the game updates, it must figure out where the character should be. Another part of it is the fact that characters established position is usually directly beneath the character, often between the feet. For example, if the position were to get shoved downward by just a few inches, the character’s position would be under the floor and the gravity would take over, causing the character to fall out of the world. 

If the character’s movement for the frame would change her position to one where her bounding box interpenetrates another polygon marked as collision, the engine will need to move her somewhere “safe”, usually by repositioning her at the very edge of the colliding polygon. However, the issue can crop up when the character attempts to push on two or more edges at the same time (like in a corner). The engine can’t apply all of the pushes at the same time; it has to go through each of the collisions it detects individually. Because it does this, it is possible for the later collisions to potentially push the player into a position that is invalid because it’s new “fixed” position - a perfectly legal position relative to colliding polygon B, now interpenetrates colliding polygon A that had already been processed earlier. Once the character is in a bad position, she can end up either stuck inside geometry, pushed somewhere else, or even fall out of the world.

Other common issues can be things like randomized forced movement. In World of Warcraft, for example, fear and teleportation effects could often cause players to get stuck in geometry or fall through the world. Imagine, for example, an ability that teleports you behind another player, ostensibly for a backstab. What happens if that player has his back to a solid wall? Where should your character appear? Should it be behind the wall? If so, that could end up being in a bad position. Should it be in front of the character? What if the character wedges himself in between two walls with no room? Another situation could be if the target character is standing on a slope while facing downhill. The teleport position directly behind that character would be underground, and would have to be adjusted upward in order for the teleporting player to appear correctly. But there would have to be height limitations too, or else the teleporting player could potentially get on top of objects not meant to be scaled by teleporting behind a confederate on a slope with his back to the thing you wanted to climb. And so on and so forth.

There are ways for engineers and level designers to try to work around these, but there will always be (literal) edge cases that can cause even the most carefully built systems to break down. That’s really what you end up seeing in these cases. Sometimes the result is great for speed runners, because it allows players to skip portions of the game. Most of the time, it just ends with the player getting stuck.

Got a burning question you want answered?

I thought I couldn’t explain game programming but I can.
Tickle your tummy with a feather
blindfold yourself
now stab yourself to try and relieve the itch,
The stabs leading up to you finding the itch will be the most painful thing ever and when you find the itch the payoff feels so good, not because you have found the itch - but because you can finally stop stabbing yourself.

How are video games made?
By looking at this code for a day trying to figure out where a rounding error is coming from, and I love it.

Everyone should have a thing;
I don’t know how artists manage to paint or how writers write books or how musicians do their thing. Code is my thing,
it’s fundamentally collaborative and requires a weird kind of logical creativity, and I get to make video games with it.
The downside is it’s hard to explain this to people.

Angry Birds Addiction Analysis

You can’t stop playing you know this game has been played to death but… you can’t stop. It’s okay, you’re not alone. We’ve all been there man. We’re here to help you. Now a lot of people can come in quickly and say Angry Birds sucks, and they wouldn’t be wrong. However to those who are addicted, they just say it’s an “awesome game”. In reality it’s just using what I talked about last time. Luck. For a bit of it anyways.

External image

Luck is addictive, it’s the chance that something good can happen, and you know if you keep trying, eventually, it will happen. Angry Birds is a whole game series built around the bonus round. Yes, it takes skill to some degree to figure out where to send the birds, but there’s only so many possible ways to send them, and it seems that, even if you shoot the exact same bird, at the exact same angle, and speed, it bounces differently. This, is where the game messed with your head. It did bounce differently, that’s the point. In early stages, there are multiple solutions, so that you don’t really notice this effect. Later stages though, they have usually, two to three solutions. The luck is in the numbers playing in the background.

External image

I can’t say for sure what exactly is going on after close inspection. I will say with confidence however, that the game skews the physics of the bird after launching(perhaps predetermined before you shoot, that would be extra evil). So again, it’s a numbers game. Sometimes you’ll sit there, and know the solution but just can’t quite get it to work. So you keep trying… and trying…. and trying. They wait until later in the game to do this to you, but the truth is they’ve slowly got you addicted, to what amounts to a bonus round in any other game. You have some control of the variables, the player chooses when to shoot, and how it shoots, but it requires a combo of luck and skill in late levels to complete them.

This is great for them, as they want to pad the game to draw it out, to give time for players to become addicted, and clearly, it worked, as there have been so many games now(As of this writing there are four games with countless ports and two more on the way). I think game designers can learn from this. The evil is inherent in the design of the game no doubting that, but, because it asks so little of you, I can’t really fault it. Mobile developers take note if you want to make the next Angry Birds, play with your players, make them keep playing, and constantly update to keep their addiction going. 

Note: I am aware that there is also a great marketing, and licensing team pushing the game to make people constantly be reminded that, hey Angry Birds is a thing that exists. However I’m only here to discuss the addiction hooks the game has employed right into is design. Sorry to anyone who wanted to see some of this.

External image

Which is probably the coolest thing I’ve seen in a while. You can quote me on that.

anonymous asked:

I'm applying in the industry right now as a Gameplay Programmer, and one thing I have a hard time providing for companies is code samples. I mean, as a game dev, you never want your code to be too complex because it then becomes harder to debug, right? So what kinds of code samples are they looking for? What types of projects should I work on that would help produce those kinds of code samples?

Code samples are kind of a weird thing, because it’s often difficult to give one piece of code and get enough context to learn enough about the programmer who wrote it. Most of the engineering hiring managers I’ve talked with about this subject prefer to give self-contained programming tests instead of asking for code samples for this reason. That said, to understand what kind of code samples they’re looking for, you need to understand what they hope to learn from the code samples.

#1. We want to see you solve a non-trivial problem

We write code to solve problems. Some of it is fairly rote automation of stuff, and that’s something pretty much anybody can write… that’s not what the hiring manager is looking for. The more interesting samples involve solving a problem where there are multiple potential answers, and some of them are clearly better than others. If the problem can be solved in O(n log n), then the hiring manager will be disappointed if you solve it in O(n²). The best answers are fast, clear, and elegantly handle failure. Show us a real problem that you solved in a fast, clear, and elegant way.

#2. We want to see your mastery of the language and architecture

When programming in any language, there are going to be little optimizations of the language that can add up over time. In C++, for example, declaring variables of the same fundamental type together saves memory. Passing const references to objects is usually better than passing an object by value. You should know these kind of gotchas, because it shows a better overall view of code - we want to see that making little optimizations like this are second nature to you.

#3. We want to see your code’s legibility

You’re looking to join a team, and that means working with other engineers. At some point, somebody else is probably going to have to pick up code that you wrote and you’re not going to be around to answer questions about it. Maybe you’re on vacation, out sick, too busy, or have moved on to another project but, eventually, somebody else is going to have figure out how your code works by looking at it. You should imagine that this somebody has severe rage issues and will come after you if you force her to read difficult or awful code.

This doesn’t just mean “comment your code” either. While commenting code is useful (and I encourage you to do it), the code you write should be written with clarity in mind. The entire architecture of your code should be intuitive and clear. The function name should clearly state exactly what it does and it should return something appropriate. The parameters passed in should be easy to use correctly and hard to use incorrectly. A new programmer who comes in and looks at it should be able to understand what it does. A new programmer who just looks at the declaration should be able to figure out how to use it.

Overall, hiring managers want to see that you can solve problems in an efficient and elegant manner, that you understand the language and its idiosyncrasies, and that the code you write is good in a team environment. This is what your code sample should show us. If you don’t have something like that lying around, give yourself a relatively small-scope coding challenge (like writing a text-based checkers program or a program that solves a boggle board that’s just an N by M array) and come up with your solution for it in the given language. Review it. Show it to other programmers and ask them to nitpick it. Re-review it, and make sure it is code you can feel proud of.

Got a burning question you want answered?

anonymous asked:

Do programmers have any input on features of the game or are they just slaves to what the designers want?

It depends on the programmer and the team. Some teams are very siloed from each other - the engine programmers, graphics programmers, or server programmers don’t always have a lot of interaction with the game designers, for example. Gameplay programmers are the ones who usually work most closely with designers, which usually leads to them being the most influential. I’ve actually been on both sides of this relationship, and I have to say that the best results come from designers and programmers working on ideas together.

The theoretical relationship between a gameplay programmer and a designer tends to be similar to the relationship between the American president and congress. On paper, congress writes and passes bills, then the president may veto/deny any bill that congress sends to his desk. Similarly, design is usually free to come up with any ideas they want, but the programmer who actually has to write the code to make those designs a reality may veto the design if it isn’t feasible (e.g. it kills performance, uses up too many resources, takes too much engineering time, etc.). If that veto happens, the design needs to be reworked until it is feasible (or scrapped).

In reality, the relationship is more collaborative and less absolute. No designer wants their ideas constantly denied, no programmer has the ability to unilaterally veto each designs without a good reason for it, and no producer wants to waste development time. So what actually happens is that designers come up with ideas and programmers help massage those ideas to make them a reality. Sometimes the programmer will have suggestions as to how to make it work. Sometimes the designer needs a better understanding of what kind of technical constraints the feature is under. Neither role really has absolute power over each other, but a good relationship between programmers and designers functions as a force multiplier for better overall results.

The main issue here is that the designer often doesn’t know what is and isn’t feasible within the code, and the programmer’s job is to empower the designer to make the content. The difference in implementation time between two very similar-sounding solutions can be (and often is) enormous, and the designer typically lacks the context to make those evaluations. When I am the programmer in this situation, I find that the most useful question to ask is “What is the problem we’re trying to solve?” because it helps reframe the situation - I’m not trying to be the wet blanket, but I’m trying to figure out the mutual goal. How can we make this request actually work towards the real goal? And as the designer, I always want to take the programmer’s suggestions under advisement because she knows what’s going on under the hood far better than I can. Designer ideas are usually cheap and easily discarded; one creative director I know likes to say that a good designer only makes around 5% of his ideas actually happen. The programmer isn’t the one coming up with all or even most of the ideas, but absolutely gets a lot of opportunity for input during the creative process. I know I definitely did.

Got a burning question you want answered?