Design Docs - Thinking about Inventory - Part 6

At some point, we have to put on the big-boy pants, and think about actually making this inventory system code useful. It's nice to see our logic perform well under a vacuum setting (within the context of its own project). The whole point of making an inventory system is to have it be part of a game, right?

I've actually been dreading this post for a while. One of the main reasons why is because the whole intention of creating an inventory system was to have it be plugged into an existing JRPG game project.

Since I'm learning game development, and have only created toy engines in the past, knowing that I would have to have my code eventually be integrated into an existing game project is quite intimidating.

I don't know what it is exactly. I mean, I develop software for a living. I've integrated my code into much larger projects with confidence many times! How can this be any different? I think it's imposter syndrome. I've found that this happens to me quite often in life.

What am I even doing?

The fact that I know I'm a total noob at something makes me even more scared to actually take the first step. This is even when I really, really, really want to take action! 😞

However, we have all experienced some variation of this feeling. That's why we just have to "give it a shot".

Okay, all this is actually building towards a life-lesson in which I hope to serve as filler for this short post. I thought it'd be nice to share some of my life-philosophies:

I think it's important to listen to feedback from others. Having an open mind helps, and although cliche, we have really listen. I usually tell others that if they're going to give me some constructive feedback which happens to not be "very positive", they should probably do this:

  • Proceed with warning me in that the following words coming out of their mouth is not what I am going to enjoy hearing, but is something which can help me improve.

    • Hey, I noticed you've been doing X this way. There's actually a better way, and I'd like to share that with you...
    • What this does is that it enables me to push my attention towards listening carefully to that person more and allows me to brace myself for what is about to come. Who really does like criticism anyway? I don't, so I want to try my absolute best by not getting jumpy and defensive, and letting the person finish their thought.
  • Listen carefully to what they say... They're explaining something you could be doing better. Isn't that a favor?

  • Let the feedback process. Sleep on it. Consider it, and see how it can make you better.

  • Wash, rinse, repeat. (and maybe DRY? Punny. 😆)

Anyway, I ramble. I just started a new job this week. My mind has been jelly. So, I was just craving to write about something less theoretical, but still, useful to read. Also, I just want to write something more practical today. 😄

The Discussion

The goal of this chapter is to take the existing JRPG Inventory System which we have written, and:

  1. Integrate it into an existing project within Unity.
  2. Add tests to this new code, and have them be runnable through Unity Test Runner.

Code

There won't be any code to distribute for this chapter. The project I'm integrating with isn't open to everyone. I'm going to keep it within the context of the inventory system we've developed.

Integration

The integration should be fairly straight-forward. The only problems which should be anticipated is that Unity scripts run in .NET Standard 2.0 API compatibility level. The code we have written so far actually uses .NET Standard 2.1. Minor differences, but a big one for our project.

The main difference in our context here is that System.HashCode is not available in .NET Standard 2.0. Because of this, HashCode.Combine cannot be used to override the GetHashCode method in a class. We have done this in some of the POCO classes within the procedurally generated items component of the project.

I'm going to defer overriding GetHashCode the "right" way for now, and just remove those HashCode.Combine calls, and figure it out later. Let's just replace it with something like this for now... Take ItemClasssEdge for example:

public override int GetHashCode() 
{
	var toHash = Name + Weight.ToString();
	return tohash.GetHashCode();
}

It isn't the smartest thing to do, but it will get us working for now.

That is pretty much the main hurdle in this integration. The rest is just dropping files into the project, and making sure everything builds.

I've actually taken some time to fix up some of the folder structure while I was integrating stuff into the main Unity project.

New folder structure.

Notice how item related things are now within the Items namespace?

Tests

The last piece of this integration is to transfer all the tests into Unity. Since I am new to Unity, I had some help with these tutorials on how ot get set up with Unity TestRunner. It was actually simple to set up and be running.

There was one thing though... Our tests were written with xunit in mind!

As it turns out Unity TestRunner uses nunit. Ahhh!

Actually, it wasn't that bad. There were just a few key differences:

  • Tests are marked with [Test] as opposed to [Fact].
  • nunit actually supports [SetUp] and [TearDown] hooks. I refactored the tests to leverage these hooks.

Overall, transferring the tests from xunit to nunit actually made the tests shorter, and more readable. An unexpected win.

Once integrated, I ran all tests using Unity Test Runner in the Unity Editor.

All green tests!

All green!

Conclusion

Yes, this post was on the shorter side. 😄 It was nice getting some housekeeping done. This is all in preparation for the next exciting chapter of our story. It involves handling items which affect overall game state. For example "key items" to progress through a quest, or storyline within the JRPG.

So, stay tuned!