Saturday, May 6, 2017

TrueSync and Rollback Netcode Prototype

Ever since the release of the first iteration of Battle High I worked on was release, I wish I was able to get the game working with online multiplayer capabilities.
At the time and until recently, doing so seemed very difficult for someone without a vast knowledge of network experience.  Even some of the biggest companies still have problems when it comes to fighting game netcode.
Regardless, I know, if I ever wanted to add it to Battle High 2 or to make it for a future title, that I would want a rollback netcode solution.  I know GGPO exists, but it's C++ library (making it very difficult to integrate into Unity3D), expensive to get a license, and last time I checked, not even openly available, especially to Unity devs, anymore.
I had experimented with doing it myself using uNet, Unity's built-in networking library, but the results were far from perfect and rather buggy.

Anyway, a few months ago, I was browsing the Unity Asset Store and came across TrueSync by Exit Games.  The first thing I read, which appealed to me was that it used a Rollback Engine and since I had some experience using Photon, the networking library TrueSync is based on, I decided to give it a whirl.
Though the library is not finished, I'm still impressed and have been able to get a pretty decent prototype -- at least to me.
Here's a video showing off the tool to record information I'll be discussing shortly as well as an example fighter:

TrueSync has a few aspects which were interesting to work with in Unity3D.

Fixed Points

