Jump to content
  • Advertisement

Ming-Lun "Allen" Chou

Member
  • Content Count

    37
  • Joined

  • Last visited

  • Days Won

    1

Ming-Lun "Allen" Chou last won the day on May 18

Ming-Lun "Allen" Chou had the most liked content!

Community Reputation

982 Good

1 Follower

About Ming-Lun "Allen" Chou

  • Rank
    Member

Personal Information

Social

  • Twitter
    TheAllenChou
  • Github
    TheAllenChou

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ming-Lun "Allen" Chou

    Get Angle of 3D Line and Rotate Polygon With Result

    Actually, atan2 is different from atan. Atan's range only spans one PI (2 quadrants), and atan2's range spans 2PI (all 4 quadrants). The separation of the individual parameters eliminates the sign ambiguity of the inputs. (e.g. All atan sees if called as atan(-1.0 / 2.0) is -0.5 being passed in. Does that mean (x, z) == (-1, 2) or (1, -2)?)
  2. Ming-Lun "Allen" Chou

    Modeling restitution

    For the games I've worked on, we use physics engines on things that we need to look "physically plausible" (destruction debris, tossed objects, etc.), but not on things that need be precise (e.g. character movement). In other words, we treat game physics engines as decorative tools, and we don't base core game mechanics on unsupervised physical simulation. For things we need to be precise controls over, we always use specialized logic outside of the physics engine. If a Newton's cradle never interacts with anything, then I'd just have it animated (simulating it physically is a waste of processing power). If it can interact with other objects, then I'd still have it animated, but physicalize it when touched by other objects. Once it's physically interacting with other objects, I doubt physical precision would be a concern, unless the Newton's cradle is the absolute major focus of the game.
  3. Ming-Lun "Allen" Chou

    What are the physics algorithms used in this?

    Not sure. But if all you need is what's shown in the video, then I'd say using a full-blown physics engine is an overkill. You probably don't need things like friction, restitution, torque, etc. I'd say all you need is a decent broadphase and specialized circle-vs-circle collision resolution (or peer avoidance steering behavior, which can be somewhat similar in implementation in this particular case). Edit: Maaaaybe also consider islanding if you need to parallelize processing of disjoint groups. I think that's more than enough in this use case.
  4. Ming-Lun "Allen" Chou

    Swing-Twist Interpolation (Sterp), An Alternative to Slerp

    I would say it depends on your intended look. As a general fallback, maybe align the twist axis with the direction in which the object's vertices are most spread out using techniques like PCA (principal component analysis), or simply the longest side of the object's OBB? As for the mechanical example, you gave a good example of where spliting the swing and twist portions in time is even more desirable. In this case, maybe a version of sterp that takes separate swing and twist interpolation parameters can be useful? Or if full control is needed, simply use the raw swing and twist from the decomposition function. public static Quaternion Sterp ( Quaternion a, Quaternion b, Vector3 twistAxis, float tSwing, float tTwist ) { Quaternion deltaRotation = b * Quaternion.Inverse(a); Quaternion swingFull; Quaternion twistFull; QuaternionUtil.DecomposeSwingTwist ( deltaRotation, twistAxis, out swingFull, out twistFull ); Quaternion swing = Quaternion.Slerp(Quaternion.identity, swingFull, tSwing); Quaternion twist = Quaternion.Slerp(Quaternion.identity, twistFull, tTwist); return twist * swing; }
  5. Here is the original blog post. Edit: Sorry, I can't get embedded LaTeX to display properly. The pinned tutorial post says I have to do it in plain HTML without embedded images? I actually tried embedding pre-rendered equations and they seemed fine when editing, but once I submit the post it just turned into a huge mess. So...until I can find a proper way to fix this, please refer to the original blog post for formatted formulas. I've replaced the original LaTex mess in this post with something at least more readable. Any advice on fixing this is appreciated. This post is part of my Game Math Series. Source files are on GitHub. Shortcut to sterp implementation. Shortcut to code used to generate animations in this post. An Alternative to Slerp Slerp, spherical linear interpolation, is an operation that interpolates from one orientation to another, using a rotational axis paired with the smallest angle possible. Quick note: Jonathan Blow explains here how you should avoid using slerp, if normalized quaternion linear interpolation (nlerp) suffices. Long store short, nlerp is faster but does not maintain constant angular velocity, while slerp is slower but maintains constant angular velocity; use nlerp if you’re interpolating across small angles or you don’t care about constant angular velocity; use slerp if you’re interpolating across large angles and you care about constant angular velocity. But for the sake of using a more commonly known and used building block, the remaining post will only mention slerp. Replacing all following occurrences of slerp with nlerp would not change the validity of this post. In general, slerp is considered superior over interpolating individual components of Euler angles, as the latter method usually yields orientational sways. But, sometimes slerp might not be ideal. Look at the image below showing two different orientations of a rod. On the left is one orientation, and on the right is the resulting orientation of rotating around the axis shown as a cyan arrow, where the pivot is at one end of the rod. If we slerp between the two orientations, this is what we get: Mathematically, slerp takes the “shortest rotational path”. The quaternion representing the rod’s orientation travels along the shortest arc on a 4D hyper sphere. But, given the rod’s elongated appearance, the rod’s moving end seems to be deviating from the shortest arc on a 3D sphere. My intended effect here is for the rod’s moving end to travel along the shortest arc in 3D, like this: The difference is more obvious if we compare them side-by-side: This is where swing-twist decomposition comes in. Swing-Twist Decomposition Swing-Twist decomposition is an operation that splits a rotation into two concatenated rotations, swing and twist. Given a twist axis, we would like to separate out the portion of a rotation that contributes to the twist around this axis, and what’s left behind is the remaining swing portion. There are multiple ways to derive the formulas, but this particular one by Michaele Norel seems to be the most elegant and efficient, and it’s the only one I’ve come across that does not involve any use of trigonometry functions. I will first show the formulas now and then paraphrase his proof later: Given a rotation represented by a quaternion R = [W_R, vec{V_R}] and a twist axis vec{V_T}, combine the scalar part from R the projection of vec{V_R} onto vec{V_T} to form a new quaternion: T = [W_R, proj_{vec{V_T}}(vec{V_R})]. We want to decompose R into a swing component and a twist component. Let the S denote the swing component, so we can write R = ST. The swing component is then calculated by multiplying R with the inverse (conjugate) of T: S= R T^{-1} Beware that S and T are not yet normalized at this point. It's a good idea to normalize them before use, as unit quaternions are just cuter. Below is my code implementation of swing-twist decomposition. Note that it also takes care of the singularity that occurs when the rotation to be decomposed represents a 180-degree rotation. public static void DecomposeSwingTwist ( Quaternion q, Vector3 twistAxis, out Quaternion swing, out Quaternion twist ) { Vector3 r = new Vector3(q.x, q.y, q.z); // singularity: rotation by 180 degree if (r.sqrMagnitude < MathUtil.Epsilon) { Vector3 rotatedTwistAxis = q * twistAxis; Vector3 swingAxis = Vector3.Cross(twistAxis, rotatedTwistAxis); if (swingAxis.sqrMagnitude > MathUtil.Epsilon) { float swingAngle = Vector3.Angle(twistAxis, rotatedTwistAxis); swing = Quaternion.AngleAxis(swingAngle, swingAxis); } else { // more singularity: // rotation axis parallel to twist axis swing = Quaternion.identity; // no swing } // always twist 180 degree on singularity twist = Quaternion.AngleAxis(180.0f, twistAxis); return; } // meat of swing-twist decomposition Vector3 p = Vector3.Project(r, twistAxis); twist = new Quaternion(p.x, p.y, p.z, q.w); twist = Normalize(twist); swing = q * Quaternion.Inverse(twist); } Now that we have the means to decompose a rotation into swing and twist components, we need a way to use them to interpolate the rod’s orientation, replacing slerp. Swing-Twist Interpolation Replacing slerp with the swing and twist components is actually pretty straightforward. Let the Q_0 and Q_1 denote the quaternions representing the rod's two orientations we are interpolating between. Given the interpolation parameter t, we use it to find "fractions" of swing and twist components and combine them together. Such fractiona can be obtained by performing slerp from the identity quaternion, Q_I, to the individual components. So we replace: Slerp(Q_0, Q_1, t) with: Slerp(Q_I, S, t) Slerp(Q_I, T, t) From the rod example, we choose the twist axis to align with the rod's longest side. Let's look at the effect of the individual components Slerp(Q_I, S, t) and Slerp(Q_I, T, t) as t varies over time below, swing on left and twist on right: And as we concatenate these two components together, we get a swing-twist interpolation that rotates the rod such that its moving end travels in the shortest arc in 3D. Again, here is a side-by-side comparison of slerp (left) and swing-twist interpolation (right): I decided to name my swing-twist interpolation function sterp. I think it’s cool because it sounds like it belongs to the function family of lerp and slerp. Here’s to hoping that this name catches on. And here’s my code implementation: public static Quaternion Sterp ( Quaternion a, Quaternion b, Vector3 twistAxis, float t ) { Quaternion deltaRotation = b * Quaternion.Inverse(a); Quaternion swingFull; Quaternion twistFull; QuaternionUtil.DecomposeSwingTwist ( deltaRotation, twistAxis, out swingFull, out twistFull ); Quaternion swing = Quaternion.Slerp(Quaternion.identity, swingFull, t); Quaternion twist = Quaternion.Slerp(Quaternion.identity, twistFull, t); return twist * swing; } Proof Lastly, let’s look at the proof for the swing-twist decomposition formulas. All that needs to be proven is that the swing component S does not contribute to any rotation around the twist axis, i.e. the rotational axis of S is orthogonal to the twist axis. Let vec{V_{R_para}} denote the parallel component of vec{V_R} to vec{V_T}, which can be obtained by projecting vec{V_R} onto vec{V_T}: vec{V_{R_para}} = proj_{vec{V_T}}(vec{V_R}) Let vec{V_{R_perp}} denote the orthogonal component of vec{V_R} to vec{V_T}: vec{V_{R_perp}} = vec{V_R} - vec{V_{R_para}} So the scalar-vector form of T becomes: T = [W_R, proj_{vec{V_T}}(vec{V_R})] = [W_R, vec{V_{R_para}}] Using the quaternion multiplication formula, here is the scalar-vector form of the swing quaternion: S = R T^{-1} = [W_R, vec{V_R}] [W_R, -vec{V_{R_para}}] = [W_R^2 - vec{V_R} ‧ (-vec{V_{R_para}}), vec{V_R} X (-vec{V_{R_para}}) + W_R vec{V_R} + W_R (-vec{V_{R_para}})] = [W_R^2 - vec{V_R} ‧ (-vec{V_{R_para}}), vec{V_R} X (-vec{V_{R_para}}) + W_R (vec{V_R} -vec{V_{R_para}})] = [W_R^2 - vec{V_R} ‧ (-vec{V_{R_para}}), vec{V_R} X (-vec{V_{R_para}}) + W_R vec{V_{R_perp}}] Take notice of the vector part of the result: vec{V_R} X (-vec{V_{R_para}}) + W_R vec{V_{R_perp}} This is a vector parallel to the rotational axis of S. Both vec{V_R} X(-vec{V_{R_para}}) and vec{V_{R_perp}} are orthogonal to the twist axis vec{V_T}, so we have shown that the rotational axis of S is orthogonal to the twist axis. Hence, we have proven that the formulas for S and T are valid for swing-twist decomposition. Conclusion That’s all. Given a twist axis, I have shown how to decompose a rotation into a swing component and a twist component. Such decomposition can be used for swing-twist interpolation, an alternative to slerp that interpolates between two orientations, which can be useful if you’d like some point on a rotating object to travel along the shortest arc. I like to call such interpolation sterp. Sterp is merely an alternative to slerp, not a replacement. Also, slerp is definitely more efficient than sterp. Most of the time slerp should work just fine, but if you find unwanted orientational sway on an object’s moving end, you might want to give sterp a try.
  6. Ming-Lun "Allen" Chou

    A Brain Dump of What I Worked on for Uncharted 4

    Done.
  7. This post is part of My Career Series. Now that Uncharted 4 is released, I am able to talk about what I worked on for the project. I mostly worked on AI for single-player buddies and multiplayer sidekicks, as well as some gameplay logic. I’m leaving out things that never went in to the final game and some minor things that are too verbose to elaborate on. So here it goes: The Post System Before I start, I’d like to mention the post system we used for NPCs. I did not work on the core logic of the system; I helped writing some client code that makes use of this system. Posts are discrete positions within navigable space, mostly generated from tools and some hand-placed by designers. Based on our needs, we created various post selectors that rate posts differently (e.g. stealth post selector, combat post selector), and we pick the highest-rated post to tell an NPC to go to. Buddy Follow The buddy follow system was derived from The Last of Us. The basic idea is that buddies pick positions around the player to follow. These potential positions are fanned out from the player, and must satisfy the following linear path clearance tests: player to position, position to a forward-projected position, forward-projected position to the player. Climbing is something present in Uncharted 4 that is not in The Last of Us. To incorporate climbing into the follow system, we added the climb follow post selector that picks climb posts for buddies to move to when the player is climbing. It turned out to be trickier than we thought. Simply telling buddies to use regular follow logic when the player is not climbing, and telling them to use climb posts when the player is climbing, is not enough. If the player quickly switch between climbing and non-climbing states, buddies would oscillate pretty badly between the two states. So we added some hysteresis, where the buddies only switch states when the player has switched states and moved far enough while maintaining in that state. In general, hysteresis is a good idea to avoid behavioral flickering. Buddy Lead In some scenarios in the game, we wanted buddies to lead the way for the player. The lead system is ported over from The Last of Us and updated, where designers used splines to mark down the general paths we wanted buddies to follow while leading the player. In case of multiple lead paths through a level, designers would place multiple splines and turned them on and off via script. The player’s position is projected onto the spline, and a lead reference point is placed ahead by a distance adjustable by designers. When this lead reference point passes a spline control point marked as a wait point, the buddy would go to the next wait point. If the player backtracks, the buddy would only backtrack when the lead reference point gets too far away from the furthest wait point passed during last advancement. This, again, is hysteresis added to avoid behavioral flickering. We also incorporated dynamic movement speed into the lead system. “Speed planes” are placed along the spline, based on the distance between the buddy and the player along the spline. There are three motion types NPCs can move in: walk, run, and sprint. Depending on which speed plane the player hits, the buddy picks an appropriate motion type to maintain distance away from the player. Designers can turn on and off speed planes as they see fit. Also, the buddy’s locomotion animation speed is slightly scaled up or down based on the player’s distance to minimize abrupt movement speed change when switching motion types. Buddy Cover Share In The Last of Us, the player is able to move past a buddy while both remain in cover. This is called cover share. In The Last of Us, it makes sense for Joel to reach out to the cover wall over Ellie and Tess, who have smaller profile than Joel. But we thought that it wouldn’t look as good for Nate, Sam, Sully, and Elena, as they all have similar profiles. Plus, Uncharted 4 is much faster-paced, and having Nate reach out his arms while moving in cover would break the fluidity of the movement. So instead, we decided to simply make buddies hunker against the cover wall and have Nate steer slightly around them. The logic we used is very simple. If the projected player position based on velocity lands within a rectangular boundary around the buddy’s cover post, the buddy aborts current in-cover behavior and quickly hunkers against the cover wall. Medic Sidekicks Medic sidekicks in multiplayer required a whole new behavior that is not present in single-player: reviving downed allies and mirroring the player’s cover behaviors. Medics try to mimic the player’s cover behavior, and stay as close to the player as possible, so when the player is downed, they are close by to revive the player. If a nearby ally is downed, they would also revive the ally, given that the player is not already downed. If the player is equipped with the RevivePak mod for medics, they would try to throw RevivePaks at revive targets before running to the targets for revival (multiple active revivals reduce revival time); throwing RevivePaks reuses the grenade logic for trajectory clearance test and animation playback, except that grenades were swapped out with RevivePaks. Stealth Grass Crouch-moving in stealth grass is also something new in Uncharted 4. For it to work, we need to somehow mark the environment, so that the player gameplay logic knows whether the player is in stealth grass. Originally, we thought about making the background artists responsible of marking collision surfaces as stealth grass in Maya, but found out that necessary communication between artists and designers made iteration time too long. So we arrived at a different approach to mark down stealth grass regions. An extra stealth grass tag is added for designers in the editor, so they could mark the nav polys that they’d like the player to treat as stealth grass, with high precision. With this extra information, we can also rate stealth posts based on whether they are in stealth grass or not. This is useful for buddies moving with the player in stealth. Perception Since we don’t have listen mode in Uncharted 4 like The Last of Us, we needed to do something to make the player aware of imminent threats, so the player doesn’t feel overwhelmed by unknown enemy locations. Using the enemy perception data, we added the colored threat indicators that inform the player when an enemy is about to notice him/her as a distraction (white), to perceive a distraction (yellow), and to acquire full awareness (orange). We also made the threat indicator raise a buzzing background noise to build up tension and set off a loud stinger when an enemy becomes fully aware of the player, similar to The Last of Us. Investigation This is the last major gameplay feature I took part in on before going gold. I don’t usually go to formal meetings at Naughty Dog, but for the last few months before gold, we had a at least one meeting per week driven by Bruce Straley or Neil Druckmann, focusing on the AI aspect of the game. Almost after every one of these meetings, there was something to be changed and iterated for the investigation system. We went through many iterations before arriving at what we shipped with the final game. There are two things that create distractions and would cause enemies to investigate: player presence and dead bodies. When an enemy registers a distraction (distraction spotter), he would try to get a nearby ally to investigate with him as a pair. The closer one to the distraction becomes the investigator, and the other becomes the watcher. The distraction spotter can become an investigator or a watcher, and we set up different dialog sets for both scenarios (“There’s something over there. I’ll check it out.” versus “There’s something over there. You go check it out.”). In order to make the start and end of investigation look more natural, we staggered the timing of enemy movement and the fading of threat indicators, so the investigation pair don’t perform the exact same action at the same time in a mechanical fashion. If the distraction is a dead body, the investigator would be alerted of player presence and tell everyone else to start searching for the player, irreversibly leaving ambient/unaware state. The dead body discovered would also be highlighted, so the player gets a chance to know what gave him/her away. Under certain difficulties, consecutive investigations would make enemies investigate more aggressively, having a better chance of spotting the player hidden in stealth grass. In crushing difficulty, enemies always investigate aggressively. Dialog Looks This is also among the last few things I helped out with for this project. Dialog looks refers to the logic that makes characters react to conversations, such as looking at the other people and hand gestures. Previously in The Last of Us, people spent months annotating all in-game scripted dialogs with looks and gestures by hand. This was something we didn’t want to do again. We had some scripted dialogs that are already annotated by hand, but we needed a default system that handles dialogs that are not annotated. The animators are given parameters to adjust the head turn speed, max head turn angle, look duration, cool down time, etc. Jeep Momentum Maintenance One of the problems we had early on regarding the jeep driving section in the Madagascar city level, is that the player’s jeep can easily spin out and lose momentum after hitting a wall or an enemy vehicle, throwing the player far behind the convoy and failing the level. My solution was to temporarily cap the angular velocity and change of linear velocity direction upon impact against walls and enemy vehicles. This easy solution turns out pretty effective, making it much harder for players to fail the level due to spin-outs. Vehicle Deaths Driveable vehicles are first introduced in Uncharted 4. Previously, only NPCs can drive vehicles, and those vehicles are constrained to spline rails. I helped handling vehicle deaths. There are multiple ways to kill enemy vehicles: kill the driver, shoot the vehicle enough times, bump into an enemy bike with your jeep, and ram your jeep into an enemy jeep to cause a spin-out. Based on various causes of death, a death animation is picked to play for the dead vehicle and all its passengers. The animation blends into physics-controlled ragdolls, so the death animation smoothly transitions into physically simulated wreckage. For bumped deaths of enemy bikes, we used the bike’s bounding box on the XZ plane and the contact position to determine which one of the four directional bump death animations to play. As for jeep spin-outs, the jeep’s rotational deviation from desired driving direction is tested against a spin-out threshold. When playing death animations, there’s a chance that the dead vehicle can penetrate walls. A sphere cast is used, from the vehicle’s ideal position along the rail if it weren’t dead, to where the vehicle’s body actually is. If a contact is generated from the sphere cast, the vehicle is shifted in the direction of the contact normal by a fraction of penetration amount, so the de-penetration happens gradually across multiple frames, avoiding positional pops. We made a special type of vehicle death, called vehicle death hint. They are context-sensitive death animations that interact with environments. Animators and designers place these hints along the spline rail, and specify entry windows on the splines. If a vehicle is killed within an entry window, it starts playing the corresponding special death animation. This feature started off as a tool to implement the specific epic jeep kill in the 2015 E3 demo. Bayer Matrix for Dithering We wanted to eliminate geometry clipping the camera when the camera gets too close to environmental objects, mostly foliage. So we decided to fade out pixels in pixel shaders based on how close the pixels are to the camera. Using transparency was not an option, because transparency is not cheap, and there’s just too much foliage. Instead, we went with dithering, combining a pixel’s distance from the camera and a patterned Bayer matrix, some portion of the pixels are fully discarded, creating an illusion of transparency. Our original Bayer matrix was an 8×8 matrix shown on this Wikipedia page. I thought it was too small and resulted in banding artifacts. I wanted to use a 16×16 Bayer matrix, but it was no where to be found on the internet. So I tried to reverse engineer the pattern of the 8×8 Bayer matrix and noticed a recursive pattern. I would have been able to just use pure inspection to write out a 16×16 matrix by hand, but I wanted to have more fun and wrote a tool that can generate Bayer matrices sized any powers of 2. After switching to the 16×16 Bayer matrix, there was a noticeable improvement on banding artifacts. Explosion Sound Delay This is a really minor contribution, but I’d still like to mention it. A couple weeks before the 2015 E3 demo, I pointed out that the tower explosion was seen and heard simultaneously and that didn’t make sense. Nate and Sully are very far away from the tower, they should have seen and explosion first and then heard it shortly after. The art team added a slight delay to the explosion sound into the final demo. Traditional Chinese Localization I didn’t switch to Traditional Chinese text and subtitles until two weeks before we were locking down for gold, and I found some translation errors. Most of the errors were literal translations from English to Traditional Chinese and just did’t work in the contexts. I did not think I would have time to play through the entire game myself and look out for translation errors simultaneously. So I asked multiple people from QA to play through different chapters of the game in Traditional Chinese, and I went over the recorded gameplay videos as they became available. This proved pretty efficient; I managed to log all the translation errors I found, and the localization team was able to correct them before the deadline. That’s It These are pretty much the things I worked on for Uncharted 4 that are worth mentioning. I hope you enjoyed reading it.
  8. Ming-Lun "Allen" Chou

    2D Lighting System in Monogame

  9. Ming-Lun "Allen" Chou

    A Brain Dump of What I Worked on for Uncharted 4

      Yes please, make it an article!  At least an overview pointing to the original if nothing else.  This post will get lost in all the complaining about Unity. Sure. I just submitted it as an article.
  10.   Original blog post   This post is part of My Career Series.   Now that Uncharted 4 is released, I am able to talk about what I worked on for the project. I mostly worked on AI for single-player buddies and multiplayer sidekicks, as well as some gameplay logic. I'm leaving out things that never went in to the final game and some minor things that are too verbose to elaborate on. So here it goes:     The Post System   Before I start, I'd like to mention the post system we used for NPCs. I did not work on the core logic of the system; I wrote client code that makes use of this system.Posts are discrete positions within navigable space, mostly generated from tools and some hand-placed by designers. Based on our needs, we created various post selectors that rate posts differently (e.g. stealth post selector, combat post selector), and we pick the highest-rated post to tell an NPC to go to.       Buddy Follow   The buddy follow system was derived from The Last of Us.The basic idea is that buddies pick positions around the player to follow. These potential positions are fanned out from the player, and must satisfy the following linear path clearance tests: player to position, position to a forward-projected position, forward-projected position to the player.     Climbing is something present in Uncharted 4 that is not in The Last of Us. To incorporate climbing into the follow system, I added the climb follow post selector that picks climb posts for buddies to move to when the player is climbing.     It turned out to be trickier than I thought. Simply telling buddies to use regular follow logic when the player is not climbing, and telling them to use climb posts when the player is climbing, is not enough. If the player quickly switch between climbing and non-climbing states, buddies would oscillate pretty badly between the two states. So I added some hysteresis, where the buddies only switch states when the player has switched states and moved far enough while maintaining in that state. In general, hysteresis is a good idea to avoid behavioral flickering.     Buddy Lead   In some scenarios in the game, we wanted buddies to lead the way for the player. I ported over and updated the lead system from The Last of Us, where designers used splines to mark down the general paths we wanted buddies to follow while leading the player.     In case of multiple lead paths through a level, designers would place multiple splines and turned them on and off via script.     The player's position is projected onto the spline, and a lead reference point is placed ahead by a distance adjustable by designers. When this lead reference point passes a spline control point marked as a wait point, the buddy would go to the next wait point. If the player backtracks, the buddy would only backtrack when the lead reference point gets too far away from the furthest wait point passed during last advancement. This, again, is hysteresis added to avoid behavioral flickering.   I also incorporated dynamic movement speed into the lead system. "Speed planes" are placed along the spline, based on the distance between the buddy and the player along the spline. There are three motion types NPCs can move in: walk, run, and sprint. Depending on which speed plane the player hits, the buddy picks an appropriate motion type to maintain distance away from the player. Designers can turn on and off speed planes as they see fit. Also, the buddy's locomotion animation speed is slightly scaled up or down based on the player's distance to minimize abrupt movement speed change when switching motion types.       Buddy Cover Share   In The Last of Us, the player is able to move past a buddy while both remain in cover. This is called cover share.     In The Last of Us, it makes sense for Joel to reach out to the cover wall over Ellie and Tess, who have smaller profile than Joel. But we thought that it wouldn't look as good for Nate, Sam, Sully, and Elena, as they all have similar profiles. Plus, Uncharted 4 is much faster-paced, and having Nate reach out his arms while moving in cover would break the fluidity of the movement. So instead, we decided to simply make buddies hunker against the cover wall and have Nate steer slightly around them.     The logic I used is very simple. If the projected player position based on velocity lands within a rectangular boundary around the buddy's cover post, the buddy aborts current in-cover behavior and quickly hunkers against the cover wall.       Medic Sidekicks     I was in charge of multiplayer sidekicks, and I'd say medics are the most special among all. Medic sidekicks in multiplayer require a whole new behavior that is not present in single-player: reviving downed allies and mirroring the player's cover behaviors.     Medics try to mimic the player's cover behavior, and stay as close to the player as possible, so when the player is downed, they are close by to revive the player. If a nearby ally is downed, they would also revive the ally, given that the player is not already downed. If the player is equipped with the RevivePak mod for medics, they would try to throw RevivePaks at revive targets before running to the targets for revival; throwing RevivePaks reuses the grenade logic for trajectory clearance test and animation playback, except that I swapped out the grenades with RevivePaks.       Stealth Grass     Crouch-moving in stealth grass is also something new in Uncharted 4. For it to work, we need to somehow mark the environment, so that the player gameplay logic knows whether the player is in stealth grass. Originally, we thought about making the background artists responsible of marking collision surfaces as stealth grass in Maya, but found out that necessary communication between artists and designers made iteration time too long. So we arrived at a different approach to mark down stealth grass regions. I added an extra stealth grass tag for designers in the editor, so they could mark the nav polys that they'd like the player to treat as stealth grass, with high precision. With this extra information, we can also rate stealth posts based on whether they are in stealth grass or not. This is useful for buddies moving with the player in stealth.       Perception     Since we don't have listen mode in Uncharted 4 like The Last of Us, we needed to do something to make the player aware of imminent threats, so the player doesn't feel overwhelmed by unknown enemy locations. Using the enemy perception data, I added the colored threat indicators that inform the player when an enemy is about to notice him/her as a distraction (white), to perceive a distraction (yellow), and to acquire full awareness (orange). I also made the threat indicator raise a buzzing background noise to build up tension and set off a loud stinger when an enemy becomes fully aware of the player, similar to The Last of Us.       Investigation   This is the last major gameplay feature I worked on before going gold. I don't usually go to formal meetings at Naughty Dog, but for the last few months before gold, we had a at least one meeting per week driven by Bruce Straley or Neil Druckmann, focusing on the AI aspect of the game. Almost after every one of these meetings, there was something to be changed and iterated for the investigation system. I went through many iterations before arriving at what we shipped with the final game.   There are two things that create distractions and would cause enemies to investigate: player presence and dead bodies. When an enemy registers a distraction (distraction spotter), he would try to get a nearby ally to investigate with him as a pair. The closer one to the distraction becomes the investigator, and the other becomes the watcher. The distraction spotter can become an investigator or a watcher, and we set up different dialog sets for both scenarios ("There's something over there. I'll check it out." versus "There's something over there. You go check it out.").   In order to make the start and end of investigation look more natural, I staggered the timing of enemy movement and the fading of threat indicators, so the investigation pair don't perform the exact same action at the same time in a mechanical fashion.     If the distraction is a dead body, the investigator would be alerted of player presence and tell everyone else to start searching for the player, irreversibly leaving ambient/unaware state. The dead body discovered would also be highlighted, so the player gets a chance to know what gave him/her away.     Under certain difficulties, consecutive investigations would make enemies investigate more aggressively, having a better chance of spotting the player hidden in stealth grass. In crushing difficulty, enemies always investigate aggressively.     Dialog Looks   This is also among the last few things I worked on for this project.Dialog looks refers to the logic that makes characters react to conversations, such as looking at the other people and hand gestures. Previously in The Last of Us, people spent months annotating all in-game scripted dialogs with looks and gestures by hand. This was something we didn't want to do again. We had some scripted dialogs that are already annotated by hand, but we needed a default system that handles dialogs that are not annotated, which I put together. The animators are given parameters to adjust the head turn speed, max head turn angle, look duration, cool down time, etc.       Jeep Momentum Maintenance   One of the problems we had early on regarding the jeep driving section in the Madagascar city level, is that the player's jeep can easily spin out and lose momentum after hitting a wall or an enemy vehicle, throwing the player far behind the convoy and failing the level.   My solution was to temporarily cap the angular velocity and change of linear velocity direction upon impact against walls and enemy vehicles. This easy solution turns out pretty effective, making it much harder for players to fail the level due to spin-outs.       Vehicle Deaths   Driveable vehicles are first introduced in Uncharted 4. Previously, only NPCs can drive vehicles, and those vehicles are constrained to spline rails. I was in charge of handling vehicle deaths.There are multiple ways to kill enemy vehicles: kill the driver, shoot the vehicle enough times, bump into an enemy bike with your jeep, and ram your jeep into an enemy jeep to cause a spin-out. Based on various causes of death, a death animation is picked to play for the dead vehicle and all its passengers. The animation blends into physics-controlled ragdolls, so the death animation smoothly transitions into physically simulated wreckage.     For bumped deaths of enemy bikes, I used the bike's bounding box on the XZ plane and the contact position to determine which one of the four directional bump death animations to play.     As for jeep spin-outs, I test the jeep's rotational deviation from desired driving direction against a spin-out threshold.     When playing death animations, there's a chance that the dead vehicle can penetrate walls. I used a sphere cast, from the vehicle's ideal position along the rail if it weren't dead, to where the vehicle's body actually is. If a contact is generated from the sphere cast, I shifted the vehicle in the direction of the contact normal by a fraction of penetration amount, so the de-penetratiton happens gradually across multiple frames, avoiding positional pops.     I did a special type of vehicle death, called vehicle death hint. They are context-sensitive death animations that interact with environments. Animators and designers place these hints along the spline rail, and specify entry windows on the splines. If a vehicle is killed within an entry window, it starts playing the corresponding special death animation. This feature started off as a tool to implement the specific epic jeep kill in the 2015 E3 demo.     Bayer Matrix for Dithering   We wanted to eliminate geometry clipping the camera when the camera gets too close to environmental objects, mostly foliage. So we decided to fade out pixels in pixel shaders based on how close the pixels are to the camera. Using transparency was not an option, because transparency is not cheap, and there's just too much foliage. Instead, we went with dithering, combining a pixel's distance from the camera and a patterned Bayer matrix, some portion of the pixels are fully discarded, creating an illusion of transparency.     Our original Bayer matrix was an 8x8 matrix shown on this Wikipedia page. I thought it was too small and resulted in banding artifacts. I wanted to use a 16x16 Bayer matrix, but it was no where to be found on the internet. So I tried to reverse engineer the pattern of the 8x8 Bayer matrix and noticed a recursive pattern. I would have been able to just use pure inspection to write out a 16x16 matrix by hand, but I wanted to have more fun and wrote a tool that can generate Bayer matrices sized any powers of 2.     After switching to the 16x16 Bayer matrix, there was a noticeable improvement on banding artifacts.       Explosion Sound Delay   This is a really minor contribution, but I'd still like to mention it. A couple weeks before the 2015 E3 demo, I pointed out that the tower explosion was seen and heard simultaneously and that didn't make sense. Nate and Sully are very far away from the tower, they should have seen and explosion first and then heard it shortly after. The art team added a slight delay to the explosion sound into the final demo.     Traditional Chinese Localization   I didn't switch to Traditional Chinese text and subtitles until two weeks before we were locking down for gold, and I found some translation errors. Most of the errors were literal translations from English to Traditional Chinese and just did't work in the contexts. I did not think I would have time to play through the entire game myself and look out for translation errors simultaneously. So I asked multiple people from QA to play through different chapters of the game in Traditional Chinese, and I went over the recorded gameplay videos as they became available. This proved pretty efficient; I managed to log all the translation errors I found, and the localization team was able to correct them before the deadline.     That's It   These are pretty much the things I worked on for Uncharted 4 that are worth mentioning. I hope you enjoyed reading it. :)
  11. Here is the original blog post. This post is part of My Career Series.   Note: This post was written before Uncharted 4 went gold, so it might contain tones or implications that Uncharted 4 hasn’t gone gold yet. Sorry for the confusion.   I started working on Uncharted 4: A Thief’s End almost two years ago, and here we are, less than two months before release. This would be my first shipped title as a full-time game programmer (I shipped Planetary Annihilation during a summer internship). Looking back now, I realized that I’ve really come a long way since I first wanted to make games more than a decade ago. I would like to take this opportunity to write down this journey to share with you and as a note for myself.     I Wanted to Work at A Game Store   My first contact with video games was when my dad got me an original Game Boy as a present while I was in kindergarten. My only two games were Super Mario Land and Tetris. That’s when I got hooked on video games. Later, I saw my cousins getting a Super Nintendo (SNES) when I was in 2nd grade. I went over and played with them pretty frequently, but we had to take turns as the SNES only has two controllers. After bugging my parents, I finally got my own SNES to play with. My favorite games were the Super Bomberman series. I even went and got all of the Bomberman games on the Game Boy.   In 4th grade, one of my friends brought over his Nintendo 64 (N64) and Super Mario 64; that was my first time playing a 3D game and it blew my mind. My friend and I made a deal where I would buy games slightly more frequently than he would, and we took turns owning the N64 and the games every couple months.   Around this time, when asked what I wanted to do in the future, I would say that I wanted to work at a game store so that “I could play video games all-day during work.” This all changed when, in 5th grade, my homeroom teacher brought a PlayStation (PS1) to school to let us play while we waited for our parents to pick us up after school. One day, as we watched in awe as he showed off how good he was at playing games, he said:   “You know what’s more impressive than being good at playing games? Making games.”   That, was when I decided that I wanted to make video games.     My Pre-Programming Phase   Back then, I knew of almost no resources on how to make video games. The best thing I was able to do was make very basic animations that reacted to mouse clicks in Macromedia Flash 3, which I learned in computer classes. In middle school, I picked up a 3D modeling software called TrueSpace and started experimenting with building simple character models, which I hoped would be someday used in a game (of course this didn’t happen).   When I started high school, I joined the Computer Research Club, in hopes of finally learning the technology behind making video games. On the first club lecture, I discovered that I did not like programming and preferred making game art; programming seemed daunting to me and not as visually attractive as art back then. So, I was detached from the programming aspect of game development for a while and focused on learning Photoshop and 3ds Max.   I was introduced to deviantART by a friend of mine in Canada. I started making and submitting art work to deviantART (both 2D & 3D) quite frequently; also, I picked up a lot of spoken English and internet slang along the way. After noticing some Flash games uploaded to deviantART, my interest in making games with Flash re-kindled; I gave another try at programming, and once I got through the steep initial learning curve, it didn’t seem as daunting as it had before. I started using Swift3D to render 3D models into Flash vector format to put in games. My most complete project was a bunny dancing game called “R-Squared de Dance!” which, unfortunately, was never fully finished and was lost. I did submit to deviantART a Valentine’s Day wallpaper with all 4 characters, though.     My First Contact with A Naughty Dog Game   One of my friends visited me and brought his PlayStation 2 (PS2) from the US, along with a copy of Jak and Daxter. The PS2 games sold in Taiwan were mostly Japanese titles; this was my first time seeing a PS2 title from the US. I only heard about Crash Bandicoot back in the PS1 days and didn’t know that it was developed by the same studio that made Jak and Daxter. Shortly after, during my sophomore year in high school, I got a PS2 because I couldn’t resist the temptation after hearing all of my friends talking about their PS2 games during lunch breaks.   During a summer break, my family went to visit some friends in California. I saw that their kids also had a PS2, with a whole collection of US games I’d never seen before. Intrigued, I asked them to bring me to a local game store. They brought me to a GameStop, and on the shelves I spotted a copy of Jak X: Combat Racing. That “weird-looking green-haired guy with an orange giant squirrel-like sidekick” instantly reminded me of my first sight of the original Jak and Daxter. I thought it looked interesting and decided to give it a try, so I picked up the game.   Jak X brought me a cinematic gaming sensation I had never experienced before. That was when Naughty Dog made a mark on me. I started having crazy thoughts about how amazing it would be if I could work at Naughty Dog. So there I was, staring at Naughty Dog’s website, clicking the tempting hyperlink that read “Want to join us? Click here!” A question popped up: “Are you still a student?” After clicking “yes”, I landed on a page that basically told me that Naughty Dog did not have opening for interns and “If you want to join us after graduation, you should pay more attention in math classes.” This, was the pivotal moment that made me adjust my attitudes towards math classes. Math became my favorite subject in high school, and I put a lot of effort in mastering vectors, matrices, geometry, statistics, combinatorics, and probability.   Fun fact: I tried programming a solver for linear systems of two variables in ActionScript, so that I could use it to do my math homework. I did not handle divions-by-zero, and when the computer told me the answers were NaN’s, I thought it was mocking me for being a noob, which has similar pronunciation in Chinese to NaN.   In my last high school semester, our Chinese teacher asked us to write a mock-up letter addressed to our dream company, be it real or fictional, and describe “why they should hire you.” I was the only person writing a letter to a foreign company which, of course, was Naughty Dog. Back then in Taiwan, working for a game company was generally frowned upon by parents and teachers, as video games were “what made kids bad.” However, I did have good grades, so my teacher did not give me a hard time for wanting to work at a game company.   And there came the nation-wide joint college entrance exam.     Addiction to Naughty Dog Games   I did pretty well in the exam, so I basically got to choose whichever college and whatever major I wanted. Determined to make games and becoming interested in programming again, I told my parents that I wanted to major in Computer Science. My dad, however, advised against that and suggested that I major in Electrical Engineering. He said that, as a pediatrician, he spent seven years in medical school learning everything besides pediatrics, and focused on pediatrics after becoming a medical intern; his argument was that I should not hop directly into focusing on what I was most interested in with tunnel vision, and should learn other related disciplines first, so that I could have a broader view.   My dad was pretty convincing, so I agreed; I chose Electrical Engineering and focused on hardware stuff, including electronics and integrated circuit design. Meanwhile, I still took some classes from the Computer Science department. Having a low-level understanding of hardware did make it easier for me to learn programming and computer architecture. For instance, I learned how to build computer memory from logic gates, and that helped me understand how memory access works. I also got to learn the gate-level design of full-adders and multipliers, hence their differences and why one is more computationally expensive than the other.   After my parents sent my sister to attend high school in the US, I remembered the fun I had with Jak X, so I asked my sister to send me copies of the Jak trilogy. As I went through the three games, witnessing the incredible work put into the game design and storytelling, I admired Naughty Dog even more and officially became addicted to their games. I went to Naughty Dog’s website once more, and saw the reveal trailer of their secret PlayStation 3 (PS3) project, later known to be Uncharted: Drake’s Fortune. I wasn’t very into shooters, “but it’s Naughty Dog, it’s got to be good.” So I picked up a copy of Uncharted when I visited my sister in the US during a summer break; knowing that the PS3 was not region-locked, I waited until I returned to Taiwan to get a PS3.   I played Uncharted. It was fun and technically impressive; I mean, look at the WATER on Drake’s pants! However, it didn’t give me the same charm as the Jak trilogy. To me, it felt like just another visually impressive action shooter with endless waves of enemies for target practice. So Naughty Dog dropped off my radar for a while.   Two years later (junior year), I saw the E3 live demo of Uncharted 2: Among Thieves. It completely blew me away. Did Drake just slide down and jump out of a COLLAPSING BUILDING, while IN-GAME? That sealed the deal. I got the game on release and powered through it; it was such an incredible game: stunning visuals, fun gameplay, awesome storytelling, and lovable characters. This was when I re-gained interest in Naughty Dog.   Then, I graduated from college.     Going Abroad & Joining The Kennel   Before I started my one-year mandatory military service, I applied for the undergrad program at a college focused on game development, called DigiPen Institute of Technology. I’ve already written about my story at DigiPen, so I’ll fast-forward a little bit. Uncharted 3: Drake’s Deception came out during my second semester at DigiPen. In spite of a few flaws in storytelling, I still thought the game was fantastic, just when I thought I couldn’t like Naughty Dog more.   Soon after, Naughty Dog released the reveal trailer for The Last of Us. This game completely caught me by surprise; a serious post-apocalyptic survival game is quite different from Uncharted’s lighthearted adventures. I thought it was a nice change of mood and appreciated that Naughty Dog was willing to try something different. At PAX Prime 2012, I went to Naughty Dog’s booth that showed a live demo of The Last of Us. The interior of the demo room was set up to look like the rundown hotel where Joel and Ellie fought the hunters. The demo itself was an impressive demonstration of hardcore gameplay, where Joel and Ellie fought for survival while out-numbered and out-gunned. Such harsh circumstances and pressure imposed on the player was a first among Naughty Dog games. After the demo, I got an Ellie T-shirt and lined up to get an autographed poster by Neil Druckmann and Bruce Straley.   I got a copy of the The Last of Us right upon release. Being able to emotionally connect to game characters is such a rare and beautiful experience. Ellie felt like a real companion, not just some emotionless sidekick controlled by AI. The rich interactions between Joel and Ellie made the story feel so alive; they fought together, they cared for each other, they shared jokes, and they experienced the same emotions together. Not many games had reached such level of compelling storytelling. I gave Naughty Dog my deepest admiration and respect, again.   When studying at DigiPen, I always had the slightest hope that some day I might end up working at Naughty Dog. After successfully landing an internship at Uber Entertainment and attending various career workshops at DigiPen, I was confident that I could get a job straight out of college. I had all these plans in my head: getting a job around the Seattle area where DigiPen is (perhaps Wargaming, ArenaNet, or Sucker Punch), working in the industry for a few years, applying for job at Naughty Dog, and then finally working there if I was lucky.   Little did I know that destiny would speed up this plan a little bit for me, where I came straight to Naughty Dog after graduating from DigiPen. You can read this story in detail here.   So here I am, working at my favorite studio, making Uncharted 4. As a huge Naughty Dog fan, I feel so honored to be working on the closing chapter of Nathan Drake’s adventure.   This has really been an uncharted journey.   After Uncharted 4 is released, I will write about what I have been working on since I started at Naughty Dog. Stay tuned.
  12. Ming-Lun "Allen" Chou

    DigiPen: The Game School I Went To

    Original Blog Post   Disclaimer: This post is all about my personal experience with DigiPen and is in no way intended to represent anyone else’s experience or opinions. I went to DigiPen Institute of Technology to learn how to make games in 2011, and graduated last year (2014). I graduated one year earlier than my fellow classmates in the same year, because I transferred in some credits I had already earned at my previous college in Taiwan. I have written one post about my life at DigiPen every year on a game design forum in Taiwan. Also, many of my DigiPen friends just graduated and have started their jobs in the game industry. So I thought, why not write a dedicated post about my experience at DigiPen in English on my blog?   Finding & Choosing DigiPen When I was almost done with my bachelor’s degree in Electrical Engineering at my first college in Taiwan, I blindly followed what most of my other peers did: looking for a master’s program in the US to advance further in academia. As I was combing through the overwhelming amount of resources on the internet over a few days, an idea deep in my mind struck me: I chose a program in Electrical Engineering because it had always been my dream to make games, and Electrical Engineering was the closest I could get in Taiwan (next to Computer Science). So why on earth was I blindly searching for a path confined within academia, just because everyone else was doing the same thing? After four years of college, I numbed my senses and got lost a little, forgetting my original dream. Hadn’t I played the Jak & Daxter trilogy and made Naughty Dog my dream company in high school? Stupid. Stupid. Stupid! So I threw away all my research on master’s programs, and simply started Googling “game school”. Several results turned up, and DigiPen was among them. I did some research and comparison on different curriculums and programs. As I learned about the vast number of various game-related courses there were, I became more and more convinced that a 2-year master’s program would not be long enough for what I wanted to learn. I ultimately chose DigiPen, which provides several 4-year undergrad programs, a learning environment exclusively for making games, and a large number of students in each year, which is a big enough pool to look for people to form a game team. This wasn’t an easy decision to share with my parents. One stereotype about Chinese parents is unfortunately true: many Chinese parents expect successful academic progression from their kids, so they encourage – sometimes even force – kids to pursue higher degrees in academia. As far as I know, going for a second bachelor’s degree after already having earned one was unheard of in my circle. Fortunately for me, my parents are very reasonable people. After confirming with me for probably the fifth time that I was determined to do this, they finally said: “If going to this game school is really what you want, then you have our full support.” And I am forever grateful for their generous support.   DigiPen Is A Very Hard School I will never forget the opening speech given by DigiPen’s president, Mr. Claude Comair, at the orientation. “Look to your left. Look to your right. You won’t be seeing at least one of the people you just saw when you graduate…or not.” This, as I learned later, is a very true statement, and he says it every year! Learning to make games at DigiPen is much more demanding than many people think. A quarter of freshmen can’t finish the first semester every year, and only about half of the students graduate on time; it’s worth mentioning, though, that some students choose to drop out because they have accepted job offers before finishing school. Students are expected to attend classes and finish assignments just like regular college students do. However, on top of that, students need to use their own free time to work on game projects with a team. There are two game projects in the freshman year (one per semester), and one game project per year after that. Students can opt to intern at game companies instead of participating in student game projects in the final year. Based on my experience, the things you learn from school, only account for 20% of the basic knowledge you need in the industry. What about the other 80%? You learn by forming study groups, conducting personal research and projects, attending club lectures, going to workshops, and last but not least, meeting with peers and professors. I learned about game physics and game engine architecture mostly through club lectures and research with peers.   Various Programs at DigiPen When I started at DigiPen, there were 5 major undergrad programs, listed below. DigiPen has since added several new programs, including two sound & music programs for games. Bachelor of Science in Real-Time Interactive Simulation (RTIS) This is basically a standard Computer Science program, plus extra courses focusing on game technology. The name of the program was changed during my sophomore year to Bachelor of Science in Computer Science in Real-Time Interactive Simulation, shortened BSCSRTIS, which is still quite a mouthful. Bachelor of Science in Game Design (BSGD) Game design techniques, focusing more on the technical side of game design, e.g. scripting, gameplay programming. Bachelor of Art in Game Design (BAGD) Similar to BSGD, but focusing more on the art side of game design, e.g. level design. Bachelor of Fine Arts (BFA) As the name suggests, game arts. Bachelor of Science in Computer Engineering (BSCE) Electrical engineering. Hardware stuff. I was an RTIS student, so I have a better understanding of the RTIS program.   Environment DigiPen is a 3-story building. On the first floor, there’s a cafeteria, some classrooms, including several bigger lecture halls, and a library (although not very large) full of books about making games (programming, art, game design, game history, you name it). You can also borrow games and various gaming hardwares from the library (for research purposes of course). On the second and third floors, there are more classrooms and the most important space of the school: the open lab. The open lab consists of a big open space with tables and hundreds of computers. Students can use these computers to work on their assignments and game projects. Most game teams would stake out team spaces and use them throughout a game project cycle. In my first two years at DigiPen, I went to school at 9 in the morning and left around 11 at night almost every day. When I wasn’t in a class, I would be sitting in my team space, working on assignments, game projects, or conducting research. Good times.   Game Projects Game projects account for special “game credits”. Throughout each project cycle, students have real milestones (Engine Proof, Prototype, First Playable, Alpha, Beta, and Gold), just like the industry. Upon each milestone, DigiPen’s game professors gather and sit through milestone presentations by every single team, usually non-stop throughout a couple days. Presentations are scored, and projects are also rated based on completion of Technical Certification Requirements (TCRs) and Design Certification Requirements (DCRs), all based on common industry standards. These are very solid practices for presentation skills. During my first milestone presentation, I was so nervous that I sweated and trembled ridiculously. During my last presentation, not to brag, I was as calm as a pro. We also learned to scope our games, as well as making the hard decision of cutting features before milestones. In order to let students get a better taste of the industry, students are allowed to jump from one team to another; on the other hand, teams can hire or fire students. Students also have the option to go solo. If the game professors decide that a student has spent too much time without a team or a solo project, they can fail the student for game credits. A game team can also fail game credits if their game ends up incomplete. A typical student game team consists of programmers from the RTIS program, a couple game designers from the BSGD or BAGD programs, some artists from the BFA program, and a producer. Producers have weekly meetings with game professors to learn production skills and discuss progress on the game projects. Game teams can schedule a “team-on-one” with one of the game professors. A team-on-one is a 4-hour session with a professor, where everyone sits down, eats snacks, and talks about the game project casually. This is sort of like a reality check for the game project and a good chance to fix communication problems within the team, utilizing various team exercises. After every session, I always felt like my mind had been refreshed and my motivation rebooted.   Clubs Unlike ordinary colleges, most of the clubs at DigiPen are either about playing games or making games: Board Game Club, Shooting Game Club, Fighting Game Club, Game Graphics Club, Game Physics Club, Game Engine Architecture Club, etc. Among them is a special club called the Playtesting Club. They hold playtesting sessions twice a week in the afternoon, setting up games on the computers in the open lab. Game teams can participate by putting up their games and let other students play. Playtesting sessions are valuable time spent in getting precious feedback on your game from fellow classmates. By the way, you can get a voucher for a free entree from the cafeteria if you playtest three games. Why wouldn’t you participate?   Integration with Industry DigiPen has a very tight relationship with the game industry. Many of the faculty are industry veterans; some are still in the industry and teaching at DigiPen part-time. Spring breaks and fall breaks are always aligned with the Game Developer Conference (GDC) and the Electronic Entertainment Expo (E3), so students and faculty are free to attend these important industry events. I cannot stress enough the importance of attending GDC. You can make professional connections there, and it is a great place for job hunting. My current job at Naughty Dog would not have been possible had I not run into Naughty Dog’s recruiter at GDC in 2013. I also write down some GDC social tips; if you’re interested, you can check them out here and here.   Career First If there’s one thing at DigiPen that is more important than preparing students for the industry, it is putting them into the industry. This is a general consensus among faculty. A student’s opportunity to break into the industry takes top priority. For instance, my on-site interview with Naughty Dog coincided with a midterm. My professor thought the interview was much more important than her midterm, so she let me go to the interview and take the midterm another day without penalty. I also missed some other classes that day, and all professors were totally fine with it.   Career Services Center In my opinion, the Career Services Center is one of the best resources DigiPen provides. You can schedule a meeting with a dedicated professional at the center. During the meeting, you can discuss how to write your resume, design your website and business cards, practice interviews, and so much more. I went to over 20 meetings before I finalized my resume, personal website, and business cards. When I had my phone interviews with Naughty Dog, they kindly let me borrow a meeting room. They also helped me draft a very professional-looking turn-down letter to a Microsoft offer I received. Almost every week, the Career Services Center would invite a game company over to the school’s biggest lecture hall for a “company day”. They would talk about the company and what they look for in job applicants. Sometimes, companies even hold interviews right on-campus! The school holds various workshops, some designed for current events. For instance, most DigiPen students are quite shy; in one of my years at DigiPen, a few weeks before GDC, where people get socialized and make connections with people from the industry, they invited some people from the industry and held a miniature mixer to let students practice having conversations with professional game developers. Every now and then, they also hold workshops focusing on self-presentation, helping students understand how to appear more professional with their social skills, resumes, websites, business cards. I really learned a lot of great tips from these workshops, including how to tailor resumes to specific companies, and what to look out during interviews. I recently learned that the school has started officially offering classes dedicated to professional communication taught by Sonia Michaels, including everything from resumes to business cards to professional networking and, of course, conference behavior. The Career Services Center is also responsible for DigiPen’s annual career fair, which is famous for being quite different from regular colleges. Instead of having students walking around company booths, students set up booths and recruiters walk around to hunt for prospective hires. It is not uncommon for a student to end up with multiple job offers after the career fair. The placement rate of the RTIS program in the past four years ranges from 84% to 90%, i.e. at least 8 out of 10 RTIS students graduated with a job offer already in hand in the past four years.   The End These are the things I have to say about DigiPen off the top of my head. I’ll end with a list of my friends from DigiPen, most of whom recently graduated and got jobs, in case you would like to follow them. Justin Cook (Website / Twitter) – Software Engineer at Respawn Entertainment Joe Lubertazzi (Website / Twitter) – Software Engineer at Respawn Entertainment Davis Standley (Twitter) – Game Designer at Respawn Entertainment Justin Maio (Website) – Game Programmer at Monolith John Hughes – Feel Engineer at thatgamecompany Garrett Woodford (Website / Twitter) – Software Engineer on Xbox Team Eric Lynum (Website) – Associate UI Engineer at Bungie Danny Frisbie (Twitter) – Production Engineer at Bungie Samir Patel (Twitter) – Producer at Bungie
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!