network


It’s 2018!

It’s officially 2018!  With a new year comes new hopes and dreams and ambitions — 5% of which will probably get accomplished or worked towards.  Despite this, I think it’s still important to establish these goals.  Anyway, this post will go over how 2017’s game development went and things I’d like to shoot for in this new calendar year.

Battle High 2 A+

I started 2017 by showing Battle High 2 A+ at MagFest.  It was an exciting trip, although a little stressful.  I really enjoyed showing the game off to potential new players; in fact, I did again at the Pittsburgh Retro Gaming Convention in March followed by a small tournament at ReplayFX in the summer.

Besides showing the game off, I also wanted to try and get a new character in the game; however, I got distracted by TrueSync, which I’ve mentioned in previous posts and will discuss later in this one.  The big issue is that adding new character isn’t cheap, especially this one as all of the sprites aren’t finished.  I could try and release the character as paid DLC to make up for some of the cost; however, that involves extra work — integration, VO, new music, etc.  I’m not going to say that the new character won’t come in 2018; however, it’s definitely lower on my list of priorities.

In 2017, however, Stream Greenlight was replaced by Steam Direct, allowing indies to publish their game onto Steam for a small fee, so I spent a small part of November and December releasing the game on Steam, so though I didn’t get a new character into the game, I did get it released on a new platform to hopefully expose the game to more players.

I’m not sure what my goals for Battle High 2 A+ will be in 2018.  I’d love to get the new character done, update the 3D backgrounds, or get netplay working; however, these are all currently low priority to me.  I’m super grateful for the fans of the game, and I know I could do a lot more to make the community grow; however, I want to move onto new ideas, a lot of why the TrueSync stuff was such a distraction though a very good one.  I’m not going to say the game is dead and that I’m never going to work on it, but I’m not going to promise tons of new content or changes either.  I think the most I will do is work to make sure all versions — itch.io, Game Jolt, Steam, and Xbox One and all consistent and up to date.

Project MerFight

Project MerFight was a rough part of 2017.  For awhile, I wanted to work on a tactics RPG with fighting game elements.  I learned a lot about art, pathfinding, and more; however, as I worked on the project, I just felt overwhelmed, that it was too big for me to take on by myself, that I was focusing on areas that just don’t really interest me that much.

With that, I made the difficult decisions, despite months of work, to put the game on hold indefinitely.  I think what this helped me realize is that I should really only focus on games and aspects of them I’m really passionate about, until I’m able to — if ever — build a team to help me in these others areas.  As much as I enjoyed Namco X Capcom, which was serving as a lot of my inspiration, there were features I just wasn’t excited to implement or felt overwhelmed trying to.

Though it feels like a failure, I think what I learned will ultimately help me and future ideas improve.  This if, of course, if the information is well documented, something I also want to improve in 2018.

TrueSync

In a previous post, I mentioned TrueSync, a online rollback framework for Unity3D by Exit Games, the company behind Photon.  Although not perfect — it’s still in beta — I think it has great potential to democratize deterministic online gameplay for a lot of developers that, like myself, find it rather difficult to approach or are unsure where to start.

I spent a lot of time working and experimenting with it.  I made a prototype fighting game using it called ProtoFighter; however, I also want to learn and improve my art and animation skills instead of a majority of my assets being from the asset store.  I’d really love to get my own fighting game framework fleshed out so that I can create new games using TrueSync more quickly.  This will take some time; for example, I refactored a lot of ProtoFighter so I could make it more extensible with other types of games, and there is still a lot of refactoring work to do.

2018 Goals

So 2017 doesn’t sound too exciting.  I focused on showing off Battle High 2 A+ and learning TrueSync and chose to “pause” a game idea; however, I did a lot of other things too, but they are all small prototypes, difficult to organize in any meaningful way.  Battle High, Project Merfight, and TrueSync are probably the most important when it came to my independent game development.

Anyway, here are some goals I’d like to aim for (not necessarily hit) for 2018:

  • Develop my fighting game framework and create a prototype with TrueSync
  • Show off a new game, prototype, or Battle High at another show, maybe one not based in Pittsburgh
  • Submit a new game idea (not a finished game) to Xbox One for the ID@Xbox program
  • Better self-care — sleep & exercise more, eat healthier, etc. (really, these are life goals but a new year always reminds me that I should be doing them as I get older)
  • Better my visual art skills — shaders, Substance, animation, etc.
  • Write more posts and/or tutorials as well as try dev streams.
  • Submit a talk to a conference — and do it NOT on the last day for submissions

This isn’t the most exciting list, and I know I won’t hit all of these.  Every new year, however, reminds me to step back and really observe and update and pivot on what I’m focusing on.  Since one of my goals is to write more posts here, hopefully I’ll write about my progress soon!


ProtoFighter Dev Blog 01 4

So for the past couple of months I’ve been working on a new fighting game prototype.  After discovering TrueSync by Exit Games, I’ve been trying very hard to create a new fighting game with it.  Again, one of my biggest regrets with Battle High is that I was never able to implement multiplayer before its release.  I definitely feel that TrueSync could definitely help me achieve that!  Anyway, I decided to write a little bit about the game and what I’m trying to do with it.

