Archive for July, 2018

RPG Development Progress Pulse – Entry 2

Progress Pulse

Progress Pulse – Entry 2

Things have been pretty busy in real life the past couple of weeks, so I haven’t had too much time for working on this. However, for this entry in the progress pulse series I’ll talk about some of the challenges I had while looking at making a generic data (de)serialization API + implementation, and why I chose to make some of the decisions I did!

Which Tech To Pick?

I’ve felt burned in the past by trying to do data serialization for my game framework because it’s always created a barrier for refactoring once it’s in place (i.e. i change some data i need and now i have to re-make or migrate allllll my SQL data).

So I was thinking about how I plan to store game state, which I have written about, and then considered the implementations I had considered for persistent storage. One of them was a graph database called Neo4j, which has a JSON representation of all of its node data. Except… I’m not ready to commit to Neo4j just yet because I don’t want to feel tied down (like I used to tie myself down to SQLite). But my objects I’m creating *are* well suited to hierarchies of entities+components, so maybe JSON is a happy medium?

Here was my breakdown for starting with JSON:

Pros:

  • Very easy to get started with
  • (De)Serialization libraries available via nuget for free
  • Human readable which is great for creating, editing, and debugging
  • Hierarchical, which lends itself well to my data structures in memory
    • Should make refactoring easy (did a component change? only change that component’s data representation)
  • Could be a stepping stone for working with Neo4j in the future

Cons:

  • Writing is probably slow, especially if I want to just modify one chunk of JSON data
    • Likely will need to write whole JSON blobs out… But who knows if it’s slow, I need to benchmark it.
  • I suspect lookups would be slow
    • But… Maybe important data is cached in memory on startup? Maybe it’s not even an issue. Benchmark it.

Basically, I was left with a bunch of pros and a couple of cons that were really just speculation. Seemed like a great way to get started!

Lesson learned was to start with something that won’t keep you locked in, but is also just enough to get you going!

Start With Something Specific

I’m a sucker for trying to make really generic things in software. It’s an extreme I find myself taking because I want to make things as extensible and re-usable as possible. The side effect of it though is that sometimes I miss corner cases (and they end up being not corner cases in the general sense) or that I make APIs that suck to use because they’re so general and maybe they shouldn’t be.

I decided I was going to switch up my approach. I wanted to figure out how I could serialize and deserialize my item definition data. That probably warrants a brief explanation:

I want items (i.e. loot) in the game to be part of a system that can control generation of them based on game state, randomness, and pre-defined organization of loot. Some drops might be totally random common items. Others might be based on quest state and need to be very specific. Maybe there’s some that only drop at a specific time of day during specific whether after killing a certain enemy. This is what I’m shooting for. So the item definitions will contain information about how to generate a base item, and provide components that tell the game how to mutate that base item (i.e. set damage to a value between 5 and 10 and call it “Axe”). But there are drop tables that have weights associated with them that can link to specific items or other drop tables. This allows the game’s content creator to generate loot that’s like “When the player is in the swamp lands, common enemies drop between 1-3 items, with a 60% chance of those items being junk, 20% chance of those items being normal equipment, 15% chance of those items being magic equipment, and 5% chance of those items being powerful legendary equipment”. Drop tables are essentially nodes with weights on the vertices that point to other tables or specific item definitions. Simple 🙂

The reason I went with this approach is because I felt that even though some of the C# types I have might be specific to item definitions, the abstract structure of the types (i.e. entities with components on them) is shared across many different game systems. So if I can make it work for this one, it shouldn’t be too hard to do for the next.

Lesson learned was try not to repeat all of your history… Learn from it. Experiment with new approaches.

Hello Singletons, My Old Friend

My arch-nemesis Dr Singleton! Actually, way back I’ve written about singletons so I’m not TOTALLY against them, I just think that 99% of the time they aren’t actually what you need. Let’s talk about my little run in with them though.

