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.

Wednesday, May 25, 2016

Art Prototype Dev Blog 03: Tired of Attire

So, for the next part of my character, I decided I needed a bit of clothing.  Clothing usually hasn't been a big issue for me; however, there are a lot of aspects to it that can quickly make the pipeline I'm trying to develop rather challenging.
Essentially, I have a few options, which I explored:
  • Marvelous Designer
  • Use iClone Character Creator's clothing
  • Model Clothing from scratch
  • Find existing clothing

Marvelous Designer

I really liked Marvelous Designer at first.  It's a cool program for designing clothing; however, I eventually found, once the coolness wore off, that it just isn't really for games and it just really isn't that much faster because of the required knowledge needed sew clothing together.  In addition, it's expensive, and with 3D Studio Max having its own version of Marvelous Design built into it with Garment Maker -- with the caveat of it being far inferior -- I decided to pass on this program.

iClone Character Creator

One nice aspect of iClone's character creator is that it comes with a decent amount of clothing.  It doesn't have every type of costume -- martial arts, occupational, etc. -- but it has enough casual clothing that you could probably construct usable outfits for most things.  In fact, it uses Substance Designer materials to edit clothing.  I didn't really dive into this, but if I want to make a shirt with a certain type of pattern or decal, this probably wouldn't be that challenging.  The bigger challenge would just be making the textures -- an area I didn't touch yet because my texturing skills are rather weak.
My only issue is that the clothing is rather high poly, a pair of jeans being about 12,000 triangles.  Again, for a next gen. fighter, this probably isn't a big deal, but I still have the feeling I'd have to do some clean up in most other cases.
Another issue that came up is that this clothing will always look the same, so I probably will need to do some adjustment.  I thought to try and use Blendshapes to make the pants a little more baggy, this way, I wouldn't have to reskin the entire thing.  Unfortunately, because of an issue with smoothing groups, when the jeans were reimported, the smoothing groups were eliminated, making it look like something from Virtua Fighter.

Though interesting, that square, patch pattern is not intentional.

Modeling Clothing from Scratch

When I say "from scratch", I really mean one of two things.  One is modeling clothing from scratch, something I'll probably need to use from time to time for more complex attire; however, for some clothing, I'll sometimes just take existing parts of the mesh, duplicate, remove geometry I don't need, and boom -- I have a pair of gloves.  This technique isn't perfect for all clothing, but again, good for tight, form-fitting clothing or gloves.

Glove and inner sleeve made by just duplicating parts of the original mesh.  Needs texture work, but for an initial pass, works.

Find Existing Clothing

Since I'm making a fighting game character, I wanted to try and make an alternate costume.  I decided to try martial arts attire; however, I didn't want to spend hours modeling it from scratch, so I decided to look for one.  After failing to find one on Turbosquid, I found one on a site called CGTrader.  It had nice edge flow, and with some minor adjustments, I was able to use skin wrap to get it onto the character.  The skinning isn't perfect, but with the amount of modeling time saved, I could definitely spend a little time adjusting the skinning.  It was about $50, and it's not something I would want to do for EVERY outfit, but I think this approach isn't bad for when I need an article of clothing for a character quickly.

Untextured, but this took very little time to fit and skin; the arm pits verts need work, but in the amount of time it'll take to fix that, I'd probably barely have the pants model if I were to do it from scratch.

Again, the goal of this prototype is to see if making a character by myself in a short period of time (1 - 2 weeks) is viable.  So far it's shaping up to be.  Here are some of the biggest challenges I've faced thus far:
  • Hair!  I need to come back to this, but decided to take a break.
  • Closing gaps -- when working with clothing, a lot of it is open, but Unity culls faces based on the shader -- and not culling (making it double-sided) increases render processing -- so you get these strange instances where the inside of a sleeve becomes see through.  There are several techniques for preventing this, but it's a bit of extra work, and I wish I didn't need to do it at all.
  • Texturing.  I'm going to try and use 3DCoat to see if I can texture clothing in a way that doesn't make me want to abandon the project altogether.
  • Will it animate?!  Once I get the entire character's look figured out, I have to see if my biped rigging script will do it any justice, will the clothing deform in a way that looks decent, etc.?
  • Shaders -- I'm not sure if I should use Unity's built-in shaders or my own; however, one thing I learned from past projects, is that when figuring this out, you should do the textures simultaneously as some shaders will change the setup of you textures -- channels, normal map use, etc.

