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.

TL;DR

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:

8/10

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.

Shortcomings

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!

Wow…

… it’s been a while.  My bad!

It’s been pretty busy with non-dev stuff the past couple of weeks.  Also, I just built my first 3D printer, which has eaten some time.  But sometimes it’s good to get away from the grind for a bit.  I expect this week will see some work on Labyrintheer as well as a little bit of toss up time on a different project I’ve been mulling over for a bit.  I have no plans to stop development on Labyrintheer, but RPGs are a dime a dozen, and to make something that’s actually interesting will take quite a bit of time, still.

So, to bridge that gap, I might do some very preliminary work on another project that I’ve had rattling around in my skull for a few months now – JUST to see how it looks in practice.

Stay tuned!

WIP: Wednesday Thursday

I’ve been working on a few items, the most recent of which has been lootable chests that have open and close animations and audio.  The animations and audio part are not something I have a lot of experience with, but the chest is thankfully fairly simple.

Right now I’ve defined a very specific Chest Controller, though I suspect I will transform this into a Usable Object Controller that will take an enum of it’s usability type (for environmental objects) like open/close, on/off, pick or gather (for reagents) and the like.  The video above is super simple, and is still a WIP.

Currently, the player will interact simultaneously with every interactable object within a radius.  The next step is to raycast or use a hidden collider to find the object most centered in front of the player and prevent interactions with objects behind the player.

It’s a start.

Work in Progress – 2017/10/17

A lot of core work on the project has been done over the past couple of weeks – and by core I mean behind the scenes.  Yeah, I say that a lot and rarely have something new to show, and this is one of those times.

However, as an independent developer, that’s how a lot of this process goes. I fixed the helium filled GelCube issue, and they seem to be functioning fairly well on their NavMesh.  Part of this was competing systems causing race conditions.  I toyed with the idea of using physics to drive them, disabling some of the Unity AI stuff, but that led me into a rabbit hole that I wasn’t in the mood to contend with.  Instead, I resolved the conflicts and they are now pathing along as they should.

I also added a physics material for them.  They’re made out of ice, and should slide around a bit more than other GelCubes and mobs in the game.  I’m also testing a fun bit where they may have items from their biome shoved inside them…  I mean, they’re likely to pick things up as they move about and grow, right?  I’m hoping this is a small detail that is cool in the long run.  We shall see.

I’ve started setting realistic masses for Rigidbodies as well.  The player has a mass of 81kg, and a full sized GelCube has a mass of 5444kg (who knew they were so heavy, but it does make sense).

Otherwise it’s been more boring: some maintenance to remove old assets that are no longer in play, some scripting for torches, creating static materials from SBSARs now that I have the walls and floors in a good place.  Oh, and modifying the Dungeon Architect DungeonRuntimeNavigation.cs file to support multiple meshes for multiple agents.  If you use DA and are interested, you can grab that here.

DungeonRuntimeNavigation Inspector
DungeonRuntimeNavigation Inspector

Basically you use an int[] to specify the NavAgentIDs that all your mobs will use and it builds all of their meshes and navigation data at the same time.  I know I’m not the only one who wondered for a while why I couldn’t use other NavMeshAgents in my Unity project.

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.

Making Materials and Models! Mmmmmmmm (M)Normal Maps?

Not being an artist can seem like one of the most daunting parts of going it alone (or mostly alone) as an indie dev.  I’m a fair photographer, but that’s as far as my artistic capabilities have previously taken me.  Most of my stick figures look, well… disfigured, and things like straight lines are as simple for me as writing in Martian.  But I’ve been really working to increase my skill set here, and be able to create things in Labyrintheer that actually LOOK pretty decent.

In light of that, I started by picking up some great models from InfinityPBR.  Andrew, the awesome dude behind iPBR (as I reference it for myself) includes some great PBR materials as SBSAR files (and recently SBS files) that really helped me delve into how materials work and what was meant by all of the components: normal, roughness, metallic, height (or specular and glossiness depending on your preferred workflow); metallic/roughness versus specular/glossiness; and a bit about what all of those components can do.