I started custom writing some APIs for JSON serialization that would use Newtonsoft JSON behind the scenes. Based on the structure of my objects, I figured I was going to have some sort of recursive call system going on where children would have to tell their children to serialize, etc… Once I got this working for a simple case, I realized that Newtonsoft has custom converters you can set up. These use attributes to mark up interfaces/classes to tell the serialization engine to use particular converters when they encounter a type. (Edit: after writing this I realize that I don’t HAVE to use the attribute… which might make this whole point moot)

The problem with attributes is that I cannot control the instantiation of them. And because I can’t control the instantiation of them, I can’t control the parameters passed in via the constructor. In my particular case, I needed to create a singleton that this attribute class could access and use Autofac to configure the singleton instance. Essentially, I needed to register custom handlers into my singleton instance, and then the attribute class could pull the registrations from the singleton instance.

Ugly pattern? Yes. I’m not familiar with any other ways to pass information or access to objects when I can’t control the initialization of my object though. It’s buried deep down so it’s not like the API usage feels like garbage, but still wasn’t happy with it.

Lesson learned here was sometimes we end up using “bad patterns”, but if they’re limited in scope we can limit their “badness”.


Autofac Modules and Code Organization

Organizing Code With Autofac Modules

What are Autofac Modules?

I’ve been writing a little bit about Autofac and why it’s rad, but today I want to talk about Autofac modules. In my previous post on this, I talk about one of drawbacks to the constructor dependency pattern is that at some point in your application, generally in the entry point, you get allllll of this spaghetti code that is the setup for your code base.

Essentially, we’ve balanced having nice clean testable classes with having a really messy spot in the code. But it’s only ONE spot and the rest of your code is nice. So it’s a decent trade off. But we can do better than that, can’t we?

Autofac modules!

We can use Autofac modules to organize some of the code that we have in our entry point into logical groupings. So an Autofac module is an implementation of a class that registers types to our dependency container to be resolved at a later time. You could do this all in one big module, but like many things in programming, having some giant monolothic thing that does ALLLL the work usually isn’t the best.

An Example of Converting to Autofac Modules

Let’s create a simple application as an example. I’ll describe it in words, and then I’ll toss up some code to show a simple representation if it. We’ll assume we’re using dependencies passed as interfaces via constructors as one of our best practices, which makes this conversion much easier!

So our app will have a main window with a main content area and a header area. These will be represented by three objects. Our application will also have a logger instance that we pass around so classes that need logging abilities can take an ILogger in their constructor. But our logger will have some simple configuration that we need to do before we use it.

Let’s assume to start our Program.cs file looks like this:

internal sealed class Program
{
    private static void Main(string[] args)
    {
        var logger = new FileLogger();
        logger.LogLevel = LogLevel.Debug;
        logger.FilePath = "log.txt";

        var header = new FancyHeader(logger);
        var content = BoringMainContent();
        var window = new MainWindow(header, content);
        window.Show();
    }
}

Before getting comfortable with Autofac, my initial first step would be to logically group things in the main method. In this particular case, we have something simple and surprise… it’s all grouped. But my next step would usually be to pull these things out into their own methods. I do this because it helps me identify if my groupings make sense and where my dependencies are. Let’s try it!

internal sealed class Program
{
    private static void Main(string[] args)
    {
        var logger = InitializeLogging();
        var window = InitializeGui(logger);
        window.Show();
    }

    // no params passed in, so no dependencies
    // return value is an ILogger, so we have a
    // logical grouping that will provide us a logger
    private static ILogger InitializeLogging()
    {
        var logger = new FileLogger();
        logger.LogLevel = LogLevel.Debug;
        logger.FilePath = "log.txt";
        return logger;
    }

    // only parameter is a logger, so that's our dependency
    // return value is a window, so this grouping provides
    // a window for us
    private IWindow InitializeGui(ILogger logger)
    {
        var header = new FancyHeader(logger);
        var content = BoringMainContent();
        var window = new MainWindow(header, content);
        return window;
    }
}