ProtoFighter

I chose this name because what I made was a prototype, and I wanted to make this clear.  I decided to use only assets from the Unity3D Asset Store, which TrueSync already is.  This includes my characters, audio, and more!  Here is a short list of some of the assets I am using:

Goals

I had several goals while making this prototype.

Learn TrueSync With a Focus on a Fighting Game

My first goal was to learn TrueSync and make a game using it.  I think I accomplished this.  In fact, it’s not my first TrueSync experiment.  Diamonds Not Donuts, a small game I released on itch.io for free, is!  That being said, for ProtoFighter, I wanted to focus more on fighting games and various issues concerning them.  ProtoFighter has a lot of gameplay functionality that most fighters do — blocking, jumping, attacking, special moves, supers, rounds, etc.  Obviously it’s missing a lot to be a complete fighting game package — single player modes, balance is a MESS, more characters, etc.  Again, for a pre-pre-pre alpha, I think I achieved my goal, but of course, when it comes to TrueSync, there are still a ton of questions I have and hope to continue to answer them as I expand upon this prototype.

Make a Fighter That Is Slightly More Accessible Than Most

Though not TrueSync related, I’ve always wanted to try and make a fighting game that was a bit more accessible to the average player.  Maybe not as extreme as Fantasy Strike, but something that I could still explain relatively easily.

In ProtoFighter, though I sadly haven’t released a tutorial yet, I tried to do this.  Essentially, instead of performing quarter circle attacks, I simplify this to forward or back plus an attack.  Now, a lot of people would immediately say this oversimplification could cause issues such as instant dragon punches or anti-airs, so to solve this I did two things.  Firstly, all initial moves such as forward+punch have rather long start-up and are reserved for moves like overheads or projectiles.  Then, every special move has a “secondary” special that branches from it.  For example, forward+punch may begin an overhead but then pressing up before the attack activates, a secondary attack, probably an anti-air attack, would be performed.  The hope is that performing the initial move and then the secondary move will require just enough time and frames that the anti-air move won’t be so instantaneous.  Maybe this won’t help, but the idea it’s simple to actually perform an attack, but requires some dexterity and memorization to cancel one move into another properly.

A secondary idea I then had is to still allow players to perform attacks using quarter-circles; however, these players would be rewarded with a slight meter bonus, so you don’t have to perform moves properly to compete or play, but players who can are rewarded slightly for taking the time and effort to perform more complex inputs.  I can’t really tell if this input system will be good or not until someone tests it, which is why I released the prototype.

Create a Framework

My third goal was to begin creating a framework so that I can create future titles, TrueSync or not, more quickly.  A lot of games I work on are usually fighting game influenced, so I wanted to construct a framework so that creating future titles, whether 2D or 3D, would be easier in the future.  Though not perfect, I definitely tried to abstract more of my classes and functionality and believe I could quickly go from this 2.5D fighting game to a 3D game rather quickly with few changes.

TrueSync Tips

So, for this fighting game, I learned a good amount about TrueSync.  TrueSync attempts to be deterministic, allowing a local player’s inputs to be immediately respected, passed over the network, and compared to the game’s state and rolled back if there are inconsistencies found and resimulated.

The issue though is that Unity3D wasn’t built to be deterministic.  Its use of floats and random system for example can cause various issues.  It’s animation system also isn’t deterministic so trying to perfectly simulate results across two machines can be rather problematic.  Anyway, here are some tips I found were helpful for completing my prototype.

Note, these tips were written for Unity3D version 2017.1.1f1 and TrueSync version 1.1.0B.

Don’t “Press” Inputs

TrueSync uses a unique method to capture and send input, it’s called OnSyncedInput.  Here’s an example of how it works.

public class MyTSClass : TrueSyncBehaviour
{
    public override void OnSyncedInput()
    {
        TrueSyncInput.SetBool(0, Input.GetKeyDown(KeyCode.Space));
    }
}

So in the above, TrueSyncInput is used to pass inputs over the network.  The first argument is a byte, used as a key.  I’m just using 0 for now, but if you use multiple,  you should probably assign them to a constant.  Then, I’m using Input.GetKeyDown to send a bool if space is down or not.  One issue with this method is that it is performed similarly to OnFixedUpdate so calls such as “Input.GetKeyDown” don’t work consistently as when OnSyncedInput is called, Input.GetKeyDown is sometimes missed.  To resolve this for button inputs, here’s what I did:

public class MyTSClass : TrueSyncBehaviour
{
    bool hasPressed = false;

    public override void OnSyncedInput()
    {
        bool singlePress = false;
        if (Input.GetKey(KeyCode.Space))
        {
            if (!hasPressed)
            {
                hasPressed = true;
                singlePress = true;
            }
        }
        else if (hasPressed)
        {
            hasPressed = false;
        }

        TrueSyncInput.SetBool(0, singlePress);
    }
}

