Characters and animation

We’re getting ready to go to Kickstarter with our game, to help us raise the money needed for the custom art, animations, and hopefully original music for Spy DNA. This means we’re making a new video to show off the progress we’ve made in the past couple of months.

One important improvement you’ll notice is that we’re using custom characters to replace the placeholders we got from the Unreal Engine asset store.

The cool thing about using custom characters is that we can make them look all different, use different body types, skin and hair colors, and of course different clothing.

Now the challenge with that is that once you stray from the Unreal Store, you need to rig up and animate the characters from scratch.

While we’re working on funding custom motion captures, we’re using some animations we purchased from mo-cap vendors with our characters.
We have (finally!) settled on an animation workflow for the project. We use Autodesk MotionBuilder for working with animations. This allows us to retarget an animation from one character to another. This is important because depending on the source of the character they may have a different skeleton, which makes the animations incompatible. This tool allows us to solve this problem.

Next, we get the animations into our project in Unreal Engine. That done, there is still a lot of work to do. The first step is selecting which animation to play for a character at any given time. At last count we have nearly 1,000 animations captured. Selecting the right one to play at any given time is complex enough we had to abandon the normal UE4 blueprint system and move most of the animation logic to C++. Once the system knows which animation is to be played, it may be necessary to slightly speed up or slow down the playback to match the speed of the specific character. 

It’s at this point that things start to get hard (as if it wasn’t hard enough already, heheh). So now that you have your base animation, you want to adjust it for the environment, so that a character's feet don’t go through the ground or hang in the air. Also you want the character to look and aim in the right direction. For these effects we are evaluating some middleware solutions (HumanIK, Morpheme, and IKinema). These provide tools for improving the interaction between the animation, character model, and the environment. In some cases they can also generate animations on the fly in response to environmental stimulus. A good example would be falling down stairs after dying.

In the process of getting it all to work, we get to watch many animations that look pretty funny. Do you have your favorite animation bloopers from a game you played? Share it with us in the comments.

GDC session highlight: Making a game fun for all kinds of players

There were so many awesome sessions going on at the GDC, it was hard to choose which ones to go to! Luckily, attendees get access to the recordings after the event, so we’re looking forward to watching the sessions we didn’t attend in person.

When beginning to write this post, I noticed that GDC team have made some of this year’s sessions available to watch for free on YouTube already. As they continue to add to the playlist, I will post the more relevant talks here with my comments.

Just how hard would you like your game to be?

Just how hard would you like your game to be?

One of the sessions GDC already published makes great points about building games that can be fun to play for a wide range of users. We wanted to link this video here for you and share our thoughts on how this relates to what we’re doing here with Spy DNA.

The two main takeaways from this talk for me are:

  • Ability to remap controls is not just nice; for some users, it’s critical to be able to play at all.

    Spy DNA is primarily targeting the PC market, and we’re planning to allow the player to use either mouse and keyboard, or the game controller to play. To make our game playable for people who can’t use the standard key mappings, we will include the ability for the users to remap their controls to suit their needs.
  • From “almost impossible to lose” to “almost impossible to win” is a sliding scale of difficulty, and many players would enjoy choices beyond just “easy” and “hard.”

    We are giving this one a lot of thought.  We want to avoid the temptation to take the easy way out and just make a the enemies stronger or more numerous.  Instead we are putting our effort into the most realistic version of the game.  This will be the hardest setting.  For players that do not enjoy the harshness of realistic combat, we will have a variety of options to make the game easier.  Examples would be accelerated healing for the PCs, starting with more skill points, or a reduction in the enemy's ability to land the most damaging shots. 

    We understand we are building a hard-core combat system that will be more challenging than most strategy games. However, once someone buys our game, it’s theirs to play, the way they want to.  So if limiting the enemy to low-power weapons is something you want to do, that will be your option.   

    This means that in Spy DNA, on one end of the continuum, there will be a full “ironman” mode, where you don’t get to reload, and only very few (if any) checkpoints. On the other end, there will be a super-easy mode, for people who either don’t have the ability to master the harder difficulty levels, or don’t play the game for the challenge.

    We don’t want to limit the difficulty settings to just Hard, Medium, and Easy. Instead, we’re aiming to offer our players many more points on the continuum to choose from, both to make Spy DNA appealing to players of all levels, and to provide a gradual difficulty increase for better replay value.

Anyways, that’s what we thought when we listened to this talk. Even if you don’t watch the whole video (or any of it), I hope we got the two main takeaways across. Use the comments below share your opinions.

Development update: UI

We've been working hard on the UI for Spy DNA.  One of the challenges with creating realistic combat is how to present the many options that are immediately available to a real combatant in a simple and intuitive UI.

We recently did our first round of play testing.  The chance to observe people playing is very valuable to a developer. From this we made a list of UI interactions the players didn’t find obvious and have addressed each one.

One example of this is the action of changing equipment.  Watching people play a common pattern was to pause the game, go through inventory and find the weapon they wanted, then equip it.  Now because the game is timeline based this would generate an action to equip the weapon.  However, since the game was paused, it didn’t immediately appear equipped.  This created confusion.  So we now show the state at the end of all queued actions where appropriate.  

For interacting on the 3D map we moved from placing all the controls on the HUD to popping up context-sensitive controls where it makes sense.  Now you can quick-click an enemy to attack as before.  However, a long click will open up a menu with all the various attack options for the combination of attacking character and target. A quick click executes the default action as before.

The same applies to movement.  Clicking on the map selects the default movement speed.  If you hold down the left button for about half a second the speed options also appear. 

Some controls such as character selection and character state remain in the HUD.  The idea is the state of the currently selected character should always be visible and the common controls ready.