Alright cool. So yes, this is a bit of extra code compared to the initial example, but I promise you grouping these things out into separate methods as a starting point when you have a LOT of initialization logic will help a ton. Once they are in methods, you can pull them out into their own classes. Refactoring 101 for single responsibility principle going on here 😉 BUT, we’re interested in Autofac. So what’s the next step?

We have two logical groupings going on here in our example. One is logging and the other is for the GUI. So we can actually go ahead and make two Autofac modules that do this work for us.

public sealed class LoggingModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .RegisterType<FileLogger>()
            .AsImplementedInterfaces() // FileLogger will be resolved as an ILogger
            .SingleInstance() // we only ever need to use one logger instance for our app
            .OnActivated(x =>
            {
                // this handles our extra setup we had for this object
                x.Instance.LogLevel = LogLevel.Debug;
                x.Instance.FilePath = "log.txt";
            });
    }
}

public sealed class GuiModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .RegisterType<FancyHeader>() // this has a dependency on ILogger, but autofac will figure it out for us
            .AsImplementedInterfaces() // FancyHeader will be resolved as IHeader
            .SingleInstance(); // we only ever need to use one instance for our app
        builder
            .RegisterType<BoringMainContent>()
            .AsImplementedInterfaces() // BoringMainContent will be resolved as IContent
            .SingleInstance(); // we only ever need to use one instance for our app
        builder
            .RegisterType<MainWindow>() // Autofac will resolve our IHeader and IContent dependencies for us
            .AsImplementedInterfaces() // MainWindow will be resolved as IWindow
            .SingleInstance(); // we only ever need to use one instance for our app
    }
}

And those are our two logical groupings for modules! So, how do we use this and what does our Main() method look like now? I’ll demonstrate with one way that works for a couple modules, but I want to follow up with another post that talks about dynamically loading modules. If you can imagine this scenario blown out across MANY modules, you’ll understand why it might be helpful.

The idea for our Main() method is that we just want to resolve the one main dependency manually and let Autofac do the rest. So in this case, it’s our MainWindow.

private static void Main(string[] args)
{
    // create an autofac container builder
    var containerBuilder = new ContainerBuilder();

    // manually register our two new modules we made
    containerBuilder.RegisterModule<LoggingModule>();
    containerBuilder.RegisterModule<GuiModule >();

    // create the dependency container
    var container = containerBuilder.Build();

    // resolve and use our main dependency by it's interface
    // (because we shouldn't care what the implementation is...
    // that was up to the configuration via modules!)
    var window = container.Resolve<IWindow>();
    window.Show();
}

In Summary…

This example showed us how to group your main initialization logic out into groups that would play nice as Autofac modules. In a really simple example, having modules might look like bloated extra code, but it already illustrated that your entry point is very simple and follows a pattern to extend (just register another module for more dependencies… and I’ll add more on this later). There’s also an obvious way to group more new logic into your application for dependencies! So discussed logging and GUI initialization, but you could extend this to:

  • User Settings
  • Analytics/Telemetry
  • Error Reporting
  • Database Configuration
  • Etc… Just add more modules!

Sometimes the pain of having a really hectic entry point isn’t realized until you’ve had to work on teams where people are modifying the same beast of an entry point all the time:

  • Simple merge conflicts in your “using” statements… Because there’s hundreds of lines of using statements at the top of the file
  • Visual studio actually CANNOT use intellisense properly when the file gets too unwieldly
  • The debugger cannot resolve variables properly when the main entry point gets too big
  • Merging and auto-conflict resolution sometimes results in code just getting blown away in the entry point… And good luck finding what went wrong in your thousands of lines of initilization

So what’s next? Well, if you keep building out your app you might notice you have tons of modules now. Your single GUI module might have to get broken out into modules for certain parts of the GUI, for example, just to keep them more manageable. Maybe you want plugins to extend the application dynamically, which is really powerful! Our method for registering modules just isn’t really extensible at that point, but it’s very explicit. I’ll be sharing some information about automatic Autofac module discovery and registration next!


  • Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress