Quick Tip: Notes in Code

Going along with my last post, just a quick tip: sometimes it makes sense to use comments to show how a loop will progress. For me, at least, this is another way to get a grasp on how values are changing and ensure that calculations account for the situations you may need.

In this case, following the logic flow, I realized that the initial value for v2 was where things were breaking down. I was also able to capture the final segment without using an additional for-loop which makes things a bit cleaner. I’m actually going to evaluate some of my other triangle logic to see if I can do the same thing using the vx -= vertices.Length method to take care of the last parent loop.

Troubleshooting via UI in Unity – Deuta

As a visual learner, I’ve found that sometimes seeing something working is a better debugging tool for me than seeing an array of int values. With the array, I can still usually see where a pattern breaks down or unexpected values might be (at least when the use merits it), but it’s more difficult for me to wrap my brain around what needs to be changed.

I’ve continued work on Deuta, my project for parametric primitives in Unity. One of the things I’ve spent some time in is custom editor/inspector UIs for shape generation. I highlighted the vertex-index (vertidx) in a previous post, but I have a great example of how it helps me.

In the above video, I’m working on a parametric torus option. I have the vertices down how I want them, but as I was writing code for the tris, I clearly missed a step. I looked at the int[] of triangles I got. I could see where there was an issue. But being able to visualize it helped me understand precisely what I needed to change and how. I know how the triangles need to be ordered, but this also allowed me to see at what index it breaks down, if there’s a pattern to it or it’s just a single issue, and to see how numeric patterns played out.

I’m sure I’ll be posting more Deuta stuff over the next several weeks. I’ll likely show off some more of my troubleshooting/visual debugging steps as I work on some more complex shapes.

Unity Custom Attributes and Custom Editors

Shapes Editor 01
Custom editor/inspector view for Shapes.cs

While working on Programmatic Meshes, it became clear that I needed some custom gizmos to help me visualize things as I moved along. It really became a necessity as I was working on sphere generation because I was having some issues where certain sizes and segment counts were creating bad geometry. This was almost certainly due to ordering of the int[] array for triangles associated to the mesh. Since everything is generated by code, that means that once all vertices are created, the code needs to also sort/order those vertices the same every time to ensure that the facet tris are created correctly.

Sphere Vertices Indices
Sphere Vertices Indices

This was my first venture into gizmos aside from some very basic line drawings. I wanted the indices of each Vector3 in the mesh so that I could ensure they were getting properly ordered each time and would meet the requirements for tri calculation. So the above was born – and damn did it ever help me see where things were occasionally not working (sadly, I don’t have a screenshot of the bad sphere, but let’s just say that it was… not an ideal geometric shape).

After getting through that, I wanted to also change the inspector so that I could enable/disable vertex visualization. As shapes become more complex, the numbering is great, but I wanted a better visualization of the vertices in the scene view. As the screenshot above illustrates, unless you rotate the view around a bit, it’s easy to get lost with where vertices actually are in relation to one another.

Sphere Vertices Visualization
Sphere Vertices Visualization

In the above GIF, you can see how movement helps determine what indices you’re viewing, but the ROYGBIV and SIZE options for visualization also help. In the ROYGBIV mode, the closest vertices are red and the furthest are violet, and everything in between follows the ROYGBIV order. With the size option, the closest vertices are the largest and the furthest away are the smallest, and they are scaled to suit in between. In either case, they’ve updated in real time. I’m not yet sure how this performs on very high density meshes, and I’m sure some optimization will be necessary, but it’s good enough for my needs for now.

I wanted the collapsible Viewables area in the inspector for this, as well as for mesh data (Vertices[], Normals[], and Triangles[]). I also wanted to be able to select the Shape (each of which is a class inheriting from Primitive()), and which Generate() method should be used (each shape has different generate methods).

For this to work, I created a few custom classes, which I added to my external DLL:

SelectableList<T> is a custom List<> type collection that has an interactive indexer property called .Selected that references the index of the selected item in the list. This has turned out to be handy for selecting items in lists from dropdowns in the inspector.

MethodCaller<T> is a custom collection that contains a reference to a class (in this case, each shape class gets a method caller), and a SelectableList<MethodInfo> of the generation methods in that class.

