Generative Glyphs

I came across this post on the Reddit sub r/Generative the other day and thought that u/ivanfleon had done something both relatively simple and also very cool. I had some ideas for generative glyphs and started by mimicking his sample there, thus was born the RectGlyph:

Two different RectGlyph settings

The interface came shortly after RectGlyph was done as I was trying to troubleshoot work on the PolarGlyph. It made it easier to see what sort of variations could be had, but also allowed debugging to be more visual (which really helps me a lot).

I’ve always been fascinated with languages, both real and imagined. As I was working toward my PolarGlyph idea, I stumbled upon a few happy accidents, such as the RunicGlyph.

Two RunicGlyph settings

And also the AngularGlyph:

Two AngularGlyph settings

And eventually worked out the kinks for the PolarGlyph:

Two PolarGlyph settings

I have a few others bring worked on, as well as some ideas regarding an editor so you can take your randomly generated glyphs and add line segments to or remove them from any of the glyphs in the set.

My pie-in-the-sky idea is to also be able to save them as a TrueType font so that they can be used in Unity (or anywhere), and possibly to save them as an SVG or vector sheet for use in various vector-based software.

It’s been a fun side project so far.

Micro-optimization #1: Setting a `done` flag using bitwise operators

I’m planning a series of very brief micro-optimization notes, both for my own records and to help anyone else who may be looking at some optimizations. I plan to provide minimal code, results, and brief explanations.

In this case, I came across a bitwise |= for setting a done flag in one of Penny de Byl’s Udemy courses. I was curious and decided to see if it was an optimization. It felt like it would be, but I didn’t expect by much. Sure enough, it is, but not by much. Still, if it’s a function that you have a lot of while-loops in your code checking against a boolean value, it could be handy.

The code:

static void Main(string[] args)
	for (int i = 0; i < 10; i++)


static void DoneTest1()
	bool done = false;
	int x = 0;
	int xSize = 100_000_000;

	while (!done)
		done |= (x < 0 || x >= xSize);

static void DoneTest2()
	bool done = false;
	int x = 0;
	int xSize = 100_000_000;

	while (!done)
		if (x < 0 || x >= xSize)
			done = true;

The results:

Using done |=  : 112ms  (1122354 ticks).
Using if  : 151ms  (1518356 ticks).
Using done |=  : 107ms  (1073112 ticks).
Using if  : 129ms  (1298421 ticks).
Using done |=  : 127ms  (1275415 ticks).
Using if  : 141ms  (1414998 ticks).
Using done |=  : 111ms  (1112100 ticks).
Using if  : 127ms  (1273705 ticks).
Using done |=  : 108ms  (1086612 ticks).
Using if  : 140ms  (1400030 ticks).
Using done |=  : 127ms  (1271739 ticks).
Using if  : 128ms  (1282120 ticks).
Using done |=  : 108ms  (1089749 ticks).
Using if  : 111ms  (1118823 ticks).
Using done |=  : 108ms  (1086191 ticks).
Using if  : 110ms  (1100477 ticks).
Using done |=  : 100ms  (1002949 ticks).
Using if  : 113ms  (1131274 ticks).
Using done |=  : 104ms  (1040928 ticks).
Using if  : 110ms  (1101986 ticks).

Each iteration shows a better performance using the bitwise |= compare and set rather than the if-statement. Across the ten iterations, the bitwise averaged 111.2ms while the if-statement averaged 126.0ms which amounts to a ~11.75% increase in performance. The bulk of the time in each set is, of course, the computer counting to 100,000,000, but given that the only difference in the two methods is the check for setting the flag, the variance is accounted for by that difference.

The Reason:

Bitwise operations on most architectures are almost always faster than other calculations, and branching statements are typically computationally heavier. When bitwise operations are an option, they usually result in more performant if less readable code.


For those of you not familiar with benchmarking in C#, I typically use the .NET Stopwatch class (System.Diagnostics.Stopwatch). I’ve removed the Stopwatch() code for brevity in the code example above. So long as you Start, Stop, read, and Reset your stopwatch in appropriate locations, you don’t need to worry about setup and other functionality as the only portion times is what is wrapped between Start and Stop.

I also run the program (usually a .NET Core console application) as a release executable rather than a debug executable to ensure performance isn’t being bogged down by the debugger for any reason.

Lastly, I try to run ten (or more) iterations of each thing that I’m testing. As you can see in the results, timing can vary for all manner of reasons. Sometimes the first execution of a code block is slower than subsequent executions. I also try to interleave each method or function being tested (e.g.: 1, 2, 1, 2, 1, 2, 1, 2 rather than 1, 1, 1, 1, 2, 2, 2, 2) to help ensure the code block isn’t being cached and repeated. Running only a single iteration is often misleading. In this case, all ten iterations of the bitwise comparison were faster, but it’s often the case the the slower of two methods might have a small percentage of faster executions and running single iteration may provide incorrect information about which is typically faster.

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.

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.

