Korrasami has Destroyed My Life.

I'm not typically one for doing Fan Art but the Legend of Korra Finale is hitting me super hard right now. So hard that I decided to do some Fan art in the style of the game I am making Dusk Runner.

Dusk Runner: A New Project Has Begun

Ah. There isn't quite anything like starting a brand new project. All the old flaws and quirks of your old project have become a thing of the past and you can focus on moving forward onto a bright and prosperous future. My last title was a infinite runner/launch game called Combo Princess. After I finished development on that project I took a break from solo development and I worked for Forever Interactive and Digital Iris for a while which was an incredible experience and I learned a ton of new technical skill and a lot of new things about how teams function in a non school atmosphere. With that knowledge in tow I am ready to dive back in to developing solo with my new game Dusk Runner. Dusk Runner is a Retro 2D Metroid Vania game that takes Inspiration from a number of nes titles. Including Batman, Ninja Gaiden and Kirby.

CSG Post 8: Living, Eating, Breathing by Reference

Up until very recently I never knew the true value of reference types. If you are not familiar with reference types, a reference type is a data type that stores the machine location of a piece of data instead of the data himself. The benefit of  this means that you can set this one data value from anywhere you have the reference. Another benefit is that it allows you to store and pass a lot of data without passing a lot of data. This particular benefit has been making my life a lot easier recently. On SOY I will often need to get data from a one object to another object. At first what I would to was assign a value directly using the get component method.

varINeed = targetObject.GetComponent<TargetScript>().desiredVar;

However a better way to do it is to just store a reference type of the object that I need access to.

var varINeed;

TargetScript  targetScript = targetObject.GetComponent<TargetScript>();

varINeed = targetScript.desiredVar;

This way is much much better because now you can also access any other data that you need from that object.

CSG Post 7: The Wonderful World of Enumerators

Ive known that Enumerators have existed for some time now. But Ive never quite realized how powerful they were before I Started working on SOY. Enumerators allow you to perform operations on a timed delay that can be closely controlled. My first run in with Enumerators was at the 2014 Global Game where I used them with: "yield return new WaitForSeconds();" pretty much exclusively. This Enumerator function is plenty useful however soon after coming onto SOY I learned the power of combining loops with Enumerators. With loops you can have Enumerators delay indefinitely until a certain criteria is met. Another trick I learned is that you can substitute the Update method with an Enumerator and have the enumerator run at lower speeds resulting in a better performance Update Methods.

IEnumerator DelayTilCriteria()
{
   while(critera < 80)
  {
    critera++;
    if(breakOut == true)
     {
       break;
     }
    yield return new WaitForSeconds(1.0f);
  }
}

This snippet shows how you can Delay, Increment and Exit an Enumerator Coroutine.

CSG Post 6: Jack Black Jacks Black Jack Blacks Black BlackJack

As a proof of concept for SOY I was requested to make a Networked Black Jack game that would prove that we could create a Networked Multiplayer game. That Project is Here:
http://www.mediafire.com/download/feaumouqpfsf0am/SOYBlackJack4.7.11.2014Jons+%281%29.zip

CSG Post 5: Managing Networks Like a Boss

I have worked on projects before involving networked play however I have agreed not to talk about it. Luckily Scoundrels of Yen does involve network play So I can talk about all the things I learned then now and also the things I've learned now now. Its important to note that I have only have extensive experience with RPC method based games. I would love to do a state sync based game but currently that type of project has not arisen.

One thing that I learned from doing networked unity programming is the value of keeping your code organized. Before learning networking I would always format my scripts however I so pleased. This was important early on for experimenting with different code formats but as coding became more and more complicated an organized structure of where certain methods were located became more and more relevant. If you aren't familiar with RPC Methods, the way it works is that you First create a method beginning with [RPC], put and functionality that you need into the method. Then use NetworkView.RPC(); to pass in the string name of the method you want to call crossed the network. Followed by the rpcmode and any parameters of the method. This winds up needing quite a lot of methods. For any piece of data that you want to transfer crossed the internet you now need a RPC method for it as well as a Public Method that triggers the call crossed the network. Because of the large amount of methods I adopted a system where there is a summary at the top of the script followed by any getter setter properties or methods.(I prefer properties). Followed by any methods built into unity. Followed by private methods, Followed by public methods. Followed by RPC Methods if any are needed. Followed by Ienumerators.

