Design Guidelines for New Patterns, Architectures and Principals.

I've spent a while considering and clarifying internal rules I apply to selecting and designing new patterns to apply to code projects.  I've reflected in particular on what makes projects more sustainable over time and what keeps them fun to work on.  I wanted to share these out and get feed back.  Please let me know what you think, disagreements, likes, recommendations or clarifications?

DVS's Pattern Design Guidelines Version 1

1.  I want any architecture to offer simple implementation.  I.e. Observable<IType>.Set(this); would be a great short line to make an instance globally accessible, while other solutions might require 5 lines to setup.

2. I want the architecture to allow me to focus on the fun parts of programming.  I still want to solve problems without stressing over how to make it fit in an existing architecture, or requiring boiler plate code.  Typically, any thing a class does that doesn't influence other classes, can do WTF it wants.  (E.g. a script that makes a button shake when a its is clicked and disabled)  But any communication from class to class needs should have some level of standards.

3.  I want it to avoid edge cases.  Any "flexibility" I add to an architecture, that will only work in one case, or one spot in the code, should probably not be part of the core architecture, but should find itself more closely tied to the class or purpose that needs it.

4.  I want the architecture to be small in size, easy to understand, and easily documented.  If an architecture (of which there will likely be multiple) is hard to document in one power point page, its probably overly complicated.  If the architecture setup requires a dozen files, it is probably too complicated to deal with upkeep and any future redesign.

5. An architecture should be easy to change.  If only a couple core architectures are used, and the code/concepts are easy to work with/well defined, then a future understanding that requires a different architecture should be easier to implement.  Its a little hard to define, but throwing out core architectures usually makes people want to throw out the entire code base and start over.  I find this often is because edge case uses of the architecture, and Step 6 might clarify this more.

6. It should have only 1 clear way to resolve a clear problem.  Things like Dependency Injection might have multiple ways to bind, such as bind to an instance, bind to a type, create as singleton, create as pool, etc...  But for creating as a singleton, if it offers 6 ways to structure a singleton, then they will likely all be used at various points.  If you ever need to change this out, then you will have many different implementations to restructure.  This increases the likely hood you will need throw out a project to fix the architecture rather than replace it in a more structured way.

7. There should only be a handful of core architectures.  Think of your first day joining a project that is already in development.  There is so much learning.  But if that same project were built primarily on only 5 different architectures, that someone could look through a power point in an hour to review, and then reference later, then on boarding becomes easier.  If code reviews require consideration of any new potential pattern or architecture, and make group decisions as to whether or not a problem can be solved with existing patterns, no patterns, or that the group needs to add a new pattern to the list, then maintaining the project will be much simpler.

This is just a first draft, so I anticipate changes with this.  Please tear this apart with an Axe, but preferably in a constructive way.  :D

 - Thanks!

Unity: RuntimeInitializeOnLoadMethod - Order and Fault

RuntimeInitializeOnLoadMethod allows us to execute code at the start of a Unity program, without it being part of a Component.  This saves a lot of headache on special initializations and having to load things when you are not in the initializer scene. However, what is the exact order of these events, and are their any gotchas?

Order of events based on load type.

1. After Assemblies Loaded
2. Before Splash Screen
3. Before Scene Load
4. After Scene Load
1. This is also the default, if you do not include a load type.

Example code:

using UnityEngine;

public class RuntimeInitializeLoadTypeTest
{
    [RuntimeInitializeOnLoadMethod()]
    public static void Default()
    {
        Debug.Log("Default");
    }

    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterAssembliesLoaded)]
    public static void AfterAssembliesLoaded()
    {
        Debug.Log("AfterAssembliesLoaded");
    }

    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)]
    public static void AfterSceneLoad()
    {
        Debug.Log("AfterSceneLoad");
    }

    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
    public static void BeforeSceneLoad()
    {
        Debug.Log("BeforeSceneLoad");
    }

    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSplashScreen)]
    public static void BeforeSplashScreen()
    {
        Debug.Log("BeforeSplashScreen");
    }
}

Faults:

• Only BeforeSceneLoad and AfterSceneLoad execute in the editor, and these will execute for each scene.  
• This means using this for a 1 time execution is out, if you want to be able to test it in the IDE.  
• Or, at least, your code has to remember if it has been executed before.
• AfterAssembliesLoaded and BeforeSplashScreen do not execute in the IDE, so you cannot test them very easily, nor depend on them for typical debugging.

If you intend to use something for a one time execution, its then Before and After SceneLoad will work, but make sure the state will not be harmed by repeat calls or that only one scene will be in use in your app.

SOLID Development in Unity

For a while I have worked on and used SOLID, Dependency Injection and Unit Tests for my Unity development.  I had the chance to present at Unite Austin 2017. 

This is actually the first well recorded presentation I gave.  (after many past recorded presentation, something always went wrong.)

