futuregrind

[futuregrind]

PlayStation Experience Round-Up

At the beginning of December Matt and I took off to Anaheim, California for Sony’s annual PlayStation Experience event. We were showing a new demo of FutureGrind with new tracks and even a new bike to play. Reception to the game was amazingly positive, and we got some really excellent feedback from players! A bunch of press also stopped by to speak with us and play the game. Here’s a round-up of links about FutureGrind from PSX 2016:

Polygon: Polygon Plays FutureGrind (video)

GamesRadar+: FutureGrind revs up with a colorful twist on arcade racing

PlayStation Lifestyle:  PSX 2016 – FutureGrind Preview – Stylish Fun

Solid Duff Gaming: The Future of Skill-Based Grinding is Here With FutureGrind

Thanks to everyone who came out and played the game at PSX! We had a blast showing it to you.

Owen

[futuregrind]

We took a FutureGrind demo to PlayStation Experience 2016 in Anaheim, California at the beginning of December. It was a lot of fun to show the game and get valuable feedback from players. We also let people play a new bike and track. We made a video to show people who couldn’t attend what it was like.

[futuregrind]

We’re still hard at work on FutureGrind! I’ve been working on a new track in Old Town. Here’s a shot of what it looks like in the Unity editor. You can see the awesome custom track editor that Matt built for the game! If you’re curious about how the track editor works, we posted a lot of details about it a while ago: http://futuregrind.tumblr.com/post/101354098523/the-math-behind-the-futuregrind-track-editor

[futuregrind]

We’ve been working on some poster art for FutureGrind. I think this is one of the coolest pieces we’ve done for the game.

[futuregrind]

Rag Doll and Animations

After we got the rider physics system working in the game, the rider was feeling a lot more alive while on the bike. But when the bike crashed and the rider went into a rag doll physics simulation, it all of a sudden felt very static again. We decided to use another Unity plugin from RootMotion called PuppetMaster.

PuppetMaster allows you to blend a canned animation with a rag doll physics sim. The plan was to spawn a rag doll version of the rider when the bike crashed, play a flailing animation, and blend it with the rag doll physics sim. This would make the rider look like they were flailing around in the air, but still behave in a physically realistic way.

Doing this meant learning how to animate in Blender, and then learning how to create Mecanim state machines in Unity, but what’s game development if not a constant learning process!

The first step was to get PuppetMaster integrated into the game and working with our rider rig and rag doll. Here was a test I did changing the muscle weights in PuppetMaster. As I make the muscles weaker, the rig transitions from a rigid static “animation” to a flexible rag doll:

Once that was working, it was time to integrate it into the game itself and get it all working together. As you can see, in game dev there are often a lot of broken steps on the way to having something that works:

Finally I created a couple of animations for the rider:

1) a static position “animation” of the rider posed on the bike 2) a flail animation where the rider would move their arms and legs around 3) a static position “animation” of the rider curled up into a ball

I created a Mecanim Animator that transitions the rider from the bike position, to the flail animation, to the ball animation. Mecanim nicely handles the transitions and blending between the animations. Then we hook it all up to PuppetMaster and configure all the muscle weights so that the rider is still affected by the physics sim. The end result feels pretty great in the game!

Owen

[futuregrind]

Rider Physics

In January I sat down to implement a new system that would add some physics to the rider that sits on the FutureGrind “bike” (or “grinder”). Until now, the rider was a static mesh that sat on the bike, but we wanted to have the rider move around a little bit as the bike spun, and hit the rails. We felt that it would help the rider feel more alive, and make the impacts of the bike feel a bit more important.

The first thing I needed to do was get a plugin called Final IK (by RootMotion) integrated and working with our rigged character. That was really easy to get set up, and you can see me playing with the rigged IK character here:

The next step was to calculate all the forces acting on the rider every frame and apply them to the IK rig. We can’t just use Unity’s built-in physics and forces, because we don’t actually use Unity’s physics for any of the bike movements. I spent a bunch of time working out the physics and math, which I may write up in a longer detailed technical post if there’s interest.

Implementing physics stuff is fun, because you often get ridiculous bugs along the way:

But finally started dialling things in to a more correct system:

Finally, once all the physics systems were finally debugged and working, we had a subtle, but really nice feeling set of movements for the rider when you’re playing. It’s not something you notice immediately, but it makes everything feel so much better:

Finally got the rider physics looking pretty close to how I want it. It’s subtle but adds a lot. #futuregrind pic.twitter.com/yNutNiQ7Xm

— Owen Goss (@OwenGoss)

January 8, 2016