But this wasn’t enough customization for me.  As I’ve mentioned before I started using Archimatix to design some architectural models (which is still something I’m getting a handle on, simply due to the sheer variability of AX and its nodes).  As I worked through some (very simple) wall models and such, I realized that I also wanted more control over the materials themselves.  iPBR offers an INCREDIBLE amount of customization, but I’m just a pain in my own arse that way.  So the next step was…  Substance Designer.

For those new to the art game, Substance Designer is an amazing software package that lets you node-author your own materials and export SBSAR files that can be used to procedurally create materials in Unity (and I believe Unreal Engine).

The beauty of the node-driven design is that, while artist-type folk seem to settle into it easily enough, we logic-driven code monkey types can also create some really stunning work since everything can be reduced to parameters and inputs and outputs.  But before you can do any of this, you need to grasp some of the basics.  I’m not high-speed enough yet to really offer a tutorial, but I can share the wealth of tutorial love that I’ve been using.  So, let’s start with normal maps.

Normal Maps

I ran across this tutorial literally this morning, which is what brought me to create this post and share this info.  More blog post, less actual tutorial, the information about normal maps here is presented concisely, tersely, and with excellent clarity.  Even someone who has never heard of a material in game parlance before can probably understand what’s being explained.

The gist of normal maps is to provide interaction between the materials and light in your scenes.  This is not the same as metallic/roughness aspects, but more to “pretend” that there’s dirt, smudges, small deformities or other similar features on your object.  When making a material, you often preview it on a perfectly flat surface.  But you still want to see the details – details that offer a 3D appearance on a completely flat 2D plane.  This is where normal maps come in.

Let’s look at the image below, for instance:

Demon Head Emboss - Coin Face
Demon Head Emboss – Coin Face

This is meant to be the head of a coin I’m working on as sort of a self-tutorial.  The eye can easily see this as an embossed image, but due to the normal map, moving the light around changes how and where shadows happen.  Here the light is off to the left, so left of the “ridges” (it’s still just a flat plane) looks brighter, and right of them produces shadows.  If I were to move the light source to the other side, the opposite would be true.  This is how normal maps help reinforce the 3D appearance of an object that doesn’t have detailed modeling done.  This is a HUGE benefit to game performance – it’s much easier to draw a coin that is perfectly flat on both sides, and apply this material to make it appear 3D than it is to produce a 3D model with this level of detail.  Easier both in actual creation of the object as well as on your GPU for rendering it.

This video shows the coin in Unity.  The scuffs and scratches are both part of the base color of the item, but the deeper scratches are also mostly in the normal map, and allow light to fall into them or be occluded from them based on the light angle.  Note that in the above video, the edge of the coin are NOT flat, those are actually angled on the model itself.  That would not be a great use of attempting to use normal maps to provide a 3D effect (at least not in any way I would be able to do it).

That’s what I have for normal maps, for now.  But I plan to continue this as a growing series of posts on PBR materials to help demystify them for those of us new to this whole thing.

Substances, Dungeon Floors, New Workflow

I’ve picked up Substance Designer and have started working on some better assets for the Dungeon biome.  Right now what I have is a bit busy, but I thought I’d share some of what I’m doing.  I started with a great tutorial on Youtube, where the presenter was kind enough to offer up his SBS file.  I made a variety of modification and exposed some parameters, kicked out the SBSAR and loaded it into my staging project in Unity.

I created three separate materials and applied them to their own GameObjects that Dungeon Architect uses to generate the floor.  Right off the bat, it looked like this:

Attempt 1
Attempt 1

Like I said… busy.  But at least it’s more interesting than what I had before.  I decided to up the game by adding a random rotation – each floor is randomly rotated by 0, 90, 180, or 270 degrees.  That looked like this:

Attempt 2
Attempt 2

Still busy, but at least a little more random.  Then I felt that the stones shouldn’t always be the same size, so I set each to have slightly different numbers of tiled stones per object:

Attempt 3
Attempt 3

Lastly, it still seemed too busy, so I lowered the overall count of each.  One was 4×4, one 5×5, the last was 4×5 making some stones also not square.  That looks like this:

Attempt 4
Attempt 4

Now it’s less busy, more random feeling, and looks decent.  I think I’ll probably go back to the Substance a bit and see what I can do about breaking them up a bit more, but for my first modification of a substance I’m pretty pleased.