"... it was fantastic. The examples and level of depth are probably one of my favorites to date for SOLID. I think it was highly accessible and I've got some of the interns at the Unity Brighton office watching this feverishly. :) Thanks Dan!" - Markus Dugdale

Even if you have no interest in Unity, the SOLID aspects of this are a great for an introduction.  I spent a long time trying to come up with a way to explain it in an easier way.  Complex explanations that only make sense if you already understand it seem to be common place.  Check out Wikipedia's opening statement on "L" (Liskov's Substitution Principle):

"... a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.)" 

 Then I get into a Dependency Injection Framework and Unity Unit Testing from within Visual Studio, as can be found here. 

Unity Portfolio

Around Ludum Dare #38, I came across two great portfolio tools: Unity Connect and Itch.IO. The combination of the two can help your Unity portfolio grow overnight.  The general idea, is that Itch.io has a great system for uploading and sharing WebGL games (and other downloadable forms), and that Unity Connect has a great system for sharing projects over all.

                       

(links)

We'll start with the basics.  You need WebGL Samples of your unity work.  try looking through any old sample that shows something.  It doesn't need to be complete.  You can take a failed game idea that successfully shows working with changing gravity, and cut everything but that gravity feature away.  

Then build to WebGL and upload to Itch.io.  (its uploaded in private mode so you can test before releasing)

2 key instructions:  1) set Itch's project type to HTML to get the WebGL option later in the page and 2) upload a zip of the WebGL Build folder created from your Unity project.  It will figure out the zip structure.    

Next, with the game live and playable, add a new project in Unity Connect.  Add a thumbnail, and have a separate thumbnail for the WebGL playable.  (I.e. something that says 'play now' or similar on it.)  Add any other content, and be sure to describe it for what it is.  Was it a Proof of Concept, where you are focused on one key element?  Was it a starter test project?  Is it actually released somewhere?  Is this just level 1 of a larger pay project?  Is this part of Steam Greenlight?

The more items you have on Unity Connect, the more your profile will stand out.  Keep it up.

SOLID Development in Unity.

A couple years ago, I worked at a company who wanted to get SOLID development practices in Unity. I was unable to accomplish it then. After unsuccessfully moving on in my career, I kept a focus on figuring out how. Unity seemed to block every attempt. A large portion of the common commands are static, and unable to be replaced. Any attempt to even run test cases of Unity code causes it all to break down.

But 8 months ago, I got it working. I've used it in a major project, and spent time honing it for improvement. With a lot of companies looking to bring in 3D, and Unity being the most popular 3D game engine, the only thing missing was a way to use professional business standards when creating unity projects.  Its here.

In this presentation, I'll demonstrate how it was done.  I'll give some code examples and discuss some of the real difficulties it brought.  I'll also show what some of the key remaining hurtles are, and how they will be over come.

I'll be publishing another book, and having some more presentations on this at other conferences.  I also have a plan to affect unity assets to work with the business world.

On Sunday, June 4th, 2017,

I'll be speaking on this at the SDC.  Please RSVP to this free event.  Lets meet.  What challenges do you faces as a Unity developer?  Lets make Unity development better.  

SDC EVENT LINK  RSVP Now.

Ludum Dare #38

I decided to take on Ludum Dare #38, which theme was "A Small World".  So I created the theme: lost on a small world, chart star constellations to figure out where you are.  So below is the game play.

You can play it here:



One concept I really wanted to experiment with, was using the same mechanics as game play to drive the opening menu.  I.e. in the game you look through the star field to find constellations, and match them up with one on your screen, including rotation.

In this starting scene, you can see I've flat out said what the controls are, and you can see the lines that say START.  But to the right upper corner and rotated, you can also see the letters STA written in stars.  It emphasizes there is a constellation in that corner.  By any movement, you see how that camera movement works.

In my opinion, this helps clarify the game pretty directly.  You leave the start screen by use of the same mechanics as in game.

I'd love some feed back as to whether this concept works well enough, and what ideas you might have to improve.

New Blog coming soon...

I wanted to let anyone who follows me know I have a new blog on the way.  This one is being custom developed, because I could find no blogging service that has what I need.

I intend to start sharing a lot more unity samples and proofs.  I want to make this very Unity focused.  The Challenge that I am facing, is that none of the blog sites have a convenient way for me to upload a WebGL package and add it to the site.  The new site I'm having developed is built on that ability.  Now, it takes easily over an hour just to post to the CDN, and reconfigure the HTML example content.  As such, there are only 1 or 2 posts that share this content, but I had started to do one new proof a day to prove out some technology or experiment with a feature.  That's not reasonable.  I could test and produce a PoC in 20 minutes, but then take an hour to share it.

Anyway, I'm working on a few big things that will probably take most of my time until around August 2017.  I'll try to get more in, but it won't be often.  Be assured, its mostly Unity stuff.