Friday, November 3, 2017

What I see when broadcasting to Mixer.

Currently, when I broadcast to Mixer, I select the Go Interactive menu item, and see the popup window to select an interactive project.  I select mine, and see this:


I click dismiss or close icon, and I'm not allowed to select this project.  Trying to figure out why...

Thursday, November 2, 2017

Resolving Mixer interactivity issues.

Recently I have stumbled in my attempt to get the Mixer interactive feature of my game working.

As you can see, I've created two scenes in my Mixer project:


And this:


I then clicked on the publish link and was presented with this choice:


October 10, 2017: Solving the different serialization layout errors.

The first time I built an UWP rendition of my game I was plagued with different serialization layout errors:

A script behaviour (probably [My component]?) has a different serialization layout when loading.

This error seemed to appear for each of my custom components.

At first I did exactly as the error messages suggested: I removed all #ifdef statements my code.  While doing so, I realized none of them encapsulated any public fields of any of my game components (classes descended from Unity3D's MonoBehavior class), so obviously precompiler directives were not the issue.

I then did some googling and found a site that claimed Unity3D sometimes serialized all fields, so I added the [NotSerialized] attribute to my protected and private fields.  I even changed my getters and setters into methods; again no luck.

Then I decided to focus on the Unity3D project.  I viewed my plugins in the Inspector and noticed that the “Do not process checkbox” was checked for each.  Based on the article here (https://docs.unity3d.com/Manual/windowsstore-plugins.html), which clearly states that Unity injects serialization code into plugins, I unchecked the check boxes for each of my plugins.

And voila!  That resolved my issue!

Sept 29, 2017: Why I decided to build my game as Unity3D plugins.

When I first started game making in Unity3D, I used the default method of creating scripts in the assets folder.  I found this to be very easy as Unity took care of all the prep work for me, so I was left free to focus on coding the game logic itself.

However this limited my ability to properly organize my source code in my repository.  To summarize, I discovered the following limitations:

1.  It was difficult to divide out shared code into a separate Visual Studio project for sharing across different applications.

2.  It was difficult to include namespaces not already bundled with Unity3D.

To resolve this, I decided to put my code into plugins for Unity3D.  This provided the flexibility to properly organize my source tree and easily add UWP libraries, at the expense of tying myself to the Microsoft platform.  However I had already decided early on to only code on the Microsoft.NET platform anyway.

So I organized my work into two UWP projects, one as a library of components I would share between Unity3D based games, and the other as a set of components specific to my current game.

I then created a .NET standard library targeting .NET standard 1.4.  My intention was to use this as a library of all my message contracts.  Obviously .NET standard made it easy to put my message contracts on both the Unity3D client and the server, which I intended to be Azure cloud.

I dragged my libraries into a folder structure I created underneath the Assets folder in my Unity3D project, and at first I was still able to see the components I created still attached to the GameObjects within the scene.  However, when I tried to build an UWP solution for my game using the Unity3D build wizard, it failed because one of my UWP projects was targeting a namespace specific to UWP and .NET 4.7, and Unity3D was trying to compile against .NET 3.5.

So then I tried to set my UWP plugins to only run on UWP by clicking on the DLLs in Unity3D’s asset view window and setting their properties using the inspector.  However, this only made me unable to run my game in Unity editor.  I also noticed that while in editor view, my components had disappeared from the inspector view of my GameObjects, with the editor complaining they could no longer be found.

After using my best friend Google, I discovered this link:

I decided to give it a shot.

First, I created another solution in my source tree to hold plugin placeholder projects.  I added two Visual Studio projects into this solution, both targeting the regular .NET 3.5 framework (the same one Unity’s Mono targets), one for each of my UWP projects.

Second, within these I added appropriate references to UnityEngine.dll, located here:
C:\Program Files\Unity2017.1\Editor\Data\Managed
And UnityEngine.UI.dll, located here:
C:\Program Files\Unity2017.1\Editor\Data\UnityExtensions\Unity\GUISystem

Third, I used NuGet to add in appropriate libraries.

Fourth, I added links from these placeholder projects back to the source code in the UWP projects.

Fifth, I created a class with the same name as within my UWP project that referenced an UWP only library, and made it a dummy class that Unity could serialize against and didn’t reference any UWP libraries within.

I put my placeholder classes library in the original folder located underneath the parent Assets folder.

I moved my UWP assemblies into an UWP subfolder beneath.

I went to the inspector and set the UWP assemblies to only run on UWP, made sure they would not process, and set that as placeholders to their equivalent libraries that I just made, targeting regular .NET 3.5 framework.

Now when I open my game in Unity editor, I’m able to see my custom components, add these components to GameObjects, and see their properties as well as set them.

I was then able to get my game to build into an UWP solution, and used Visual Studio to deploy them to both my laptop and my Xbox One console.

However, when I took a screen capture of my test game on my Xbox One console, I get this:


Friday, April 3, 2015

Presenting at SATURN 2015.



I will be running an interactive session on architecting websites to handle high concurrent user load.  Will recommend two patterns that you should always keep in mind when building public facing websites.

I based some of this on the research I did for my MSDN Magazine article:
http://derricksweng.blogspot.ca/2013/02/building-simple-comet-application-using.html

Sunday, February 3, 2013

Building a simple COMET application using Microsoft.NET

MSDN Magazine published my article on using COMET principles and Microsoft.NET to implement web real-time. http://msdn.microsoft.com/en-ca/magazine/jj891053.aspx

Saturday, April 30, 2011

ASP.NET Drop down list and strongly typed DataTable

I had code where I populate the contents of an ASP.NET DropDownList with a strongly typed DataTable returned from an ASP.NET web service. In this code I bound the DataTable to the DataSource of the DropDownList and did a DataBind() in the Page_Load() method. This worked perfectly fine on my local box.

However, when I loaded up the ASP.NET page in the production data center, I got:

System.Web.HttpException: A
DropDownList cannot have multiple items selected

To solve this problem, after I bound the DataTable to the DropDownList, I iterated through each ListItem and set its Selected property to false:

foreach (ListItem myItem in myDropDownList)
{
myItem.Selected = false;
}