This change uses a bool that is set to true when OnSyncedInput is executed if the space bar is currently down. The toggle is then reset once the spacebar is no longer being held down.  The bool that is actually pased in TrueSyncInput.SetBool is only set if the keyboard is down AND hasPressed was false before being set to true.  This way, the first entry of TrueSyncInput will be true for only one execution of OnSyncedInput.  This should prevent any issues with OnSyncedInput missing an input as the average button press usually occurs for a few frames.  I don’t use this method exactly in ProtoFighter, but the idea is similar.  Instead of doing separate Booleans for each input type — up, down, left, right, etc. — I use an integer and bitmasking to change it during OnSyncedInput.

Treat TrueSync Like A Separate Engine

This sounds silly as Unity3D is a game engine; however, to make TrueSync’s determinism work properly, you have to use a lot of unique structs and classes that it introduces.  There’s FP, or FixedPoint, for float values for example and TSVector for Vector3’s.  Also, TrueSync has its own Transform class (TSTransform) that does not have all the functionality — at least now — that Unity3D’s Transform class has.  You can’t use children the same way and certain methods such as those that convert transform information from world to local space are missing.  Overall, you can’t just take a finished game and integrate TrueSync into it quickly.

One trick I had to do, for example, was figure out a way to align character hit spheres to certain joints.  In a normal setting, I could just use the following:

Animator anim = GetComponent<Animator>();
Transform t = anim.GetBoneTransform(HumanBodyBones.Chest);
Vector3 chestPos = t.position;

However, one problem is that this creates a Vector3 and even though I can convert the position to TrueSync’s Vector3 equivalent, a TSVector, they may be different values between the multiple players due to floating point precision errors.

To resolve this, I built a tool to cycle through my animations and store important point information as a TSVector  in a ScriptableObject.  I don’t save the position though; instead, I save the vector from the center to this point.  So, to get where the chest would be in my animation, it would be something like the following:

TSVector localChestVector = GetChestPosition(frame);
TSVector worldChestVector = tsTransform.position + tsTransform.rotation * localChestVector;

So, in the above, I’ve gotten a local vector for my chest position and then used the position of my player and rotation to define the world position for my chest now.  You’ll also notice that I’ve used a frame.  This is because a lot of fighting game interpret things as frames, and I believe interpreting your deterministic game in TrueSync is a lot easier to understand through the concept of frames than through time.  Even though my 3D animation is made up of curves, I store different bone information in these TSVectors so they can be referred to later regardless of the rotation or position of my character.  I also do a similar technique for moving a character by their root animation without actually having the Animator drive it.

No Animators — At Least How You Think

As of right now, TrueSync doesn’t have an Animator class.  For fighting games, this can be an issue since animations and the accuracy of said animations is so important.  To handle this, I did the following:

  • Stored all of my animator data in a separate data structure, mostly just my transition parameters and conditions
  • Muted ALL of my animation transitions
  • Disabled the Animator Component
  • Use Animator.Update(float)

So, even though the animator is disabled, Animator.Update(float) still allows the Animator to be updated.  Even though you do have to use a float instead of an FP, the amount I update is determined by the frame I’m supposed to be on, so my update function looks like this.

FP syncedFrame;
FP localFrame;
Animator anim;

private void Update()
{
    anim.Update(((TrueSyncManager.DeltaTime) * syncedFrame - localFrame).AsFloat());
    localFrame = syncedFrame;
}

So, here I have syncedFrame which is the frame of my animation that is set during OnSyncedUpdate.  Then I substract the syncedFrame to the localFrame and convert it to a float value.  I then set the localFrame to the syncedFrame.  I used FP instead of integers in case I want to play the game in slow motion.  This still needs some tweaking, however, but it gets the general idea across.

Overall, using Animator.Update(float) is great because it allows me to still get a lot of the functionality of Animators

  • Transition blending
  • IK
  • Mirroring
  • Humanoid rigs

But with more control.  This is one reason all transitions in the Animator are muted actually.  Because I don’t want transitions to happen automatically and switch states suddenly if there is rollback.  Doing it more manually allows me to switch state when I need to.

Just one small part of my AnimatorController; the red arrows show that my transitions are muted.

Anyway, the future of ProtoFighter is uncertain.  I will most certainly not release this as a full game, but instead a fighting game demo.  I know in this current 2D version I’d like to do the following:

  • Add rooms and lobbies instead of the “Ranked Match” system it uses now
  • Add stage select
  • Add an interactive tutorial
  • Balance and clean up the existing characters, Protolightning and Protaqua
  • Start looking into AI and single player modes

Overall, the goal with this game is to eventually get a framework to a place where I can experiment with a variety of gameplay styles and making something myself later down the road, hopefully sooner rather than later.  Maybe I can even use this to integrate TrueSync into Battle High 2 A+ — though I make zero promises.

ProtoFighter is available on itch.io & Game Jolt for free!  If you download the game and play them, I’d love to hear your feedback — but make sure you try the multiplayer as that’s the main area I’m trying to focus on.  Also, if you have any questions on TrueSync, I’d love to try and help as I think it’s a great asset and can help give online functionality to a lot of new indie game content — fighting games and other — in the future.