And lastly, MethodDictionary<T> is a custom collection class that collects MethodCaller<T> objects. Its constructor takes a filter for classes (to remove the base class and secondary base classes where inheritance takes place on multiple levels), and a filter for methods based on the name of the methods to acquire.

The creation of the MethodDictionary also builds out the dictionary based on the filters provided, so there isn’t a lot of work needed to implement it. This is definitely a plus.

In the Unity code, I also created three custom attributes:

[Segmented] is tagged to generate methods that use the segment count value. This allows that slider to be enabled/disabled on constructor selection.

[DefaultGenerator] is tagged to generate methods that the default Generate() method passes to.

[GeneratorInfo] is tagged to all generate methods and provides inline help text in the inspector, typically what segment count actually accounts for if it’s used, and what the measure/size value indicates (e.g.: circle/diameter, quad/size, hexagon/apothem*2).

Using reflection, I do something like this in the ShapeEditor.cs script:

if (shape.shapeMethods.Callers.Selected. Methods.Selected. GetCustomAttributes().SingleOrDefault(s => s.GetType() == typeof(SegmentedAttribute)) != null)

It’s not terribly pretty, but it’s fairly quick – quick enough for inspector draws – and allows the inspector panel to change on the fly as selections are made.

It’s worth noting, if you haven’t worked with custom attributes before, that the attribute doesn’t need to have fields despite all examples I came across online containing them. Without fields, it’s basically a check to see if it exists or not – a boolean of sorts applied to a reflected method to change how the inspector is drawn. Some examples:

[AttributeUsage(AttributeTargets.Method)]
public class SegmentedAttribute : Attribute
{
}
[AttributeUsage(AttributeTargets.Method)]
public class DefaultGeneratorAttribute : Attribute
{
}
[AttributeUsage(AttributeTargets.Method)]
public class GeneratorInfoAttribute : Attribute
{
    public readonly string info;

    public GeneratorInfoAttribute(string info)
    {
        this.info = info;
    }
}

And usage on a class method:

[Segmented]
[DefaultGenerator]
[GeneratorInfo("Generates a circle based on the 'starburst' pattern.\n\nSize is the diameter of the circle.\n\nSegments is the number of segments _per quadrant_.")]
public Mesh GenerateStarburst() { /* code */ }

I will probably write some additional posts about this, maybe with more code, as this project continues. And I’m sure I’ll have a Part 2 of Programmatic Meshes in the next week or two.

What to do, what to do…?

Still playing with some new Unity 2020 features, still dabbling on Labyrintheer as well as a few other projects. Learning a bit of Machine Learning just for fun, figuring out the ins and outs of HDRP and RT, and generally using this lovely COVID pandemic as time to reset a bit and figure out what I actually want to develop sooner rather than later.

For whatever it may be worth to you, if you are interested in Machine Learning, either specific to Unity, or more generally, I cannot recommend Penny deByl’s courses on Udemy highly enough. All of her courses are great, and the ML and AI courses are no different.

https://www.udemy.com/course/machine-learning-with-unity/

While the course is ostensibly about Unity and the development takes place within Unity, it isn’t specific to the Unity ML-Agents (though there are sections for that). The bulk of the course is geared toward developing your own agents and brains in C#, which is fantastic whether you want to use Unity’s ML-Agents or not.

In the immediate now, I’ve been working on some Unity code to create a system of CCTVs and monitors to show them. It’s a core component of a potential game idea I’m futzing with at the moment. I expect to have some pictures or videos in the next week or two to show off. Until then, Happy Thanksgiving 2020.

And we’re back (for real)

So, I know I said “my bad” last time, and that was six months ago.  But, Labyrintheer development has actually kicked back off and progress is being made.  Prior to giving it a break, I had two nagging issues that I couldn’t overcome.

#1 – the small one.  All chests that could be looted (advanced props) have a model and animation path that starts with them open (sort of in their T-pose).  The first thing that happens on instantiation was that they close, and in doing so, play the appropriate sounds.  It was a loud and obnoxious thing – small, but annoying.  Anyway, that’s been dealt with.