bool variables/constants;
bool GettersSetters;
void UnityMethods();
private void PrivateMethods();
public void PublicMethods();
[RPC]void RPCMethods();
Ienumerator IEnumerator();

Ive stuck to this structure for a while now and I really like knowing what section to look in depending on what type of method a certain functionality uses. Eventually I would help to define the Raid+ tech reqs using these standards and I am very glad I made that decision.

CSG Post 4: Tooled Up

One of my first Tasks for SOY was to make a tool for unity that would make it easy to place game objects with a single click. Due to NDA related reasons I cant talk to much about it but I have made another script that has very similiar functionality to the SOY tool. That can be found Here.
Check It Out!

CSG Post 3: Version Control is Rad

In unity development we often have the problem of how we implement one another's code into the build without breaking the build and without wasting a ton of time re connecting all the inspector variables. The Answer: Version Control. Version control is a software that tracks the changes that are made in certain files. Those changes are tracked on a server then are later pulled onto other peoples machines. Ensuring that everyone changes are implemented into the build lightning fast. While version control is incredibly powerful it does not come without a couple drawbacks. The first being that the VC software that we use(Source Tree) does not allow the merging of different scene files. So when you are deving you have to make sure that no one else is making changes to the same scene as you. You want to have this practice for all of your files but scenes are especially annoying because they can contain many important changes. Another problem is that when learning source control you are very likely to lose a lot of your work. This summer I once had to redo 2 weeks worth of work because I hadn't committed for that long and my hard work got overwritten by a coworkers hard work. Luckily, on Raid+ we haven't had any major catastrophes, due to the amount of emphasis we placed on always committing to other team members. I hope that things continue to go this swimmingly.

CSG Post 2: The Hundred Enemy Problem

Just recently in my CSG Capstone class I over heard a conversation about the use of the SendMessage() Method in unity and how it is much slower than direct calls or using Events. This is certainly true. Having to Search through an entire GameObject in search of the passed in method name is incredibly inefficient. However I had just recently been working on a problem with another project of mine and it seemed to me that the only elegant solution to the problem was to use the SendMessage() Method.
The Problem is that when you develop a game you may have an undefined or variable amount of enemy types each being controlled by a corresponding script that will only function for that enemy type.  That works well enough for just a few enemies and maybe you want to add a bit of inheritance into the mix and have all your AI scripts inherit from a script that has a health property on it. The Problem comes in when you want to be able to detect that an object is an enemy and apply damage to that object generally so that whether it be a Flyer enemy or a Walker enemy you can call just one line of code to apply the same Operation to several different types of script instances. The three ways that are typically used to pass data back and forth between objects are not valid solutions. Direct Calls issues the Immediate problem of not being able to make direct calls. If we don't know what script we are using then we don't know what calls we can make. Events would work but for a game that may need Hundreds of enemies active at once, passing variables to over a hundred different instances of somthing that may not even need that informations does not sit well with me. And of course SendMessage is actually a very good solution to the problem except it does not work because that is also highly inefficient.

One solution that I came up with before writing this was to instead of having entirely separate scripts for each enemy, grouping enemies together based on how similiar their behaviors were and then just changing certain variables to allow them to have their proper behavior. This Minimizes the amount of calls you have to do and the amount of different tags you have to set. It is not a perfect solution by any means but it would allow you to easily have a hundred enemies without becoming to inconvenienced . The Solution that I thought of as I was writing this is a much better solution though. Rather than having One script for each type of enemy and a script that it inherits from you could have just two entirely separate scripts. One script for the enemies unique behavior and one script for the enemies common behavior. The common behavior script would be on every prefab of an enemy and would be called when needed by unique script. This way any generic methods can be called by external scripts and the unique behavior script also has access to it for its own behavior.

CSG Post 1: Here We Go Again

Another semester of the CSG program another set of forced blogs. Im going to take my first blog to just give an overview of Raid+ affairs. The team that I'm with for my Matc capstone class (Raid+) is currently making a game called Scoundrels of Yen(SOY). SOY is a Collectible Card Game that uses a board game type interface. The Designers are currently hard at work finding the Fun. Artists are doing tonnes of cool concept art. And programmers are hard at work setting up the framework for the game. We are currently using service called Get to Done for our performance tracking and so far that is working pretty well. The Tech team is using Source Tree and BitBucket for version control. A good Start to the Semester.