Month: June 2017

Over the past few months, I have been researching and developing a little procedurally generated game which will eventually be created in the Godot engine. This game will have a story that’s procedurally generated for the players. A part of this game is the dialogue, which will also be procedurally generated. To accomplish this, I set out to find a library of some kind which can create procedurally generated dialogue (or at least the dialogue that I want) and is written in my programming language of choice, Python. From the looks of it, there isn’t one, and so I had to look elsewhere. That’s when I stumbled upon something called Rant. This is billed as a library which can procedurally generate dialogue. At first I thought I had found what I was searching for. Sadly, though, it is written in the least open source-friendly language I have ever seen: C#. This can be used on Linux (with the Mono runtime). But I’m looking for a solution where I don’t have to use a bunch of programming languages to achieve what I want.

At first, I tried making some kind of dialogue scheme that would suit my needs. I threw in some sentences of what may define the NPC, and mashed it all together. From the looks of it, though, the scheme is getting out of hand. I have several lines of dialogue, and I’m not even finished. I don’t entirely know how I’ll fit it all together, considering this is just for a simple demo of the full game. It looks like I’m going to have to get creative.

I went digging and searching around I came upon several possible ways of integrating C# code into Python code. There’s IronPython, a fully implemented version of Python in C#. The big problem with this was that it didn’t look very portable to me, as I would have to bundle the .NET libraries with the game for each platform, and that’s a royal pain the ass. Then I looked at Python.NET, which looked very promising: you can call some C# code from Python, and you can call some Python code from C#. It looked like the best of both worlds. Now, actually making it work is a bigger problem.

When I tried to use the Rant.dll assembly in my Python program, I found that I can’t do that because, well, it’s C# code, and the regular old CPython (which comes with many Linux distributions) can only import C or C++ code. Then I looked into using the clr module from Python.NET, but I couldn’t find a version built for Linux. Through a lot of hand wringing, brow beating, and code cracking, I found that I had to use the latest version of Mono (version 5.0.1) along with an unstable version of Python.NET. This one built with the suggested command: python setup.py build_ext --inplace. The built shared object library file, “clr.so”, and the “clr” module load in Python. Heck, I was even able to load the pre-built “Rant.dll”. But this is nothing compared what I must do now: actually making some procedurally generated dialogue with Rant. And I don’t know where to begin with that.

Last Friday, I did a panel at A-Kon 28 about starting out with Gimp. I had been wanting to do a panel for a while, so I prepared for this one. I followed the advice of the dynamic duo that is Vitamin H, and planned out what I was going to say, along with practice. While I did write out an outline, along with the practice, that didn’t really prepare me for the panel.

I practiced the panel at a local community college. While that served to focus what needed improving, I couldn’t get proper feedback on what was missing from the panel. I don’t know any artists, and friends of mine couldn’t take time off to come see it. Even when I recorded the practices, I couldn’t get people to look at it, nor critique it. So I had to just think of how the audience would react to it. I did this each Friday, for a few weeks, up until the convention.

Before I started the panel, I was nervous. I thought of how to properly show the panel, including the video set-up. I also looked at how few people were in line, so I thought that it would not be a big crowd. Then, when they allowed people in, the room quickly filled. At that point, I knew I was screwed.

I led off by introducing myself, talking about the program, and possibly where you can get it. Then I showed off some of my pictures. I showed one I made for Kirby’s Epic Yarn, along with a parody of a movie poster. When they laughed at the joke, I thought, “Nailed it.” But then it went downhill from there.

I kept trying to show the audience some of the finer details of Gimp, but I couldn’t exactly talk about the tools. The settings for the paintbrush tool were pretty self explanatory, so maybe I shouldn’t have gone in that direction. Also, the picture that I used for an example didn’t really seem to work for the audience. I had already inked it out, so I couldn’t show the full capabilities of the ink tool. I did talk about the “dynamics” feature, and I think they got that. But talking about how to use the bucket tool, and the selection tools just fell apart. Heck, I couldn’t even tell whether the audience was learning something.

Near the end of the panel, half the audience left. Those who did asked questions, and I was able to answer a few of them. One guy asked about the blending capabilities of Gimp, and so I tried to answer his question to the best of my abilities. I couldn’t understand whether he was talking about the blend modes of the layers, or the blending capabilities of the brush tool. Still, he kept his interest. Other people asked about the settings, but I couldn’t really answer that. From the looks of it, only a handful of the audience learned something.

The next time I do this, I’ll have to get people to give me feedback on what I’m planning. Also, I’ll have to define exactly for whom this panel is targeted.

Who Runs This Blog?

I'm Jason Anderson, a guy who messes with open source software, writes bad poetry, knows something about accounting, and wants to solve all of your I.T. audit requirements.