#2 – the big one.  Both the player and mobs have evolved over my time with Labyrintheer. They started with CharacterControllers because, well… they’re easier in a lot of ways.  But, despite literally weeks of effort, I couldn’t prevent the player from climbing atop the gelatinous cubes when they pushed against one another.  It was frustrating.  And it appears, in part, to have been caused by having both a CC and a Rigidbody.

I started using the Rigidbody because with only CCs, the mobs would push the player around too easily.  The fix, at least so far as planned, is to remove the CharacterController components, wire all the player controls to appropriate Rigidbody physics, and probably just not use CCs anymore.  It’s not a huge amount of work, just need to get physics movement working (and feeling) right.

All of this is coupled with trying out Unity’s Collaborate rather than my existing git repo.  I’ll probably maintain git, at least for a while, but Collaborate really does seem pretty nice, and I don’t have to worry about git vs git-LFS.  Let’s see how that ride goes.

Otherwise, I plan to maybe use another platform for bug/issue/work item tracking.  Anyone have any tips?  I’ve been toying with #Slack, and trying to find a plugin, perhaps, that would work for such a thing. Conclude would be okay if I didn’t mind eight million channels (one for each issue).  Maybe there’s a better way.

Anyway, for what it’s worth, I should be posting here much more often.  Thanks for hanging around!

Unity Profiling for Fun (and Profit?)

For those who may have been following since before this blog began, you may have seen the Iceglow Gel death sequence that includes the possibility of spawning smaller Mini Iceglow Gels.  This was, by and large, a stroke of sheer genius on my part (yeah yeah yeah, just let me have this one).  It seemed like a cool idea and has led to some other cool ideas for deaths with other mobs.  In fact, each mob has a DeathScript requirement, even if it’s just to, you know… die.

But this has also been a thorn in my side.  When an Iceglow dies, there is a major stutter before the new minis are spawned in.  I finally decided to toss up the profile to see what was going on, and decided to write this brief post on profiling, because damn, it’s handy!

For those new to Unity or development, the profiler is a pretty common tool used to “debug” the actual running game.  It can attach to a development build for better and more accurate profiling, but if you’re simply looking for bottlenecks where the definitive time and resources aren’t as important as discovering the spike, you can also simply attach the profiler to the editor itself.

Ice Glow Death Profile 1
Ice Glow Death Profile 1

This was a capture at the time of the resource spike right when the Iceglow dies.

Ice Glow Death Profile 2
Ice Glow Death Profile 2

The details of CPU usage show that the >1s spike is caused by the PhysX core baking the mesh for the minis.  I was hoping that, since this was running in a coroutine, that it wouldn’t impact the whole of the game.  Maybe I’m doing it wrong (or, at least, not the best way).  Maybe I can pre-bake those meshes.  Maybe I can use simple colliders instead (a cube is far easier to calculate).  I’m just delving into this, and I’m not sure what the best solution is yet (stay tuned for updates on that, or follow my plea for help), but for now, the profiler is my handy tool to figure out what calls are b0rking the game.

Easily as important as debugging code, and definitely more important for tuning, I can’t recommend highly enough learning to love your profiler.

If at first you don’t succeed, Google some more…

As a lesson, today I taught myself that sometimes your first (several) attempts to Google a problem just don’t do the trick.  For several weeks I’ve had an issue where my mobs just zoomed around like they’d been snorting magic dust, completely ignoring the values set for them with regard to speed, acceleration, et cetera.  It happened fairly suddenly, I wasn’t sure why, and many attempt to fix it failed.

I Googled this issue many times over the weeks looking for an answer.  Nothing relevant ever seemed to make it into my search results.  It became frustrating!

Then, on a whim, I searched once more for the answer, clearly using a better phrase, and Google’s magical algorithm finally decided to lend a hand.  Of course, the answer was something dumb on my part.  At some point, the isKinematic boolean flag on the rigidbody component became unchecked, which meant that the rigidbody and the nav mesh agent were in a race condition, both trying to control the movement of the mob.

But, NO MORE!  My gel cubes gracefully slog around the dungeon biome again, and the War on Magic has been brought to a halt.

One checkbox took weeks to resolve.  Probably a n00b issue, but a good lesson all the same.

Random Class, Singletons, and the “Big Debate”™ (does this sound familiar?)

A few weeks ago I wrote a VERY similar post about my Logger class and the debate over the use of Singletons.

I’ve done the same with my new randomization class, LRandom().  LRandom does several things under the hood, and is a singleton for a very specific reason.  First, I wanted to use it to replace the random class that Dungeon Architect uses during initialization of a dungeon or map.  In part because I wanted more control over randomization, and in part because I wanted all aspects to produce the same values with the same seed.  Previously, at least in earlier versions, DA would produce the same dungeon layout, but things like decorations and extras would not always be the same.

Additionally, I wanted the same random class to be able to control other randomizations during play: loot, die rolls, et cetera.  The current implementation uses a single System.Random instance, though I may extend this to have several – one for dungeon building, one for loot, one for mob AI, and so forth.

Also, the state of the System.Random is stored in a serialized file on exit.  This should, in theory and after a lot more work, allow one to pick up where they left off with the state of the randomizer where it was before.  The main goal here is to prevent “known randoms” with the given seed.  The first chest you run across won’t always have the same stuff.

The class also contains the original DA methods for NextGaussianFloat() and GetNextUniformFloat() to integrate without changing a lot of the DA code.  And lastly, it contains methods that allow the instance to be reseeded if need be, which is mostly good for debugging, but may have benefits during runtime as well.

So, currently, LRandom() and LLogger() are two singletons that I’m using that have proven very beneficial.  If you missed my last post, or want to hear more about Singletons (the good, the bad, and the ugly, so to speak), check out this great podcast from The Debug Log- Episode 73: Design Patterns: Singleton.

Logger Class, Singletons, and the “Big Debate”™

So I’ve spent a bit of time working on getting a logger class setup, which is rudimentarily complete.  This class currently just writes out to a file and also to the debug console in Unity.  It takes in a message, a module, and a severity.  I wanted to easily have access to this class from anywhere, but since it writes to a file, I also needed to ensure that there was ever only one instance trying to access the file at a time.  This, of course, led to the singleton pattern.

Now, even a cursory glance through newbie programming blogs and books can cause one to question why this is even a pattern to begin with – it seems that everyone says to stay away from them, and I kind of understand why you don’t want to overuse them.  The Debug Log has a pretty good episode about them here.

So, singleton was the answer, and it was setup nicely enough and it works, though I still need to make it threadsafe.  But… logging:

LOG!
LOG!

So, now it’s back to work on the game itself.  I have most of the systems in place to get a sample level up and running soon.  Yay!

Dungeon Layout Metrics

So, for the current branch of changes, I’m working on level layout, design metrics, and baseline functionality.  What does all of that mean?

Layout Metrics and Design
Layout Metrics and Design

In the above photo, I have a nearly perfect layout.  The spanning tree options have kept the start (blue dot – bottom right) and end (red dot – center) pretty far apart.  The blue dot is the actual portal where the player would enter the level.  The red dot is just a red colored portal, but that portal is a marker for where the boss room will eventually be.

Of course, since everything is randomly generated, no two levels will be completely alike.  Unfortunately, that means as I change things up or even hit a seed I don’t like, things can go south.

Too Much Spanning Tree
Too Much Spanning Tree

The above shot is with a bit more weight on the spanning tree node.  There’s still a nice long path between start and end, but there are also long hallways that loop too far around (for my taste, at least).  Actually, the above example isn’t awful, but these images are the same seed, the first with 0.05 spanning and the second with 0.15.  While the spanning value may be static on all levels, there may be some small fuzziness around those as well.  Trying to find boundaries is more of a balance than I expected.

Other than basic parameters, I’m trying to prevent barrels from spawning inside of walls:

Barrel Wall
Barrel Wall

Or in large groups that get in the way:

Too Many Barrels
Too Many Barrels

I’ll be working on better “torch flicker” – right now it’s a bit stuttery looking, and I’d like it to be smoother and look more like an actual torch.  Then a few more mobs, the boss spawn, and some more decoration for the level.