Tuesday, May 17, 2016

Art Prototype Dev Blog 02: Hairy Situation

So I spent the weekend working on the art prototype mentioned previously.  I decided to try and make a 3D version of this character that I concepted over a year (maybe two or even three) ago.

Why am I not a professional concept artist you ask?  This, this is why.  Now stop asking!
I'm serious about this prototype, so I even made a spreadsheet, splitting up task.

I was pretty excited, getting a pretty decent body and face done in iClone Character Creator relatively quickly.  I knew it wasn't going to look exactly like my concept, but I had the major components figured out.

I did learn that iClone Character Creator spits out a lot of textures, at most four -- diffuse, spec, normal, and alpha -- per part:
  • Head
  • Body
  • Eyes
  • Transparent Layer of Eyes (which I'm tempted to remove)
  • Upper Teeth
  • Lower Teeth (which aren't the same size as the upper)
  • Tongue
  • Fingernails
  • Toenails
  • Eyelashes
This is one aspect of iClone I like over Mixamo Fuse.  Fuse has less textures, but you still had to make multiple materials since the eye lashes -- which needed transparency -- were on the body and face's texture.  I'm pretty sure using cutouts would have sufficed though.  Anyway, I wrote a script to make one texture's alpha channel the red (or any channel) of another texture.  This is important because if I plan on using Unity 3D's built in shaders, they require the alpha channel to be utilized.  For diffuse textures, the alpha is used for transparency; in the specular (or metallic) it's used as the texture's smoothness.  This is how the character looks in Unity3D after playing around with various work on this:

The top image is how the character looks with the built initially exported spec map, which has an alpha of 255.  It's extremely reflective and unnatural.  I lowered the alpha to 64, resulting in the lower image, a lot less reflective and smoother.

After getting the base model figured out, I, instead of doing clothing, decided to try my hand at hair...which quickly made me think...

At the same time, it made me realize why so many games have bald or short-haired characters.

Anything else is expensive -- whether that's the amount of time needed to create decent looking hair or the rendering power needed to deal with the transparency created by using the alpha plane technique.
It was also at this time that the hair in most character creators -- Fuse and iClone CC included -- are just not amazing.  Don't get me wrong, they are much better than I could make as I soon learned trying to make my own, but they just feel lacking compared to other games.
For myself, the problem is that there are a lot of different ways to do hair and a lot of the tutorials I found were for rendering realistic hair for animation, not games.
So, for my situation, here are some possible solutions:

Use What's Out There

Fuse and iClone do come with some hair, and, though I don't love it, it is usable.
"Messy" hair exported from Fuse and put on my character with minor modifications.
I could probably take this hair and manipulate it enough to get various styles.  There are also stores and other resources out there I could use to find new hair.

Learn to Model Hair

As I mentioned previously, there are dozens of tutorials out there.

These are just two of many that differ on skill, time, programs, etc.  I tried modeling my own, but I think I came across a bigger problem:  My concept isn't really complete.  It's just a single pose of the character.  I think, because I knew I'd be using a character creator, that thought I wouldn't need a character sheet with front, side, and back views; however, because the hair is rather atypical, I should have clarified it.
Because this is a prototype -- and because I was in a bad mood pulling my hair (and his) out -- I decided to just use Fuse hair to improvise a new haircut.  This is what I came out with.  I'm still not in love with it; from some angles it looks odd.  The biggest problem I discovered is that rendering hair is rather difficult.  It was particularly frustrating because in Fuse, the hair looks fine, but they are using a unique shader that isn't built into Unity.
Not only does this need specular adjustment, but there is odd Z-fighting, particularly at the front bang
Despite my efforts creating various shaders in Shader Forge, I still couldn't quite get the hair to look right.  Fortunately, I was able to find a shader in the Unity asset store, Advanced Hair Shader.  I had to get a version compatible with Unity 5; fortunately, the developer was very quick to respond to my email.  Though, despite getting a good version of the shader, I still wasn't feeling it.

The parameters need a lot more adjustment, but the Z-fighting is gone at least.
As I continue these characters, I'm going to avoid using alpha transparency in my hair.  It'll probably require more triangles in the meshes, but I think it'll create a better look overall, especially for the more cartoony, bright look I'm going for.  Also, when working in Unity, I try to prevent myself from fighting with the engine.  I'll either make a workaround -- as in with using my own simplified physics solutions -- or work with the engine.  It obviously doesn't work great with alpha transparency, so I'll avoid using it when I can.  I was also having some luck using muscles in 3DCoat to make hair -- retopologizing was inducing some rage though -- and I want to explore that further and see if that can create nice, sculpted hair.  I know I can't use that for everything, but it's worth a shot for sure.Overall, I hit a bit of a bottleneck in the character creation process.  I should have probably done attire instead of hair.  Admittedly, attire will create similar problems and have its own questions like how do I close gaps?  Do I use clothing provided by Fuse or Character Creators or use Marvelous Designer or something else to make clothing?  The most challenging part will most likely be tying all the parts together, making them coherent and consistent, but I'm going to keep trying -- at least for a bit before finishing the next Battle High 2 A+ character, Beat.

Thursday, May 12, 2016

Art Prototype Dev Blog 01

So for the last month or so after pausing Project Merfolk and besides new character work for Battle High 2 A+, I've been trying to work on improving my art skills and my art pipeline.  I wrote a script to convert any rig to the 3D Studio Max biped

I then did research and experimentation with various other programs such as iClone, 3DCoat, and Marvelous Designer, all with the goal of becoming a better and self-sufficient artist.  I've been wanting to start a new project, but since I've been doing all of this art exploration, I thought that it would be a good idea to, instead of making a gameplay prototype, make an art prototype, a prototype of the way the art in my game would look and feel.
This is an important step for my next game, regardless of what it is, so I'm going to start this now.  I'm going to do it live!
Well sorta...and with a lot less anger

The first thing I need to do is determine the look I am going for.  There are several ways to go about this.  One is to determine my strengths and weaknesses.  I know photorealism is definitely not an option.  It takes too long for me, and there are certain skill sets that I don't possess and would take way too long to try and develop -- high res sculpting, complex retopology, etc.  Another tool to help with this is to develop a style guide; from what I know, a style guide is similar to a game design document, but focuses solely on the visuals of a game and usually done very early in a game's production.
I'm going to develop the style guide for the look of characters for my next game, Cupkick.  The first part, is on a scale from realism to cartoony, how do I want the characters to appear.  The following image shows a character made in iClone Character Creator.  It uses the Slim morph -- one I find rather cartoonish and like -- and ranges from no (0%) influence to 100% influence of this morph.

Based on this morph, I want something a bit higher than 25% but not any more than 50%.  The game is going to be a 3D fighter, so characters will be a big focus.  I like this range because it's not 100% realistic, but the 100% is a bit too cartoony and looks weirdly unnatural.  This could be due to the use of a realistic texture on a cartoon-proportioned model. (Note, I'm going to edit these textures before using them in game.)  Regardless, the previous image is just one of many types used in a style guide.

Another part done for style guides is just the use of finding existing work and stating what aspects you want and what aspects you don't.  Here are some games I'm looking at for influence:

Team Fortress 2

Though not a fighting game, TF2 has a unique style that has many aspects I like such as strong silohuettes -- important in a figthing game to help identify moves and simple yet bright colors.  One aspect I don't like is that the proportions are a bit too on the cartoon side for what I'm shooting for.

Dead or Alive & Tekken

I've been a big fan of the Dead or Alive and Tekken series.  I do like the way the characters look.  There's an anime influence in their faces; they aren't realistic so they avoid an uncanny valley look, but they are still strong.  Also the game is bright as a whole.  The negative takeaway is that the world and shading as a whole is a bit too realistic and sometimes silhouettes can get lost.

Marvel Vs. Capcom 3


I really like the graphic style of Marvel Vs. Capcom 3.  The characters are a great mix between realistic and comic style.  The graphic style is a bit too harsh and flashy for what I'm shooting for, gameplay elements can get lost sometimes.

Super Mario Galaxy

Super Mario Galaxy is a bit too cartoony for what I'm shooting for; however, there are aspects of the game's looks I'd like to capture, particularly its cleanliness and bright colors.

Street Fighter V


It's contested, but I think SFV is a great looking game.  The character models, though not all beautiful, are great because they have strong silhouettes.

So, comparing these, I sorta want the following in my game:
  • Bright colors
  • Easy to discern silohuettes
  • Slightly unrealistic characters
And here are some elements I don't want:
  • Comic book style / harsh outlines
  • Photorealistic graphics (in characters AND environments)
  • Cartoony proportions
My biggest issue, of course, is that achieving this level of art fidelity on my own is going to be very difficult (if not impossible).

So what is my goal?

My goal is to create one character from scratch for this game with the following goals in mind:
  • Determine how long creating a new character will take; for example, if it takes 2 months for one character, this is way too long, and obviously i need to invest in other avenues to create characters.  
  • Develop and polish a pipeline for creating characters
  • Achieve the look of the characters I am developing
  • Have something more visually appearing to show off early to gain excitement
I mention the last one because I've felt for my previous prototypes that because they usually have prototype are or look boring, usually get ignored or I get little feedback on them.  I want to see that, if I start with stronger visuals first, that I can get more interest in what I am working on early.
In addition, here are some other, more specific questions I want to answer:
  • How am I going to do hair?!  I like planar hair, but it usually takes a long time to model.  Can I find a starter base asset somewhere and work with that?
  • Will the iClone Characters be good enough?  Too high poly?  Too recognizable?
  • How will I do clothing?  All iClone?  Marvelous Designer?  Model from scratch?
  • What shader / materials will I use?
  • Will these characters run well in Unity3D? On Xbox One?  On PC?  On mobile?
Anyway, this is just a short blog post about what I'm working on next.  Hopefully I'll be able to show progress as I continue working on it and smoothing out the pipeline.

Tuesday, April 26, 2016

Reallusion Character Creator

Taking a break from Project Merfolk, I decided to do more preproduction level work.  One thing about Project Merfolk I didn't really establish was a good character pipeline.  I was using Mixamo Fuse, which I liked for character creation, but I was having a few issues:
  • After its acquisition by Adobe, the Steam version of Fuse seemed abandoned; I'm not a fan of Adobe Cloud and didn't want Adobe Fuse -- the next iteration of Mixamo Fuse.
  • The amount of customization, though strong, left a lot to be desired at times.
  • Exporting a character to the website to download your auto-rigged Fuse model, though great, was also a bit slow at times and a paranoid part of me is always nervous when they'll shutdown that server.
Anyway, for those reasons, I wanted to try and find a different character creator.  I stumbled upon Reallusion's Character Creator (CC), an extension of their iClone product:

From their website.  I get what they are going for, but still, a bit creepy, right?

There were a couple of things I liked based on the preview and a quick trail period:
  • A lot more selection and variety for morphs
  • The ability to easily make new morphs
  • Exported characters are auto-rigged with facial blendshapes AND twist bones
So after downloading the trail -- and eventually purchasing it -- here are my notes of pros and cons

Pro:  Lots of Different Morphs (but could be more flexible)

Like I said earlier, there are a lot of different morphs and there are even more that you can purchase -- which I did.  The only thing that annoys me is that every morph is limited to 0 and 100.  I've used similar programs where these limits don't exist; however, I think this is done so that other parts of the program, such as clothing and auto-rigging, are more stable.

You don't have to go to ZBrush, but it's probably easier to edit in there than some programs.

Con:  The controls are TERRIBLE!

Admittedly, I am a bit spoiled (or used to rather) by 3DS Max's controls, so the controls for the Character Creator were a bit foreign to me at start, or at least I haven't gotten used to them.  For example, the camera controls are:

Z:  Pan Camera
X:  Enter Camera
C:  Rotate Camera

To my knowledge, there isn't a way to edit these either, which is rather irritating.  Also, there's only one viewport, so you have to switch to the camera view to see your character from all angles.

Pro:  Nice character models

Now, every character creator I've ever used always has a certain "look" to their characters something that makes them seem cheap and easily recognized, similar to when people are like "Oh, this is obviously a Unity game".  In my opinion, similar to when buying an asset of any kind, you shouldn't just USE the character you get directly from the creator if you want to avoid this; however, I feel like this CC can definitely get you a look closer so you don't have to do this.
For example, if you want characters to have more expressive or larger eyes, there's probably a morph that exist for this, OR you can make your own that achieves this.
Also, since they use Allegorthmic Substance materials, you can customize a variety of textures for your characters by just tweaking a few sliders and substituting a few maps.

Pro:  Good rigs -- though a bit advance

The rigs you get when you export a character are pretty good and they import nicely into Unity3D -- though the thumb and index fingers get mixed up when setting up a humanoid avatar.  They have arm and leg twist bones -- something Mixamo Fuse does not have -- though animations on these bones won't export automatically if you are Humanoid avatar rig in Unity, but I'm sure a script could be made to treat them similarly to 3DS Max's biped twisting bones.
Unfortunately, they do not have facial bone rigs -- unless there is a setting for this I missed -- but they do have blendshapes for various expressions.  The reason I say setting is that the rigs export with a bunch of dummy objects that would indicate that facial rigging does exist.
In addition, I only have to export to a propriety program instead of a proprietary site like Mixamo to get and use my rigs.

Con:  Meshes are a bit heavy

In addition to having a lot of bones in the rigs, upon export, the average character -- depending on how much clothing you dress it in, is about 50K triangles.  If you are making a console or high-end PC game or a game with few characters on screen at any given time, this is probably fine and can be fixed with LOD meshes or retopologizing.
In addition, there are a LOT of texture maps generate with each character, for example, there is a separate texture created for a character's nails and teeth as opposed to combining them.  This may be parameter that can be adjusted similar to Fuse, but I haven't found it yet.

Con:  Little clothing and hair to choose from

This was a problem in Fuse too, but there are few pieces of clothing to choose from and even less hair, and, unlike Fuse, there doesn't seem to be a pipeline for creating your own clothing.  I can understand why as there is probably lot more setup to clothing besides just modeling it.  I do, however, think there are plans to add this feature eventually.
Here is some clothing available from start (with the essential bundle):
  • Shirt
  • Tanktop
  • Jeans
  • Joggers
  • Skirts
  • Blazer
  • Sneakers
  • Boots
  • Sandals
  • Heels
And with the use of procedural materials, you can create a huge variety of outfits with little modeling effort.

Undecided:  Requires / Comes with iClone

So CC is really an extension of another tool known as iClone, which is for 3D animation.  From what I gather, it's does everything that 3DS Max's biped or Unity's human avatar does.  Every character has a standard rig and then you import animations into the engine.  
It has control issues similar to CC and it doesn't really seem to be intended for animating IN rather than using mocap or premade animations and adjusting them for your characters a bit -- blending, putting on multiple rigs, etc.  The package I obtained does include a tool for capturing mocap from a Kinect; however, I haven't tested this out yet; as I have yet to purchase the connector needed to hook a Kinect to my PC.

Con:  Relatively Expensive

No one likes talking money, and CC is free as part of a trial to iClone, but to export a character created in CC, you have to purchase an iClone license.  Though perpetual, it's rather expensive, about $700 -- and this is a sales price that I think ends soon.  In addition, the special morphs were another $150.  I was cautious, but I ultimately feel this was a worthwhile purchase as 3D character work like this is something I want to utilize in my future work.  This is what I got:
  • iClone
  • 3D Exchange (tool used to go between iClone and other programs)
  • Character Creator
    • Essential Clothing and Morph Bundles
    • 100 Reference Heads
  • Kinect Mocap Plugin
So in summary, despite the price, I think CC was (or will be) a worthwhile investment.  It seems the product will continue to improve and advance and, since I like making character-focused games such as fighters that focus on characters models, it fits my needs.  I am a bit disappointed that iClone seems to do things that 3DS Max already does.  In addition, I still need a way to either edit or make unique clothing, which brings my to my next point:

Marvelous Designer

I posted about CC awhile ago, and someone brought up this program, which I had forgotten about actually.  It's essentially a much better version of 3DS Max's Garment Maker -- more stable, easier to use, etc.  The issue is, despite it being easier, it requires precision and a rather good knowledge of actual clothing design and pattern making.  It's neat, but I'm unsure if it's actually useful for what I do, and with the clothing CC already provides, could I just apply a morph or a simple fix to the clothing I already have instead of making my own garment pieces?  If a perpetual license wasn't $550 (or $60 a month -- I just dislike subscription models), I'd probably be more inclined to get it, but I'm on the fence and need an actual character idea that would need it before investing the time / money to learn it.

Anyway, my next plan is to try and make a character from beginning to end that uses CC.  Tempted to do it for a Project Merfight character, but I may want to try and do something more human first.  I'll post progress when I get that started.

Monday, April 4, 2016

Project Merfight DevLog 01

So as I've hinted in previous posts, I've started a new game!  I still don't have a title, but for now, I'm calling it Project Merfight.  This name is appropriate as it involves merfolk and fighting!  I haven't done a great job logging my games as they progress, so I want to improve upon that.
This first post is about the game itself, but also some of the developments I've made on the 3D front of the game.  To summarize Project Merfight is a tactics RPG with a battle system influenced by fighting games.  I've been working on the game for a while on and off while working on Battle High 2 A+ stuff; however from February till now, I've been trying to get a build ready for Indiecade.
What I have so far:

Essentially, during the month of February, I focused on the tactics aspect, mostly just getting the characters walking around the screen.  Then, I wanted to get the battle system down.  As I work on this, I do wonder, "Why don't I just make a fighting game?"  Well, this game's goal is to fill the void I feel fighting games have been leaving for me lately.
One is story.  I've said numerous times that fighting games are not good at telling stories.  The story ends up getting in the way or is often neglected or ignored.  Though I don't have a super deep story written at the moment, the goal is to attempt to deliver one.  Another void is single player content.  At the launch of Street Fighter 5, I felt myself wanting more.  Playing online crosses this border between fun and frustrating for me rather quickly, and I'd rather just spend my energy in other places, so instead of trying to improve my skill in a fighting game, I decided to try and use my knowledge and see if I could create an RPG experience that takes some of my favorite parts of fighting games and puts them in this space.
I'm using Unity3D, and though I like using the game engine a lot, there are always a few things I encounter when working in it; these items I wanted to document.


Using Mecanim with Equippable Attacks

 So right now, the flow of the game is you do the tactics part, moving in range of an enemy, and enter the attack phase, which looks similar to a 2.5D fighting game.  You perform a combo within the time limit to inflict damage.  What I want to do is that every time you use (or land) an attack, you gain experience points for that attack.  Once an attack levels up, that attack either gives you HP, Attack Strength, etc., but also, new attacks OR, similar to Namco X Capcom, the attacks change so you're forced to learn how you attacks connect more.
One technical issue with this, however, is that Unity's new animation system, Mecanim, really feels that it was built to assume that your animation state machine will never change.  There is the Animator Controller Override system -- which I do utilize -- but that feels more for like "Oh, I'm replacing this character's walk cycle with a different one but all the other states are the same."



So, what I'm doing is essentially I'm taking EVERY state in the game -- a lot I'm still missing sadly -- and putting them into one AnimatorController
This is only a small section of it too...
 I then have an AnimatorOverrideController that references this:

So happy Unity fills these in automatically...

Finally, before the fight segment of my game begins, I assign various state to animation pairs, instantiate a new AnimatorOverrideController, and replace the animations I need.  The main reason for this is that I'm not sure yet how many animations a single character will have and instead of having possibly 100s, I only reference the ones I need for that battle segment.  I've also created a custom data class that handles transitions -- as well as other info such as when attack spheres should be tracked.  Anyway, I'm happy with this solution for now -- until I test it on Xbox One and it breaks for some reason (which I'm hoping doesn't happen).


Swapping Equipment

So once I solved my animation issues, I had another issue related to equipment.  How was I going to equip different items to my characters?  I could do something where the items don't get shown, but I felt this was rather boring.  I want what the player equips to the characters to show up; I think it's important.  This is what I have so far:

Essentially there are several types of equipment I am dealing with:
  • Color swaps
  • Normal Meshes (or GameObjects)
  • Skinned Meshes
Color swapping was easy.  I just make a new material for one of the default items the character is wearing and swap them as needed.  Unskinned meshes and other game objects were simple too.  I have each bone of the character referenced, so I just reparent the item to a designated bone.  In the video, this is how I'm making the sash -- which his also using Dynamic Bone, an asset I recommend -- as well as the "Kelp Juice" attached to her hip.
The hardest part was skinned meshes.  Now, I could put every skinned mesh the character will use into one file, but I don't want to have to keep doing that and having to deal with a giant 3ds max and fbx file with a bunch of different parts.  When working though, I figured, "Oh, I'll just import the other skinned mesh, change the root bone, and it'll just work, right?"  Nope!  The problem is that upon import, the skinned bones and root are assigned to the Transforms included upon import.  Also, you need to make sure that upon import, the bones in the skinning data -- at least from 3DS Max -- go from the root bone and include parents of any bones.  It's almost safer to include the entire skeleton in the skinning data; Unity will remove all those with no influence upon import.  So after fighting with this for almost an hour, I figured that I need had to write something to transfer the bone data from my imported meshes to the current character's rig.  The following script does so:

[ExecuteInEditMode(), RequireComponent(typeof(SkinnedMeshRenderer))]
public class SkinRendererWeightTransfer : MonoBehaviour
        bool initialized = false;

        SkinnedMeshRenderer smr;

        public Transform newSkeletonRoot;

        string originalRoot = "";

        string[] originalBoneNames = null;

        void Awake()
            initialized = false;

        public void Update()
            if (!initialized)
                if (!smr)
                    smr = GetComponent();
                    if (!smr)

                if (originalBoneNames == null || originalBoneNames.Length == 0)
                    originalRoot =;
                    originalBoneNames = new string[smr.bones.Length];
                    for (int i = 0; i < smr.bones.Length; i++)
                        originalBoneNames[i] = smr.bones[i].name;

                if (newSkeletonRoot == null)

                // Reassign bones
                if (newSkeletonRoot)
                    Transform newRoot;
                    if (!StaticHelpers.FindChildByName(newSkeletonRoot, originalRoot, out newRoot))
                        Debug.LogError("No bone found for:  " + originalRoot);

                        Transform[] newBones = new Transform[originalBoneNames.Length];
                    for (int i = 0; i < originalBoneNames.Length; i++)
                        if (!StaticHelpers.FindChildByName(newSkeletonRoot, originalBoneNames[i], out newBones[i]))
                            Debug.LogError("No bone found for:  " + originalBoneNames[i]);

                    smr.bones = newBones;
                    smr.rootBone = newRoot;

                    initialized = true;
                    enabled = false;

 Probably not the best formatting for this blog, but essentially, I'm storing the original bone names and order, and then, upon equipping to the character, I get the new bone transforms.  (StaticHelpers is my own class).

Anyway, with this issues solved, I could start making equipment for my characters -- of course, writing details and what aspect of the characters they affect is an entirely different design mess.

Tons to Do!

I still have tons to do and I'm not even close to calling this game done.  I'm submitting a prototype more or less to IndieCade in the hopes that I can get some good feedback and maybe generate some interest.  These are still the biggest issues I'm having:
  • RPG Design.  I feel I have a decent grasp of fighting game design after all of my Battle High 2 A+ work; however, even just the pathing system took me awhile and I ended up finding a solution that was better than what I  had been doing and implementing that!  I'm just nervous that managing all of the data like how much each item cost, the stats they effect, etc., is going to prove not only difficult but boring and make me lose interest in the game.  And don't get me started on UI.
  • Title!  I still don't have an official title for this damn thing.  Project Merfight could work, but it sounds unfinished.  Essentially, the game takes place in a fantasy world that is inhabited by merfolk -- more like Rikuo from Darkstalkers than Ariel from the Little Mermaid.  The original idea was that it was going to be more similar to a World of Warcraft world in terms of aesthetics, but my friend got me thinking to change that a bit, and I thought about bioluminescence and have this 80's / neon yet underwater idea going through my head.
  • Content!  Rpgs -- well all games really -- have a ton of content.  Part of my goal recently was to go through the game and see how quickly I can make the content.  Having an idea of how to swap objects -- whether it's through texture or  meshes themselves -- helps, but still causes a bit of anxiety.
  • Tutorial -- though there are games that have done this similar, I want to try and make the game more about discover and experimentation instead of me telling the player how to do everything.  That being said, I'm still going to need to make a tutorial.  I want to take the Final Fantasy Tactics approach where it's optional, but I'm afraid if I do that I'll just neglect it.
  • Story.  I like writing, but I always lack confidence in my writing.  I also want the story to branch by level objects -- defeat Boss A goes this route versus defeating Boss B for example.  This is a lot of work, and in this first iteration, I will most likely be cutting.
Anyway, my goal is to get at least 2 levels (3 if you count a tutorial) before the late IndieCade deadline of May 15th.  I know the game will be far from what I want, but again, having the deadline is helping me focus and solve problems I'd probably ignore for months before actually tackling.  I'll try and post more about Project Merfight as I continue to work on it.  In the meantime, enjoy some gifs!