Posted on September 23rd, 2012 at 10:59 pm
I don’t finish most of the games that I play. I play a lot of games, and the vast majority don’t hold my interest for the time it takes to pull through to the end. So, when I actually do finish a game, it’s generally been a testament to how much I enjoyed it. However, L.A. Noire was not one of those games. In fact, I found myself trudging through the game with the distinct goal of making the whole thing go away.
While I played through L.A. Noire, I found that I quite enjoyed the process of searching around a crime scene, examining evidence, and slowly discovering the connections between clues and my suspects. And, while the interrogation options sometimes felt a little ambiguous, they easily made me feel as though I were playing out a detective show. The mechanics worked; it was Cole that was the problem.
Detective Cole Phelps first comes across as a by-the-book, stiff-backed, upstanding war veteran who is trying to bring justice to what he discovers to be a rather slimy city. He responds to cops with questionable morals and dirty men that slip by the system with slight indignation and annoyance, but he never does anything about it. What he does, and thus what the player does, is exactly by the book.
And yet, there’s a disconnect. Cole does exhibit passion, but at very odd times. Yelling at suspects that the player has already surmised to be innocent for example. He accuses obviously hapless witnesses of horrid crimes and then turns around and tries to comfort them in the same conversation.
The disjointedness of Cole’s interactions with other characters continues through to the entire plot, if you can call it that. The game is structured like a standard cop show, and like a cop show, individual “episodes” (cases) are distributed through various “seasons” (desks), and while those seasons may have individual story arcs, nothing really travels through to the next section of the game. The end of the Homicide desk is actually a lot of fun, and ends on a rather intense note. But then Cole is transferred to Vice to be partnered with a cop we already didn’t like, and the energy is completely sucked out of the game to start once again at zero.
To make matters worse, Cole dramatically fails to grow as a character throughout this rather arduous ordeal. The one moment weakness (and if you haven’t played the game by now, no you don’t get to chastise me for spoilers), when he suddenly decides that he doesn’t love his wife (who we’ve never met) and instead starts an affair with a singer (who was only briefly featured beforehand). My reaction to that whole thing was: “Wait, what? Why?” In all instances of cops practicing infidelity, Cole would scold them. He appeared to hold honor to the highest regard. In fact it was the only defining aspect of his character, and his sudden and seemingly random betrayal of what the player was told were his core principals totally ruin any limited connection felt with Cole up to that point.
The truly unfortunate part of the game is that as soon as Cole steps out, and his former squad mate, Jack Kelso, steps into the main roll for the last few hours of the game. Instead of stiff-backed, “morally superior” and randomly shouting Cole, Kelso’s stint as detective actually has an arc that feels believable. He uncovers a plot to defraud war vets, digs into it, gets attacked, fights back, and all the while he’s getting more and more frustrated and angry with the characters that he’s finding. His moral outrage feel real, where Cole’s felt hollow.
Though Kelso only had a fraction of the screen time that Cole did, he was far more relatable, and I care about him more. I cared because the way he reacted to the situations and characters he encountered felt real, and felt like they came from real emotions and motivations. The character and writing of Cole Phelps utterly failed to grasp that.
Posted on August 4th, 2012 at 12:24 pm
Alright, as I stated in my first post, I’m working on a (rather ambitious) combat engine that will let me play around with various control schemes and relationships painlessly and easily.
But first we need a guy to swing a sword.
Meet Rob. He’s going to be our testing character, likely for a good long while. Rob is built out of a collection of Unity GameObjects (the base in-game entity of Unity) in a specific hierarchy. Though there are significantly fewer points, the structure of Rob is loosely based on the animation rig of a standard bipedal creature. Thus, there is a single root object, to which the shoulders are attached, and then the hands. At some point in the far future, I want to be able to attach this system to a standard rigged character. If I’m thinking in terms of this structure now, I hopefully won’t have to deel with too many horrid surprises later on.
Rob’s sword was a free asset from the Unity Asset Store, made by Alexej Bodemer. The Asset Store is just another reason why Unity is such a good prototyping tool. While there aren’t scads of free assets, there are plenty to elevate an assortment of cubes into something more closely resembling what you’re developing.
Swinging A Sword
At this point in the project, I fully expect most of this code to be tossed out once I actually start building the system. What this phase does is ascertain precisely what variables and controls I will want to have.
At the moment, Rob’s hand is being moved directly from a start to ending position in code, with the sword attached. As I don’t necessarily know how many bones (or levels of hierarchy) there are going to be beween the character’s hand and his root, I’m setting the hand’s position as relative to the character’s root.
There were two significant challenges in getting the sword to swing correctly: getting the rotation to tween correctly and getting the position of the sword to be offset from the body.
Unity uses Quaternions for the rotations of objects. If you don’t know how they work, that’s okay, because unless you know your matrix math, they’re essentially black magic. In any case, I had a start rotation, or the orientation of the sword when Rob starts his swing, and an ending rotation, the orientation of the sword when the swing ends. Using the Quaternion object’s lerp() function, it’s quite easy to rotate the object smoothly from one to the other by the shortest path. The problem that immediately cropped up was that the sword did just that, by rotating through poor Rob’s body.
Here’s what was happening. The start and end orientations are such that the “shortest” distance between them (in terms of rotation) is actually the opposite of what I wanted.
My solution was to add an optional third “middle” rotation. For the first half of the swing, the sword rotates from the starting rotation to the middle rotation, and then from the middle to end in the second half. With this addition, the shortest rotation between each of the three points is the direction that I want it to rotate. This actually works better than I expected it to.
Without an offset from the body, a sword swing will look rather silly as it moves through the body in a line between start and finish. Some internet searching found two very effective equations for computing three dimensional bezier curves using either one or two control points.
Unity has great visual debug commands that let you trace lines, shapes, and control points to the screen, making the visualization of paths and the setting of positions and rotations very easy.
This is attached to a custom object editor that I created specifically for this bit of the project.
The object editor lets me set the positions and rotations for the starting, ending and middle points in the swing. It’s as easy as clicking a button, moving a control point in the Unity editor, and then clicking “done.” The slider lets me scrub to any point in that swing to see exactly how it looks. The editor also activates the controls for the bezier curve.
The code that was written for this was purely exploratory, and basically everything is going to be rewritten. That doesn’t mean it wasn’t useful though.
For example, I now know that for every independent body part that I want directly controlled by a sword swing, I’m going to need the following:
- Stance position and rotation
- Starting position and rotation
- Ending position and rotation
- Midpoint rotation
- One or two bezier control points
- How long it takes to go from the stance position to the start position
- How long it takes to go from the start position to the end position
- How long it takes to go from the end position back to the stance position
That’s a decent amount of information. I’m planning on breaking up each section of the swing (to start, slice, to stance) into separate “movement objects” that will each have the ability to have parabolic motion, halfway rotations, and individual times. That way, I can re-use the code when I go to make new motions such as blocking, punching, or kicking.
The next phase of the project is going to consist of mostly internal components that are going to be driving Rob’s motions and their respective editors. With any luck, I’ll be able to get it nearly to this same point soon, but with a more comprehensive backend, editors, and settings that don’t rely on values saved inside of a Unity level.
Posted on July 22nd, 2012 at 5:19 pm
This blog is being set up to document my various independent game projects as I work on them. I tend to have a small collection of side projects that each progress as I feel inspiration to work on them. Having a small collection of different projects means that I’m unlikely to find myself stuck on all of them and thus do no work at all.
The current project that is tickling my fancy is meant to be a flexible combat design tool. I enjoy working with combat systems, but one of the things I don’t like is the overhead required to get one working at the most basic level. Having to do that just to play with a concept or a control scheme is exceptionally irritating. Thus, the purpose of this project is to create a tool that will allow me to build a combat system relatively quickly, and then be able to expand and iterate on that system easily and painlessly with minimal code changes. If this works out, I may extend it to be able to work in an actual game environment.
Planning Out the Execution
I’m going to be working in Unity 3d. Unity is a great prototyping tool because of its very user-friendly editor and editor extensions, and it’s an environment that I’m quite comfortable in.
I don’t know precisely what the actual code structure of this system is going to be yet. Any seriously detailed plans I make at this point are going to be little more than educated guesses. For that reason, I’m going to start from the smallest bits of functionality (a character swings a sword) and move on to more complicated interactions (a character swings a sword and hits something) and upwards until the system has the features that I want.
So what are those features? Here are some of the broad concepts and features I want this system to have:
- Stance-based Combat — Collections of attacks will be grouped up into “Stances.” Stances will have different relationships to one-another. For example, the “Guard” stance might automatically block the “Heavy” stance, whereas the only way to block attacks from the “Fast” stance will be to cancel them out with other “Fast” stance attacks.
- Swordplay Focused — Though I will try to make the system itself as abstract and non-specific as possible, my first iteration will be for one vs one sword combat.
- Dynamic Movement and Animation — I’m not an artist, so I don’t want to have to make countless animations for this system to work. I want to be able to set what characters are going to do from within Unity’s editor.
- Physics-based Interactions — There’s no point in creating a dynamic animation system if it plays the same way every time. I want the character’s swords to interact in a physical and generative way.
- Stat-based Interactions — I also want to support character statistics that will modify how the characters fight. Examples of this would be the strength or speed of an attack.
- Encapsulated Controls — The input methods for combatants will be separated from the actual systems. The input will only see a list of attack “types” (Attack 1, Attack 2; horizontal, vertical, lunge; etc) and Stances.
Now, this list is quite intense, and the system it details is rather expansive. I expect this to take a long time, but the journey is half the point. As I said before, I’m going to start with very basic functionality and work up from there, with the goal of having the final structure evolve naturally.
Let’s get to it.