Once that was working, I also implemented a few quick lines of code that allows us to tell the head to look at different things. Matt can hook into this from the gameplay code and have the rider look at stuff that’s coming up ahead, or look behind themselves when they’re doing backwards, and stuff like that. Should be pretty cool. These are some random head movements to test the system:

That's a quick look at some of the work we've been doing to breathe a little bit of life into the rider!

Owen

[futuregrind]

In December we took FutureGrind to PlayStation Experience in San Francisco. We showed a whole new environment of the game in our demo, and we spent a lot of time polishing the visuals of the game. These are some screenshots I took from that build of the game showing the latest.

Owen

[futuregrind]

Matt and I were talking the other day about how many little visual changes we’d made to the game over the last few months. When you work on a game and make lots of little changes over time, you don’t really notice how much of a difference they’ve all made together. We thought it would be cool to take some new screenshots so we could see the difference. We thought you might like to see too!

Owen

[futuregrind]

We’ve been working away on FutureGrind but haven’t posted much lately. We’ve gone back and revisited some of the visual style to try to improve the look of the game both for aesthetics and making it easier for the player to understand what’s going. I feel like we’ve been making some good progress.

Today I’ve been spending time taking some new screenshots of the game with some custom cameras, so I thought I’d share one.

Owen

[futuregrind]

Implementing grinder crashes (told in vines)

Two days ago I started working on the implementation of a new feature for FutureGrind. When the grinder (our vehicle) crashes, it used to play an explosion effect and the grinder would immediately vanish. We wanted to add more excitement to the crashes, so the plan was to have the rider fly out of the grinder and have the grinder bust up into pieces during a crash.

I decided to document the various stages of implementation with vines and put them all together in one place so you can see how a feature like this comes together:

1) On crash, spawn the rag doll character physics object. It just drops to the ground.

2) Follow the rider rag doll with the camera as it falls.

3) Apply forces to the rag doll so that it keeps moving forward after the crash. Also apply some random forces to the limbs to make them flail around a bit.

4) Sometimes during development you get...uh...bugs...

5) Spawn copies of all the grinder parts during a crash and apply forces to them all, similar to the rag doll. Oops...the forces are a bit strong...

6) Better forces being applied to grinder bits. Improved the shapes of the physics objects so that the grinder pieces roll on the ground in a more realistic way. Failure screen comes up after a couple of seconds.

7) Added smoke and fire effects to some of the grinder pieces. Makes everything look cooler. Particles always make stuff cooler.

I’m pretty happy with this so far! It will require more tweaking before we ship the game, but I’m excited to have people play this at PAX next week!

Owen

[futuregrind]

FutureGrind is coming to PAX Prime!

That’s right, FutureGrind will be at PAX Prime at the end of August, 2015! We’re really excited to be a part of the Indie MEGABOOTH in their MINIBOOTH section. 

Check out the Indie MEGABOOTH site for a full list of games showing, and for more information on FutureGrind. This video shows a bunch of the awesome indie games you’ll be able to try at the MEGABOOTH (including FutureGrind):

So if you’re coming to PAX, stop by the booth and say hi! Both Matt and I will be there talking to folks and showing the game. We’ll also have some sweet FutureGrind buttons for you to grab!

Owen

[futuregrind]

I’ve been working on some new art tools in Unity for FutureGrind over the past couple of weeks. We wanted a way to manage our colour palette across the game in a better way. So I’ve been working on tools that allow us to do just that!

(The very complicated post I wrote on serializing dictionaries in Unity was for this stuff)

[futuregrind]

Unity Dictionary Serialization

This post is pretty technical, so it will be most interesting to you if you're a Unity programmer...or just feeling a little adventurous.

The Problem: 

I’m in the middle of making some big changes to our art pipeline to allow us more control over the way the art looks from inside Unity. One of the things I need to do is store a Dictionary of data inside a ScriptableObject. However, Unity doesn’t automatically serialize Dictionaries.

The result is that if you have a ScriptableObject or MonoBehaviour that contains a Dictionary field, when you save it to disk and reload it, that data is gone. This is not usually want you want…

The Details:

The problem is actually a little bit more complicated than I described above. The data I actually need to serialize is the following:

Dictionary<Mesh, List<List<int>>>

And we’ll see why that complicates things in the solution section next…

The Solution:

(I need to thank Matt for pointing me to most of the resources I’m going to mention. This is why it’s awesome working with someone else: they can help you when you get stuck)

As I mentioned above, the first problem is that Unity just won’t serialize a Dictionary. In order to work around this, you need to create a derived class from Dictionary and write your own serialization callbacks. Matt pointed me to this link, which describes the code:

http://answers.unity3d.com/questions/460727/how-to-serialize-dictionary-with-unity-serializati.html

The end result is a class called SerializableDictionary, which looks like this:

using UnityEngine; using UnityEditor; using System; using System.Collections; using System.Collections.Generic; // Unity can't serialize Dictionaries, so this works around it by using Lists instead. // Details here: http://answers.unity3d.com/questions/460727/how-to-serialize-dictionary-with-unity-serializati.html // NOTE: The TKey and TValue types you pass in MUST be seriliable themselves. If they aren't // try using the generic derived class technique found at the same link. [Serializable] public class SerializableDictionary<TKey, TValue> : Dictionary<TKey, TValue>, ISerializationCallbackReceiver { [SerializeField] private List<TKey> keys = new List<TKey>(); [SerializeField] private List<TValue> values = new List<TValue>(); // save the dictionary to lists public void OnBeforeSerialize() { keys.Clear(); values.Clear(); foreach(KeyValuePair<TKey, TValue> pair in this) { keys.Add(pair.Key); values.Add(pair.Value); } } // load dictionary from lists public void OnAfterDeserialize() { this.Clear(); if(keys.Count != values.Count) throw new System.Exception(string.Format("there are {0} keys and {1} values after deserialization. Make sure that both key and value types are serializable.", keys.Count, values.Count)); for(int i = 0; i < keys.Count; i++) this.Add(keys[i], values[i]); } }

Great! Oh…except now we’ve run into a new problem. If you declare this field:

SerializableDictionary<Mesh, List<List<int>>>

it still won’t serialize because Unity doesn’t know how to serialize a generalized class (i.e. a class declared like MyClass<T>).

However, if you visit that same link from above:

http://answers.unity3d.com/questions/460727/how-to-serialize-dictionary-with-unity-serializati.html

We learn that you can derive a subclass of a generic class with a specific type and Unity can serialize that. So now we have this:

[Serializable] public class MeshToIntListListDict : SerializableDictionary<Mesh, List<List<int>>> {}

Awesome! Except…it still doesn’t serialize.

Now the problem is the type we’re trying to use for our Dictionary values. Our SerializableDictionary class requires that the type we pass as values to the Dictionary is serializable. This is because the SD class grabs all the keys and shoves them into a List, and it does the same with the values. So internally, it’s trying to serialize:

List<List<List<int>>>

and Unity just goes. “Uh…” But there’s a way we can make this work:

http://answers.unity3d.com/questions/289692/serialize-nested-lists.html

All we have to do is create a serializable class that contains our List. And we can do this multiple times for as many nested lists as we need. So now we have this code:

[Serializable] public class IntList { public List<int> list = new List<int>(); } [Serializable] public class IntListList { public List<IntList> list = new List<IntList>(); } [Serializable] public class MeshToIntListListDict : SerializableDictionary<Mesh, IntListList> {} public MeshToIntListListDict myMeshDict = new MeshToIntListListDict();

And internal to the SerializableDictionary, it’s now creating:

List<IntListList>

which is fully serializable! Success! Now Unity can serialize our ridiculous data structure!

But wait, the major problem with this approach is that it makes the resulting code pretty ugly. Let’s say we want to add an element to our data structure. In the original case, we end up with this syntax:

myMeshDict[mesh][index].Add(curInt);

But now we end up with this mess:

myMeshDict[mesh].list[index].list.Add(curInt);

While that may not look overly confusing at first, I can assure you it is confusing to try to write. But we can fix that too with operator overloading. So let’s add array accessors and helper functions to our custom classes:

[Serializable] public class IntList { public List<int> list = new List<int>(); public int this[int i] { get { return list[i]; } set { list[i] = value; } } public void Add(int i) { list.Add(i); } public int Count { get { return list.Count; } } } [Serializable] public class IntListList { public List<IntList> list = new List<IntList>(); public IntList this[int i] { get { return list[i]; } set { list[i] = value; } } public void Add(IntList i) { list.Add(i); } public int Count { get { return list.Count; } } }

And now we can access our stuff in a nice way again:

myMeshDict[mesh][index].Add(curInt);

Now who needs a drink?

Owen

[futuregrind]

Doodling some futuristic interior spaces.

[futuregrind]

I’ve been working on adding some 3D elements to our FutureGrind demo’s score screen. Now with spinning medal...

[futuregrind]

I got some new pens for sketching, so I started doodling some rough building designs for FutureGrind.

[futuregrind]

Big announcement this morning: FutureGrind will also be coming to PS4! You can read more details on the Playstation Blog: http://blog.us.playstation.com/2015/02/23/skill-based-stunt-racer-futuregrind-coming-to-ps4/