The goal of TrueSync is to keep players in-sync.  There are two aspects of base Unity3D development that make this difficult:  floating point precision and determinism.  Because different computers interpret floating points differently, there can be problems with syncing.  To fix this, TrueSync provides its own structs such as FP (Fixed Point) and TSVector.  They work similarly to floats and Vector3's, but with the goal to be consistent between machines.
Overall, a lot of Unity3D components have TrueSync versions such as TSTransforms used to replace Transforms and track their position, rotation, and scale; however, some aspects of Unity are still nondeterministic such as the Animator and can make certain types of game, such as a 3D fighter, rather difficult to make.
Anyway, this blog goes over some aspects of TrueSync and workarounds I used to get the game working and still synced (at least to my knowledge as I haven't tested it a ton with other players.)


TrueSyncBehaviours created by the TrueSyncManager, the MonoBehaviors that manages the TrueSync scene use a method called OnSyncInput.  This method is used to take player input, send it to the opponent and then perform a rollback if it has changed.
I feel sending the less values over for this, the better, so I just send a single integer and then use a bitmask to see how it has changed.

AddTracking Attribute

Another important aspects of TrueSync is the AddTracking attribute.  TSTransform positions and rotations are tracked; this attribute is important because when the game rolls back, these parameters will be taken into account.  Overall, anything that changes on the player and is important for both players to know needs this attribute; however, I wish I knew if there was a limit or warning if you try to track too many variables.

Animation & Playables

Anyway, since I was doing a 3D fighting game prototype, I had to figure out a way to make TrueSync do the following:
  • Translate and rotate the character using animations' root motion
  • Figure out where certain limbs were on certain frames for hitbox detection
The normal animator system was causing issues with this.  Limb positions were different between users as were root positions.  The solution came in the form of Playables, Unity's newer alternative to the Animator (though recently I learned as of 5.6 and onward, this system is changing, once again.)
In 5.5, the advantage is that it allows me to set a time directly instead of letting the animator playout, which can cause problems with floating points precision errors.
To get my game working, I had to do the following:
  • Store an array of TSVectors based on frame for translation and rotation
    • I did this with a tool that plays out each playable, recording the changes in root position and rotation to TSVectors and TSQuaternions respectively.
  • Store a similar array of TSVectors for the position of different limbs.
One thing to note is that TSTransform does not have all the same functions as Unity3D's transform, so functions like InverseTransformPoint don't exist, so to get these TSVectors, I had to do a little work.  In my tool, I use the following between frames:

Vector3 prePos;
Vector3 diff = transform.position - prePos;
prePos = transform.position;
diff = transform.InverseTransformVector(diff) * 60f;
fighterInfo[currentInfo].velocityByFrame.Add(new TSVector(diff.x, diff.y, diff.z));

I record the velocity change each frame by using transform.InvertseTransformVector and store it in an array.

For rotation, I use the following:

Quaternion newQuat = Quaternion.FromToRotation(preForward, transform.forward);
preForward = transform.forward;
Vector3 v = newQuat.eulerAngles;
fighterInfo[currentInfo].rotationByFrameEuler.Add(new TSVector(v.x, v.y, v.z));

Then, during OnSyncBehaviour, the TrueSync's behaviour method, I translate and rotate these back to my characters by using the following:

TSVector vel = tsTransform.rotation * states[currentAnimIndex].velocityByFrame[currentFrame] * TrueSyncManager.DeltaTime;
tsTransform.position += vel; 


An important thing to note is I also don't let the Animator playing the Playable use root motion.  Anyway, because currentFrame uses the AddTracking attribute, when the game rollbacks because of new inputs, my character's positions and rotations are fixed and recalculated.

For keeping track of joints and other areas that need to be tracked for hit spheres, I use the following:

Transform t = anim.GetBoneTransform(fighterInfo[currentInfo].hitBoxPoints[i].boneRef);
Vector3 iP = 0.5f * (t.transform.position + t.GetChild(0).transform.position) - transform.position;

iP = transform.InverseTransformVector(iP);

I get the bone's position and average it with the first child so it feels more center (for example, I get the middle of the hand instead of the wrists.  I then subtract the root position from this and use InverseTransformVector.  In the game, when I want to get this position back, when testing hit collision, I use the following:

TSVector hurtBoxPos = tsTransform.position + tsTransform.rotation * currentState.hitBoxPoints[0].trackedPoint[currentFrame];

It's similar to my velocity, but I add the current transform position first.

Overall, this allowed me to get points that in a non-networked game I could probably get more easily, but this allowed me to get this rather accurately.

Local Multiplayer

This is another issue I was having and wasn't addressed, but most if not all fighting games have the ability to be played locally offline.  By default, TrueSync doesn't really provide this.  Photon does have an offline mode, so when I want a local match, I set offline mode on and instantiate a second player.  This player uses a different key during OnSyncInput; otherwise, both players would mimic each other the entire time since it's the same machine.

A Work in Progress

TrueSync is still a work in progress.  For example, the provided physics are still rather problematic.  I tried using them at first but characters were sinking through the floor, going through walls, and all other sorts of strange behaviour.  To be honest, I always struggle when I use an engine's provided physics, so I went with my own solutions instead -- using sphere intersection checking, distance checking, etc.

Also, it's built off Photon, which is great, but there's a lot about Photon I still need to make myself familiar with, for example, how to cleanly exit a room?  Is it usable for Xbox One games and if so, what do I need to do?  Also, Photon is not free; unless I'm okay with only 20 people being able to play at a time, which I'm not, I'd need to pay to get more eventually; unless, I'm willing to host my own server, which quite frankly I'm not.

Will I use this to port Battle High 2 to an online mutliplayer solution?  Maybe!  The issue is this prototype is going smoothly because I started working with online in mind from the start.  I did not do this with Battle High 2 A+; however, this does not mean I can't do such a thing, but I know there is a lot more work involved.

Finally, I uploaded the protoype to; if you'd like to try it, feel free!  I'd love to know if the online worked for you! (I know, from a fighting game perspective there is still a TON of work to do).

Thursday, January 12, 2017

Battle High 2 A+ @ Magfest!

So as I previously mentioned, I entered Battle High 2 A+ on a whim into MagFest's indie game showcase.  MagFest is an game and music festival near Washington DC.  Since there was no entry fee, I figured entering was a win-win.  If I got the game into the show, I'd get an awesome opportunity to show the game off; however, if it were rejected, I'd be able to enjoy the conference without the stress of presenting a game.
Fortunately for me, it was accepted!  It was a great learning experience that I would like to share.


What I Did Well

Since this wasn't the first indie showcase at MagFest, there was plenty of useful resources out there to prepare.  I believe I was pretty well prepared and did the following well:
  • Be comfortable and have food and water:  Being at a booth for 4+ hours a day can be rather tiring, especially if you're standing a majority of that time (fortunately, I had extra chairs), but I made sure to dress comfortably as well as have food and water.
One of the "delicious" snacks I had
  • Have a carpet! (or make your space presentable):  I had banners, a carpet -- actually an outdoor floor mat which wasn't too soft and conflicted with comfort a bit -- and two setups.  I think my setup could have been nicer, but it was acceptable in my opinion.

  • Get help!:  As a solo dev, manning a booth can be rather difficult.  Fortunately, I had some coworkers and friends come to MagFest to help, even briefly for bathroom or lunch breaks. 
  • Have back-ups!:  I had my Xbox One with Battle High 2 A+ on it as well as my Microsoft Surface.  I also brought 3 monitors and extra cables.  Having 2 setups was great -- allowing more people to play the game -- but it was also good in case something broke!


 What I Could Have Done Better

This was the first time I had really shown off the game at a gaming venue, so there were a few things I could have done better.
  • Bring a dolly cart!  I recently bought a new car with a lot of room, which made transporting all of the monitors and other gear easy; however, taking it from my car to the hotel was rather frustrating.  A dolly cart would have made this a lot easier.
Would have helped so much...

  • Make it easier to see you worked on the game.  The first and second days of MagFest I wore Battle-High-related gear; however, on the 3rd and 4th days, I didn't, so people didn't know I had worked on the game and thought I was just watching or waiting for my turn to play.
A photo posted by Matt (@mattrified) on

  • Give credit better:  Though I work primarily alone, a lot of talented people worked on Battle High, and I wish I had better information about them when asked.  A lot of people would ask about the pixel artist or the graphic designer, and it was awkward trying to explain the situation of those individuals with people.  Having their business cards -- with their permissions of course -- would have made this easier.
  • Better print materials and swag:  This is mixed.  People liked my buttons -- which I'm practically out of -- and business cards.  I also had post cards -- which were the best thing to give out -- however, the post cards didn't have accurate or enough information.  For one, it only listed that the game was out for Xbox One and  Unfortunately, right after printing, I published Battle High 2 A+ on Game Jolt, so I had to tell people this directly.  I wanted to print out a new post card with the additional platform, as well as information on the back about Battle High 2 A+'s history (pictured below), but I procrastinated -- THANKS, CHRISTMAS. 

  Another thing I did is I get pencils printed.  Though I thought this was a neat bit of swag, they didn't go as well as I would have thought -- and now I have over 300 pencils! Regardless, the misprinted postcards were probably the most frustrating part of this.

A photo posted by Matt (@mattrified) on

  • SPEAKERS!  I bought really nice BenQ monitors for MagFest that had built-in speakers; unfortunately, I didn't realize till later that they were rather quiet.  I should have bought speakers as well.  No one could hear the sound design, voice acting, or music, which was especially embarrassing when the sound designer showed up to player -- SORRY!
  • Let people play themselves.  On the first day, some people wanted to play and instead of letting them play Arcade, I would volunteer to play them in Versus, probably scaring some of them away.  Though, and this was a bit awkward, a lot of people would ask me, "Hey, can I play?" to which I sometimes looked at them like a confused dog.  I guess maybe they thought I was in line to play or something and not the dev, but still, I wasn't sure what to say.
I think I nearly did this at least once.
Overall, showing my game off at MagFest was a great learning experience.  I met with a lot of people who were enthusiastic to play the game as well as its future and some that even showed interest in working with me in the future on updates or new titles.  Sure there were some people who weren't interested or poked fun at the cheesy dialogue, but nothing heinous and nothing directed at me like "Go jump off a bridge!"  The worst comment I heard was "Oh geez, I never heard of this game before!" which mostly made me realize my lack of marketing.
I got to see people play the game in a competitive setting which is probably the best way to learn about the game and I learned a lot.  For example, I learned that Beat has a nasty high-low mix-up, and that Jada's Lightning Whip's are overpowered.  I also got to witness the first (that I'm aware of) Battle High 2 A+ tournament!  Sure there were only 12 entrants and 4 of them didn't show, but it was still awesome to see!

Footage of the Battle High 2 A+ Tournament in Action!

I also got to see the game played at MagFest Versus -- a Nick Arcade-like gameshow held at the festival.

Footage taken from MagFest Versus!

Now, I've heard developers complain that sometimes cons aren't worth it, that a lot of people will say they like your game and will buy it but then "forget" to after the show, but you know what?  I don't really care.  I had a great time, learned a lot, and would love to do it again either at MagFest or another similar con with Battle High 2 A+ or another game!

Wednesday, January 11, 2017

2016 In Review

So it's over a week into 2017, and I realized I haven't written much about 2016.  I wanted to take some time now and write a (semi) game-development-related retrospective of 2016, its highlights, lowlights, and maybe a midlight.

Lowlight:  Rushing a Game for IndieCade

Though it was a learning experience, the year did start off a little rough.  I had just come off of releasing Battle High 2 A+ on Xbox One in December of 2015, so I was taking a bit of a break from game development in the beginning of the year.  Soon though, I was trying to finish a game for IndieCade, an independent game festival.  The entries were due in May, so I figured I had enough time to get at least a competent prototype done.  I was working on a merfolk themed tactics games with fighting game elements.

Though I made some good progress, I still felt I was rushing and was unhappy with what I came up with.  I wrote about this on Gamasutra.  Since then, I've decided to start the idea over.  One issue with it was that it was starting to feel too copied and unoriginal.  I don't want to use the grid-based system for movement.  In addition, I just wasn't happy with the art.  I want to try something else and I don't want to rush the game for some contest.  Though I think deadlines are important, setting one that is too soon can make the project feel insurmountable.

Highlight:  Patching Battle High 2 A+ Successfully -- Twice!

After taking a break from the merfolk game, I decided to do a small Battle High patch.  I was pleased, once again, with how easy it was to update it through the ID@Xbox program.  In fact, later in the same year, I decided add a new character to Battle High 2 A+ named Beat -- which I wrote about in previous blog posts.

Lowlight:  Oral and Other Health Issues

Before the Beat patch, however, I had some drama.  Around July, one of my teeth started bothering me.  The dentist didn't quite know what was wrong, noticing that the tooth was wiggling a bit.  Because I had trips coming up in October, I was nervous about doing anything major, especially after being told by the endodontist that nothing seemed problematic in the x-rays.  Fast-foward to mid-October, right before Unite (one of Unity's yearly conferences), I go in for a checkup and my dentist discovered the tooth wasn't cracked but that the crown was loose.  She recements it, and the problematic pain returns the following weekend.  I then go through a root canal retreatment -- essentially a root canal on the same tooth.

Imagine having this done on the same tooth...twice

Overall, this isn't very game development related, but things like tooth pain are distracting.  From July to October I was worrying about my tooth, seeing if it was a gum infection or a cracked tooth, using an over-the-counter bite guard, not wanting to have an unnecessary extraction done, but worrying about it nonetheless.  At the same time, I was also having lower back pain back in February when I was working on the tactics fighter which made working a bit distracting -- this was mostly due to bad posture while working for long hours.  This made me come to the conclusion that I need to be more assertive when it comes to self-care.  I need to be less afraid to get something done instead of waiting-and-seeing, and I need to exercise and do more preventative care.  I need to sleep more and eat healthier.  These are all resolutions, and I've made progress on some.  I've starting speaking to an e-therapist to help with my depression, and I bought a treadmill (though I should have bought an elliptical machine) so I can jog (or at least walk) when it's ugly or too hot outside.

Highlight:  MagFest!!!

Another good thing that happened though is that around August, I decided to enter Battle High 2 A+ into the indie game showcase at MagFest -- a music and games festival near Washington DC.  It was accepted, which was a great -- yet rather stressful -- experience.  I'll write about that more in detail in my next posts.

MidLight:  Featured Blog

Admittedly, I can be a bit of a scrub at time...
I wrote a blog article about accessibility in fighting games, which got featured on Gamasutra.  I was excited to have it featured; however, some feedback on Twitter was rather harsh and made me worry that I had tarnished my reputation somehow, that if I were to release fighting games in the future, the genre's communities would see my name and ignore it.  I realized a lot of the criticism wasn't correct though, that people focused on one small argument while ignoring the a good majority of what I wrote.  What I said is that better tutorialization and simpler inputs could help with fighting game accessibility, not that they were the ultimate or only solutions.


Despite knowing that they are cheesy at times and almost none of them happen, I'd like to make some resolutions or goals for 2017:
  • Practice better self-care -- eating habits, exercise, sleep schedule, etc.
  • Prepare a game that I feel comfortable publishing before May of 2018
  • Write more blogs -- both here and on Gamasutra
  • Organize my web presence / social media accounts -- instagram, twitter, tumblr, etc. -- better
  • Don't let criticism hurt my progress or confidence and instead learn from it
Thanks for reading!

Saturday, December 10, 2016

Battle High 2 A+ On Itch.IO!

I'm proud to say that Battle High 2 A+ is available on  I just wanted to write a quick post on the different between the two and the idea behind some of the choices.

FeatureXbox (PC, Mac, Linux)
Controller CompatibilityXbox One ControllersMost Controllers and FightSticks, especially those recognized as Xbox 360 controllers
KeyboardNoYes (Only Player 1)
TestingMicrosoft Cert TeamPC tested lightly, Mac and Linux untested
AchievementsXbox One Achievements and Journal EntriesOnly Journal Entries
  • Price:  The Xbox One, because of the extra work, achievement features, and 70/30 payment split, is a dollar more.  Because isn't as tested and won't automatically update like the Xbox One version, it is a dollar less -- that being just a minimum price, of course.
  • Controller:  As previously mentioned, controllers on Xbox One are problematic at the moment; however, a wider selection of devices should work on the versions of Battle High 2 A+.
  • Keyboard:  Obviously, the Xbox One version doesn't use a keyboard.  The PC version does, but only for one player since a keyboard is considered an input device.  I haven't tested it using 2 keyboards.  Which keys represent what controller buttons can be configured by pressing F2 on the main menu.
  • Achievements:  The Xbox One version has achievements, a total of 1600 Gamerscore points (so far).  Though the journal entries for earning costume colors are still present, there is no outside API being called when these journal entries are triggered.
That's the most up to date information.  From now on, I'm going to do my best to keep the Xbox One versions up to date and identical to the versions.  If you find any issues while playing, please don't hesitate to email me about it at

Wednesday, December 7, 2016

Battle High 2 A+: Version

So, just in time for the one year anniversary of Battle High 2 A+'s release on the Xbox One, a new update has been made, version!

New Character:  Beat


First a foremost, the newest feature of this new version is Battle High 2 A+'s newest character, Beat!

Beat is a mysterious masked wrestler and water elemental.  Though they have strong slams like a grappler, they don't have the same stamina or low speed.  Beat's also has a lunging punch in which a bubble forms around his fist, destroying most projectiles that come in contact!  Beat is part of Version, which is a free download that should be available after 12/7/16.



I felt that releasing just a new character wasn't much, so I also added a new feature.  When selecting a stage in Versus or Training mode, pressing "X" will open up the modifiers menu!  This menu  will allow users to adjust the following settings:
  • Health:  Every wanted to have a set of first hit kill matches?  Well now you can!  With this modifier, health can now be set between 100% and 1%.
  • Elemental Energy:  Want to go one on one with no Elemental Energy?  How about infinite Elemental Energy?!  Set the starting energy, or set it to None so no energy generates, or Infinite to never lose meter
  • Stage Width:  This was more or less a suggestion from a player who felt the stages' widths were too long.  You can set it to 100% -- keeping it where it is -- or 64%, which would be one screen width, meaning the camera won't move at all.
  • Distort and Invert:  Well, I'll let players discover what that does for themselves, but these may be a hint at possible, future updates as well.


Other Changes


There's three new achievements.  One is for completing all of Beat's journal entries.  The other two are for fighting on modified stages in Versus.  The only other fix worth mentioning is a fix to Mai's light projectile.  It's hit stun was too long and made for a very easy infinite.


A Note About FightSticks


Someone on Twitter reminded me that I should mention FightSticks quickly.  I use Unity3D as my engine for this game.  Unfortunately, the engine, when building for Xbox One, does not support FightSticks since they are not interpreted the same as basic controllers on the console.  I put in a bug report about a year ago concerning this and recently heard back.  Unity3D is planning on overhauling its current input system; because of this, they are not going to look into fixing my bug.  Also, they do not know when this input system overhaul will be released.  When it is released, I'll do my best to look into updating Battle High 2 A+ and seeing if it works.  Note, most fightsticks should work on the PC version when that is finished and released, especially if said fightsticks are read as Xbox 360 or Xbox One controllers.




So with this latest update, what's in store for Battle High 2 A+'s future?  Well, there is still one character I'd like to finish.  It'd be nice to get them done before 2018; however, it'd also be nice to work on a new IP and finish a new game as well, so, I'm probably going to take a short break from Battle High 2 A+ a bit, but not till after MAGFEST!
This is because I'll be showing off Battle High 2 A+'s newest version there this January!  It's a bit nerve-racking, but also very exciting to be showing the game off to the public.  I've never done something like this before -- well, that's not entirely true, I did show it off at a small Pittsburgh tech gathering once.  Regardless, I'm nervous and excited.  Maybe I'll even be doing a tournament! Anyway, from now until January, that is probably what a majority of my indie game development time will be focused on.  I even got this fancy banner printed!

Other Versions


Another thing I will be focusing on is finally getting the PC (Linux and Mac) version of Battle High 2 A+ to match the Xbox One version.  This shouldn't take much time and hopefully can be accomplished before MagFest.
I did get asked about a version for the Razer Forge (the OUYA successor essentially).  I can't promise anything now.  There have been graphic changes / improvements made to this version that could make porting this version to the Android microconsole rather difficult.  I apologize in advance if this never comes to fruition.


Thanks for Playing!


Finally, I just wanted to thank everyone who has played the game and supported me while developing it as well as those who have worked on it with me.  This really is a passion project.  My plan for this game was never to fund my own company or retire.  I know it's not the best -- heck it's not even close to being the best -- fighting game out there.  It'll never be a part of EVO; there'll never be a Mattrified Cup -- at least any time soon on the latter.  Heck, I don't even have the time or resources to attempt implementing proper netplay -- though believe me, if I could I would -- but I still appreciate those who play and enjoy the game.  Your encouragement is the main reason I come back to it and develop it further.  Anyway, consider this free update a thank you.

Sunday, November 6, 2016

Unite 16

Since it's been awhile since my last post and I'm bored on my flight back from LA, I decided to write about my experience at this year's Unite.  Unite, for those who don't know, is a conference held by Unity3D where new features are announced or shown and knowledge is shared between other Unity developers.  Instead of going to GDC -- the Game Developers Conference -- this year, I decided to save my money and go to Unite instead.
This year's logo

I have to admit, I'm glad I did.  I wrote about this previously, but I feel it needs repeating.  I like Unite over GDC for three reasons -- focus, applicability, and positivity.  Though GDC is focused on game development, I feel it's very scattered.  You get high level design talks, low level tech talks, mid level art talks, etc.  For the price of admission to GDC -- about twice that of Unite's -- I just feel like I have a hard time focusing on what talks I should go to or want to go to.  Unite, though you do have design, tech, and art talks, connects all of its talks by the fact that Unity is involved somehow -- though this year I have to admit, some did a better job making this connecting than others.  Then, some talks at GDC don't really feel applicable to what I do at my current game development job or my current indie work.  Even though some topics discussed at Unite may be over my head, at least their connection to Unity makes them feel somewhat achievable.  Finally, there's positivity.  Unity is FAR from a perfect game engine, but a lot of people there are excited about it and that excitement is infectious.  The team is working hard to fix bugs and create new features, and they are excited to share that with attendees.  Anyway, here are some brief summaries of the talks I went to:



I admit, I was pretty tired during the keynote, but the two biggest things shown off that excited me during it were the Timeline and the new Post-Processing effects -- the former I'll talk about later.  They also demonstrated VR editor tools so you can create and build world elements while in VR -- admittedly, I personally wasn't excited for this but could see its appeal.


HoloLens, HoloLens, HoloLens!

I went on three separate talks about Microsoft's HoloLens, four if you count the one-on-one demo I had right after the keynote.
This is a HoloLens; I think I saw this image like 5 to 10 times.

As a VR skeptic -- not as strong as I used to be admittedly -- I was curious to have a demo of the HoloLens.  So after being taught their navigational concept, GGV -- Gaze, Gesture, and Voice -- I experienced a short demo called Galaxy Explorer.  I was impressed!  Once I got used to the gestures, it felt pretty natural.  Also, the device was untethered, and I was able to see the world around me.  It felt like it was adding to my reality, not imprisoning me in a different one -- which is what VR makes me feel like sometimes, especially due to the wires.  So, after this demo, I was very excited to try and learn as much as I could about this augmented reality device!  I also got to play with the new Surface Studio -- I think I may have to save up and make one my next PC.
This post is starting to feel like a Microsoft ad, huh?

The first talk that discussed HoloLens was entitled A Guide to Building Mixed Reality Experiences.  This was a rather high level talk about various challenges involving working with the HoloLens such as stabalization, world-locking, sharing, and more.  The speaker essentially told the audience to use the learning tools out there if you plan on developing for HoloLens.  I'll just say it left me a little hungry for more.
The second talk felt more like an advertisement to use Vuforia's augmented reality software with HoloLens to create even better, more immersive AR experiences.  Vuforia's AR toolkit involves looking at a symbol or image and using that image to display 3D objects, usually through a phone; however, because the HoloLens has a camera, you can use it to do this AR and make HoloLens experiences even more immersive.  It seemed very complex, probably something I'd never utilize, but it was neat to see it in practice.
The third HoloLens talk I went to, which was on the conference's second day, was my favorite.  It started off rather dry -- going over the specs, again -- but finally, the speaker went over some actual HoloLens implementation.  The most interesting was the explanation of two Unity Components, the Spatial Mapping Renderer and the Spatial Mapping Collider.  Essentially, the HoloLens collects data about your environment and creates a 3D mesh of said environment, which is updated repeatedly.  The SMR allows the environment to be rendered; it's most common use case is for occlusion, making objects "disappear" when they go behind a wall, floor, or table.  Then, the SMC created a collider for these objects, so I could, for example, have a sphere fall and make it appear to roll on the floor.
Some challenges with HoloLens development were then discussed.  One is the concept of anchoring.  A lot of the time, objects will jitter and shake.  To prevent this, they need to be anchored, either to the user or to a point in the world.  This seemed like an interesting challenge, but one that didn't seem insurmountable.  They went over the emulation process as well as other tips such as treating the HoloLens like a mobile device that should have a constant frame rate of 60 FPS.
I was a bit sad at the end, however, when I learned that there isn't a way to hook up an Xbox One controller to the HoloLens.  Someone mentioned that bluetooth controllers may work, but it was at this time I realized that the HoloLens isn't really being marketed as a gaming device, at least not in the way VR sometimes is.  My excitement for developing for HoloLens was a bit deflated -- especially at its price points -- $3,000 and $5,000 for commercial development.  That being said, if I ever had the choice between working on another VR project or a HoloLens project at work, I'd choose HoloLens.


Great Design Talks

Usually, GDC has the best design talks; however, two design talks this year were really enjoyable.  The first was entitled What Makes Great Games?  The talk was given by a programmer who goes by the name Gigi on the Unity forums; this made me laugh since that's also the name of the protagonist from the tactics fighter I started earlier this year.  His talk discussed his journey to try and find a recipe or formula to what makes a great game.
His initial recipe was simple:  Flow and Simplicity.  Of course, these two concepts needed to be broken down as well.  He defined flow as the state in which people are so involved in an activity that nothing else seems to matter.  He then gave his recipe for flow:



The player needs goals; however, not all goals are the same.  There are explicit goals set forth by the game; less defined implied goals such; and player driven goals, those that players bring to the game and the most interesting.



Feedback is how we perceive progress and is very important to flow.  Gigi told a story about how his old vacuum didn't let him see how much dirt he sucked up, but his new, expensive Dyson did, giving him feedback on his dirt accumulation.  Anyway, there is immediate feedback such as hit sparks in a fighting game; natural consequence such as fire burning somethings; and progress like levels or experience points.


No Distractions

He then mentioned the concept of No Distractions, which seemed more difficult than the previous two.  Essentially, he tried to make warn against distracting the player with too much -- with art, rules, pop-ups, anything really.


Just Right (Challenge)

Finally, he mentioned the Just Right challenge, which is a tough one because it's very subjective.  He showed the "Flow" chart in which difficulty over time/skill.  It reminded me of the Gamasutra blog post I wrote about fighting games recently.  It got some hate from those who don't find what I discussed hard; meanwhile, I wrote it to empathize with those who do.  Anyway, it really comes down to understanding your audience and what they find hard or difficult.

I think this is the exact same image shown during the talk.

He then went into simplicity, citing that creating it is very hard.  We yearn for grace and elegance in game designs, but it's not always there.  Again, wanting a recipe, he came up with 4 items -- though he cited these were ones he came up with that might not be as strong as others.



Core to me I felt could also be called Edit.  On creative competition shows like Chopped or Project Runway, the concept of editing is always brought up.  It's essentially cutting and editing until nothing else can be removed, until you risk losing the core.  Essentially, it came down to Less = More.
I'll just assume Tim Gunn is hearing about an overly complicated garment game design.


Limited Choice

Games are said to be a series of interesting choices -- paraphrasing from Sid Meier.  More choice isn't necessarily better as we get into what Gigi called the Paradox of Choice, a psychological term in which too many choices cause Analysis Paralysis, which causes us to postpone a decision and then eventually regret not making one.  He then used an MMO called Rift that didn't do very well.  He alluded that its character leveling system was perceived to have too many choices for users -- at least at first -- and could have contributed to this failure.
Skill tree from Rift.  A bit complicated-looking, right?



Similar to Just Right Challenge, but spoke more about making small changes to make things more understandable.


Player's Perspective

Finally, he explained that games can have a lot of complex systems, but the more that can be done to hide these and slowly reveal them as to not overload the player is a good start.
Anyway, his recipe for Simplicity came down to a cute acronym phrase:  CLIP it.
Overall, though this was a basic design talk with little connection, it talked about very important subjects that I believe a lot of designers, including myself, often overlook.  It was refreshing and enjoyable -- despite the audience participation.



The other design talk involved hats!  It was from two game developers who discussed 9 different hats they felt are necessary to wear when developing a game -- big or small.  I liked the talk a lot too despite it having very little connection to Unity.  The nine hats were as follows:



Asks the big why questions:  What are we making?  Who is the audience?  Where do we see ourselves in the future?
Pretty sure they were not referring to this guy.



Asks the how.  Has to make the choice between Fast, Good, and Cheap -- most say choose 2, but choosing 1 is more realistic.



The most groan-inducing; however, still important.  You need to think about how the game will make money, but also how will the game be funded, even if the answer to the first question is unimportant to you.
Probably what everyone envisions when they hear "Finance".



You want your audience to know your game exists.  This involves public relations and community management and customer service.  It's important to look for promotion opportunities, regardless of the size.


Quality Assurance

Thinking about an efficient process for fixing bugs.  Theirs:  Play, Encounter, Report, Fix, Review, and Repeat.  Also, they included general playtesting under this hat.


Design, Art, Code, & Audio

The two defined these 4 -- and I'm happy they included audio -- as the basic hats needed to be worn to actually make a game or the product itself.
They also gave 4 tips about wearing said hats:
  • You need to wear all 9!  They are all equally important.
  • You may have to wear multiple hats -- as a solo dev I try to wear all 9 -- but trying to wear multiple at the same time is bad -- focus is key.  Be a laser, not a hose.
  • Every hat will not look good on you; this is fine and happens.  It still needs to be worn; you can always learn from others or find others to wear it.
  • Multiple people should not wear the same hat at the same time.  You need to clearly define roles; you want to enable, not impede.  Tasks need to be focused and clearly defined.
An example of bad hat wearing; he's wearing multiple but only one is touching his head

Again, a very basic design talk, but with information I have a tendency to overlook.  The talk helped simplify these concepts in a way where some of the less desirable hats -- such as finance or marketing -- are still approachable.  I did suggest a tenth hat (later on Twitter), or a zero hat, being self-care, which I feel people working on an indie title -- including myself -- sometimes neglect.


Other Cool Things

At one point, I saw a rather interesting talk about Houdini, which is a software package I've heard about before, but primarily thought people just used it to make cool particle effects for video production, not games.  A dev making a game for both the PlayStation Vita and the PS4 showed us how he used it to make procedural meshes; for example, he created a bridge and then used a Unity plugin to make that bridge expand varying length depending on the design of his platformer levels.  It was cool to see; however, similar to Substance Designer, the amount of time it takes to setup such things make me wonder how useful they really are.  It did give me some ideas for the tactics fighter I was working on awhile ago.
An example of procedural meshes from Houdini

Some Unity developers showed off the new Timeline tool, which will be coming in later versions of Unity.  If I had to summarize it, I'd say it's like an Adobe AfterEffects timeline but for elements in your game, usually used for cutscenes, but it probably has thousands of other, unique uses.
This is from Cinema Suite, which is apparently what the Unity Timeline will be based on

Another company showed off an asset called NeoFur.  Though the talk was short and felt a bit like an ad, seeing it in action did seem interesting. 
An example of NeoFur

Then, a talented GPU programmer showed off how he got high quality cloth physics in Unity; well, he didn't show us how really -- at least not in-depth -- he showed us that he did.
Finally, the Unite Party was fun; it's usually a blast, and this year at Universal Studios was no exception -- though King Kong 3D was a dud.  A mixer at Madame Tussauds on Halloween night wasn't bad either.

A photo posted by Matt (@mattrified) on


Not So Cool Things

Any other talks were rather forgettable or memorable for the wrong reasons.  For example, the multiplayer talk, which did happen after the party, was sort of a mess.  In the first half, the two speakers discussed how they did peer-to-peer multiplayer for an RTS, but it didn't use any of Unity's new multiplayer tools, which was sorta frustrating.  Unity stresses democratizing game development, and they started with making online multiplayer more accessible, yet no one ever makes anything with it or shows how to make games -- that aren't the spaceshooter demo -- with it.  The second half was its own mess; I left 5 minutes into it.
Also, I was annoyed how there was no breaks in between talks, not even 5 minutes.  This usually results in talks running into each other and some starting late; the multiplayer talk started 18 minutes late for example. 
Finally, and this is stupid, but the provided lunches, in my opinion, weren't good.  I would have rather saved money on my ticket and just bought food since there were almost a dozen restaurants surrounding the hotel.
Okay, the salads weren't this sad, but that multiplayer talk was.

Overall though, despite a few minor hiccups, I really enjoyed Unite.  It inspired me to continue working on some older ideas I abandoned earlier this year instead of doing National Novel Writing Month.  I also think I may go next year instead of GDC once again, but I think it's still too early to tell.

Wednesday, July 20, 2016

Golem Jox 2: A Fighting Game Unet Experiment

During my spare time for the last couple of weeks I've been working on a fighting game prototype in Unity 3D involving primitive 3D shapes.  The following video shows the progression of this prototype:

I had the following two goals while working on this:
  • Create a 2.5D fighting game that utilizes Unity3D's Animator class
  • Make the game work online using Unity's new(er) high level networking API
The game idea, entitled Golem Jox 2, is based off an old jam week project I did at Schell Games a few years ago.  The overall design is that by switching various body parts, legs, arms, etc., the player would have different moves and attacks available.  Though this would be a balancing nightmare -- a nightmare I'd at least attempt to live through -- it could have served as a unique way to allow players to create a fighter that fits their particular play style.  Unfortunately, I didn't get time to integrate the UI needed to allow for swapping.
What I did get to focus on, instead, was the networking aspect using UNet, Unity3D's networking API.  This post is about that game prototype, some lessons I learned, approaches, etc.

Deterministic Approach

So as much as I like Unity3D, one issue I have is that it doesn't feel precise at times, meaning if the game is running at a certain frame rate on one machine it'll yield results different from those of a machine that runs better or slower.  There are ways to resolve this issue, such as using Time.deltaTime, but sometimes there can even be issues with this such as floating point precision issues.
With this goal in mind, my first task with this was to create a way to update the game in a way that would be consistent regardless (or nearly regardless) of any slowdown.  To accomplish this, I used something that resembled the following in my Update method:

// The amount of time, in seconds, that must elapsed before updating the game.
float frameRate = 1f/60f;

// The current frame the game is on.
uint currentFrame = 0;

void Update
     time += Time.deltaTime;
     while  (time >= frameRate)
          time -= frameRate;

Now, this is similar to FixedUpdate, which is supposed to be consistent; however, I suspect that sometimes a frame can be skipped, or the game can be running slow and the value of currentFrame wouldn't increment when I want.  I'll explain the importance of currentFrame later.  Anyway, within the method, ManagedUpdate, I update the players, their physics, any other collision testing I need to do.  I even manage their Animators, which can done by disabling the Animator Component and calling animator.Update(frameRate).  This allows me to know that the Animator is updating consistently and if a few frames need to be skipped, these are skipped in the Animator.

Animator + Mecanim

When Mecanim / Animator, Unity3D's updated solution for playing animations, was announced, my initial thoughts were very skeptic.  I was having some issues and the editor could be better for it; however, its ability to allow for animation retargeting, animation blending, and IK functionalities made it something I really wanted to do for this game.
The following is what the initial state machine of my Animator Controller graph looked like:

I'd show more if Unity let you zoom out...

For this prototype, I used a lot of asset store animations such as and  What was great about this was that, because of humanoid targeting, I could use a variety of animations and have them blend smoothly with little to no popping.  Another aspect that Mecanim made useful was StateMachineBehaviours.  StateMachineBehaviours have entry, exit, update, movement, and inverse kinematic methods that can be overwritten.  I usually just used entry, exit, and update.  Originally, I tried using internal variables within each StateMachineBehaviour such as tracking the frame and assigning an exit frame.  There were some issues when you try and enter the same state and use this method, so I decided to use a parameter instead.  Also, it's important to note that Exits happen after Enter if a transition is utilized.
In addition, prototyping is a great time to just experiment with fun things in general.  I did this with the smear effect, which was a vertex shader I found on Twitter:


So, for a long time, online multiplayer has been very intimidating to me.  In a previous game, Battle High 2 A+, I didn't even attempt to try and do it as I felt I wouldn't be able to do the job properly.  Now, using UNet, I decided to try my hand at prototyping online multiplayer with this.  My goal wasn't just to use UNet's basic functionality though such as SyncVars and NetworkTransforms, but instead just send Commands and use RPC Client calls to try and simulate a rollback system similar to GGPO -- I knew I wasn't going to get anything that sophisticated in less than a week, but I still attempted it for my prototype.
The main goal when doing this is that the local player should feel like their inputs are immediately respected and reacted to.  The problem with this is that when the player immediately changes state, this needs to be sent to the server and then to the opposing client.  Naturally, there will be delay, even if just a few frames and this needs to be dealt with properly.
This is where the currentFrame variable came into play.  My thinking was that I would record the frame when the player changes state, send it over the network and compare the opposing client's current frame with the received frame and then fast-forward that character that many frames.  This, surprisingly, actually got me decent results.  They were FAR from perfect, but I was able to get the game running over the network.  Note, I did this with a StateMachineBehaviour that called a Command upon entry depending on the state.
Most issues would arise when the two players would get out of sync; for example, if the delay was bad -- about 8 or more frames -- some attacks would not register on the opponent's side.  One reason for this could have been that, when I received the values, I wasn't checking attacks when doing the fast forward process; just fast-forwarding the character to make sure the positioning was accurate.  I also wasn't rewinding the entire game this many frames; something that could have resolved some issues.
Anyway, after only three days of focusing on the online aspect, I had something playable over the internet.  It wasn't perfect, but people were able to play the game on two separate machines with relative accuracy.


In conclusion, I learned a lot doing this prototype.  To be honest, I'm unsure whether or not I'll continue working on this, but the hope is that when I start a new fighting game project, I can carry over the lessons I learned from doing this.  I'd like to also try to use more of UNet's functionality to try and make the online components such as SyncVars and NetworkTransforms to try and make the networking more reliable.
In addition, I'm unsure that I'll be able to use this approach if I ever try to add networking to Battle High 2 A+, but it could be possible in the future.  My only issue is that because I'm using Unity3D's networking solution and am not a seasoned network programmer, that whatever work I ever do, especially in this genre where online play is highly scrutinized, won't be great.  This, however, does take practice and that practice will only come by making (and eventually releasing) games that try and utilize this functionality.
Anyway, if you'd like to play this game, you can download the build here: .  Enjoy and please let me know your thoughts.