Playing with ray-tracing, Pt. 1

Back to working on Labyrintheer. But it’s Unity 2020, and I’ve been interested in playing with ray-tracing (RTX), so I started a new project, brought in some old assets and started toying with it.

The first entry is the trusty Gel Cube (from InfinityPBR) with RTX materials applied. This one is only lit by the internal point light that dies off when it dies. This is both of the attack animations and the death animation without scene lighting:

The next is with scene lighting. This is where RTX really shines with colored shadows cast through the transparent material of the GelCube:

The video quality isn’t as good as I’d hoped – need to work on that a bit.

Really, working with RTX in Unity’s HDRP isn’t terribly difficult, but there are a variety of gotchas that make it a bit of a headache, and materials are set up significantly differently (as are lights and scene volumes and…) That said, I plan to work on a few creatures first, just to get a feel for it all, then move on to bringing in the dungeons under RTX. Should be fun!

State of the Devblog

It’s been several months since my last post. That isn’t to say I haven’t been slinging code, but as I’m sure you all are feeling as well, this pandemic has really put a damper on mental clarity. Over the past several months I’ve come to a few conclusions: Labyrintheer is not mothballed, but is also on the backburner; this will become my devblog more generally for game dev and other code-related (or even tech-related) posts; and I need to post a lot more.

I’ve been considering creating some tutorials, both here and on YouTube, possibly with a Patreon backing options for additional content. I’ve also considered some small courses for Udemy. I might test the waters of all of the above to see what “feels” right for me.

All of that said, there should be more regular content being pushed out here, and I hope to see you all around. Thanks!

Advent of Code 2018

For those new to coding, or folk who want to exercise their brain cells a bit, check out this year’s Advent of Coding 2018.  Each day offers two puzzles to flex your coding skills, build new skills, or just generally put into practice your code-fu.  They are language agnostic, and often quite interesting.

If you want to join a private leaderboard, my code is: 427712-b8e50570 .  Feel free to join.

I also have been posting my own code to GitHub here.  It’s not pretty, and definitely not always the best approach, but I’ve been tackling each day with an idea for how to solve it rather than trying to find the quickest solution – usually with some robustness in mind that would make the code more flexible and allow for it to be used in other circumstances.  Not sure why… just how I roll.  I also haven’t been cleaning up after myself.  If I go down a path that leads to failure, it’s usually still there and either commented out or just not executed.  Since this is sort of a sandbox event for me, take any code I have in that repo with a grain of salt.  All days are currently in C# and for Visual Studio for Windows, though I may slowly put together some Mac console apps and Unity stuff in C# as well.

Fallout 76: A Wasteland Review

Puttering along with my development, I’ve decided that in addition to dev-blog posts and occasional tutorials, I’d also share some reviews with folk.  And what better way to kick that out than the very polarizing beast that is Fallout 76.  Please bear with me for my first few reviews as I work out some format ideas.


Each review is likely to start with a TL;DR section that just gives the briefest blurb and score.  While most reviews put the score at the bottom, in hopes you’ll read the whole thing first, I know that a lot of us skip to the bottom first anyway.  I only want to read reviews for 90+/100 games or games that do so poorly their scores are barely numeric.  That being said, Fallout gets:


Yes, that’s a lot higher than the current average MetaCritic score of 51/100 (user score: 3/10), and I know that critics and gamers alike have been deriding the game fairly steadily since its launch, but hear me out.  There’s a lot of game to be had for $60 (or less), and a lot more than meets the eye.  It’s not without bugs that are currently annoying, sure, however it’s worth venturing into post-war Appalachia.


In another plot twist, I’m going to lay out the negatives of a game first.  It’s like getting the bad news before the good news – that’s what everyone chooses, right?

The game certainly has a lengthy backlog of bugs to resolve at this point, and many of those really should’ve been caught in QA, or at least the B.E.T.A. phase of the game.  Many of them are minor annoyances like attached wires at your C.A.M.P. not aligning with your generators, or corpses despawning right after death (preventing looting).  Some are large, like being stuck in your Power Armor, or having your C.A.M.P. despawn improperly.

But these are largely technical issues that will be resolved with patches over time (there was a post-launch, very large patch already, another due any time now, and a third scheduled in December).  I’ve been lucky enough to not really run into any game-obliterating issues, but I do know they’re out there and respect that folk have been agitated by this.

Lastly, there are quite a few opinion-based criticisms of the game.  Some feel that the lack of human NPCs and the 24-PC limit in an instance makes the game feel empty or devoid of interaction. Lots of folk (including myself) dislike the 400WT limit to the stash, though that’s being upped to 600 in the next patch. I’ve seen complaints about a lack of a social hub.  So many complaints, some valid, some pedantic, some strictly one opinion versus another.

But, I like it…

But despite the flaws, I like the game on nearly every level, and actually disagree with many of the criticisms.  Here’s why:

Empty / Devoid of Interaction:  Looks, it’s the apocalypse, right?  I always felt it was a bit strange (despite always loving the Fallout franchise), that there were SO MANY people around.  It’s certainly plausible that a lot of folk would survive and the population would start to rebuild.  But I don’t think the scenario painted in FO76 is any more or less plausible.  Interaction with other players sort of makes sense the way it is – there are a handful of them, but not a ton, most of the post-war population that lived outside of the vaults have been killed off or died, and the few players in your instance are out and about learning the new world and surviving.  They aren’t at some social hub, flossing and throwing salt at each other. The sense of loneliness and desolation, in my opinion, is perfect for a Fallout game.

There’s not much to do after level x: Well, I mean, this seems to fall in line with complaints about virtually every persistent world game these days, and frankly I just don’t get it.  If you’re at max level two weeks after the game came out, and have done every side quest and explored every nook and cranny of the very large map, I’m not sure what you expect.  The kicker with this argument is that it’s a no-win for developers.  You could spend eternity making a game that lasts forever, in which case it would never launch, you could be baking extra content that releases a month or two after launch, in which case people would say it should’ve been in the base game and it was all a big money grab, or you just launch the game, and folk are mad because they “beat the whole thing” too quickly.  Seriously people, what’s a developer to do?  My ideas for Labyrintheer are partly designed to curb this, but the best way to do that is with roughly infinite content creation done programmatically and pseudo-randomly.  But that also means that much of the content is “weaker” compared to a fully realized and static game.

Here, though, there is a LOT to do.  Get absorbed by the environment.  Find the little nuggets of life before (and just after) the war.  If you’re willing to look below the surface, it’s an incredibly deep and rich world, and sometimes even the most mundane or humble building holds within it the story of a whole person.  I get the feeling that a lot of gamers today aren’t big on nuance, and that’s a real bummer.  Fallout games have always been as much about story as they’ve been about blasting super mutants into oblivion.  This game has as much or more of that than any previous installation, but some of it just isn’t spoon-fed to the player… and that isn’t a bad thing.

Why do devs release garbage with so many bugs? Why don’t we hold them accountable? This has become a bigger and bigger issue in the gaming community over the past decade, and the complaint isn’t without basis, exactly.  But there’s also a very large gap between what developers can do (technically) and what players think they can do (in a perfect world). Games and software have always had bugs, and they probably always will.  Sometimes they’re large, sometimes they’re small, sometimes they’re just funny, but they always exist.  It’s not just games, either.  But the issue is that at some point, people started expecting perfect software.

Yeah, “we don’t expect perfect, but this bug makes the game unplayable.”  Does it?  Because many of us have been playing it just fine for weeks.  Sometimes even with load testing (the beta), big issues aren’t going to wash out in QA or testing.  Sometimes the scale of a production, live, released environment is the only place you’ll find issues.  Sometimes even really big bugs.  I work in software development, in QA in fact.  Even a professional software company sometimes releases well-tested products that have major, major issues.  And the software we write has a far larger impact than someone not being able to play a game.  But it still happens.

Bugs will happen, and no matter how major they are, I’m not likely to get mad unless the developer simply doesn’t care or doesn’t try to fix them.  Because software without bugs is a pipe dream.  And trust me, game developers want no bugs far, far more than players do.  But it isn’t going to happen.  Some games may not have bugs that impact you, but all games have bugs that impact someone, and how the developer handles that after the fact is a far more crucial measure of their success.

A laundry list of wishful thinking: I do have numerous things I think could’ve been done better, implemented more sanely, or should have existed from the get-go.  That’s also true for many games I play, but anything with a persistent world is more likely going to be the target of my thinking “why the heck didn’t they add this?”  Still, persistent games also usually have development for much longer lifecycles post-release.  I’m sure many of those things will be seen as time goes on.  There’s a lot of room for FO76 to grow and improve, but despite that, I’ve had a lot of fun playing it.  Isn’t that the primary measure of a good game?  Is it fun?

Final Thoughts

Critical thinking is a skill I wish was applied more in gaming these days.  Sometimes the “critical” part does mean voicing your unhappiness with a game – absolutely.  I’m not saying that there’s nothing wrong with FO76, or that people who are upset about them don’t have valid concerns.  But I see so many threads about people demanding a response from Bethesda “today”, that it’s clear many folk just can’t grasp things outside of their own feelings on something.  Does Bethesda have the resources to respond to all of the hundreds of disparate “right now” requests for answers?  Of course not.  Speak your bit and move on.

If you like the game, keep playing it.  Yeah, some stuff isn’t as good as it could be, but there’s just so much to see and do.

If you don’t like the game, that’s cool, too.  Tell Bethesda why you think it was a waste of money, then move on.  Just as there’s a ton to do in FO76, there are even more games out there with lifetimes worth of gameplay, too.

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!