DiceNotation: roll some dice in C#

So, in building out Anaeax, I needed a way to express random quantities for game systems: weapon damage, level-up effects, so on and so forth. Code is one thing, but the game uses SheetParser to maintain tabular lists of weapons, monsters, and so on and so forth—I don’t exactly want to be defining this stuff in a C# file, no matter how easy Exor makes it (and it is pretty easy).

I play tabletop games. Dice make sense to me; I have an OK understanding of the sorts of distributions you can put together from them and they’re at least reasonably intuitive for most people. So my first inclination was to go write a dice parser, something that could turn 3d6+10 into a usable range. But why build when you can steal, etcetera etcetera, and I found an abandoned project on CodePlex (with tests, even!) that I could bend to fit my needs, PCL and MathNet compatibility among them. The resulting fork of DiceNotation is on GitHub and NuGet (with the MathNet integration in a separate package).

While this is going to be used in the game, it’s also going to be used for something else: doing statistical analysis for game balance in Excel. Which means I get to learn how to bridge Excel and C#. Which means I need a lot more liquor.


Assembly.GetEntryAssembly() is tricky.

So something I learned when I was getting Exor ready for publication and was reminded of when I hit a bug with TiledSharp last night was that Assembly.GetEntryAssembly() has a trap door in it. Something a lot of people, myself included, seem to forget is that you can load managed assemblies from unmanaged code in .NET. When you do this, GetEntryAssembly() returns null.

This is documented, but in the regular case you won’t see this–your app runs, you get the entry assembly you expect, life is good. The unit test runner in Visual Studio (at least as of 2013), though, calls through unmanaged code. So does the XNA content pipeline, which I’m otherwise using happily with MonoGame.


Exor: an extensible add-in framework for .NET

As with my other projects over the last couple weeks, I’ve been on a kick where I pull useful stuff out of old projects and polish them up for an open-source release. Exor is a (somewhat) polished iteration on Anaeax’s mod system. It couples an attribute-based type mapping add-in system with a neat wrapper around CSharpCodeCompiler that allows an add-in (like, say, for a game) to compile and dynamically load .cs files that can provide those types.

Originally I only planned for this project, my MonoGame-based content management gizmo and SheetParser, but Versioner ended up being a useful side effect–it didn’t really make a lot of sense to put all of the versioning and dependency resolution into Exor just to lock it away from other projects that could use it.

Exor is on Github and NuGet (Core, Compiler) and is licensed under the MIT license.


More Github stuff: Versioner

While on vacation at my folks’ in Maine, I’ve been plugging away on extracting more common patterns from various old projects. One common issue I regularly run into is the need for maintaining versions of stuff and a dependency graph. There are no easy libraries for this stuff as in Ruby, so I’ve repeatedly reimplemented solutions in multiple projects. Decided to clean up the best of them, write a solid test suite, and open-source it as Versioner.

The source is available on Github and a compiled PCL is available on NuGet.


GitHub braggadocio: SheetParser

So I spent a little time pulling useful code out of old projects and threw SheetParser up on Github and NuGet. SheetParser is my simple parsing/deserialization tool for ripping spreadsheets and building C# objects out of them. It’s a niche library, borne out of doing game development; I use this to avoid writing a bunch of really dumb tools and instead using Excel to do my dirty work.

Mostly tested, too, though coverage isn’t complete. MIT licensed – have at it.


When all your tools are hammers…

…your thumbs are on notice.

Wait, that’s not right at all.

Anyway. Anaeax update—chewing through that final rewrite I mentioned a bit ago, a little more than halfway through. I hear tell it’s giving Peter a bunch of ideas, though he’s currently caught up in some other stuff and hasn’t had much time to progress on his side of things. (Neither of us need this game to eat, and we’re currently not considering a Kickstarter, so if it takes another eight years to come out—well, I’m not too worried.)

I’m in a blogging mood today, though, so I figured I’d talk briefly about the scripting layer. Readers of the old blog might remember that the scripting layer was a Rhino-based JavaScript interpreter that used Rhino’s general coolness to talk to the Java APIs inside the game. And that was rad. But we’ve switched tech to Mono for a number of reasons around tooling and platform-friendliness. While .NET has a couple different JavaScript libraries, none proved suitable for what I wanted. I wanted fast script execution but an option for no runtime code generation (which is disallowed on iOS, consoles, and so on).

This is harder than it sounds. JScript.NET requires runtime code generation and just doesn’t run on platforms without Reflection.Emit. Jint is cool and nobody knows about it, but I ran into a lot of trouble trying to make it play nicely with what I wanted—it was also pretty slow.

So I was complaining most vociferously about this to my buddy Sean, who has this habit of being good at things. Sean is a compilers guy, which scares me roughly on the level of “an axe-murdering guy” but in completely different parts of my psyche, and he’d done a bunch of Roslyn reading. (He doesn’t do much .NET, but, y’know. It’s an interest.) “What about using Roslyn to compile your scripts?”

“That’s horrib—wait, that’s brilliant.”

So off I went, code code code, and had something cranked out in a few hours. Not using Roslyn, which is still kind of new, but the (now) old standard, CSharpCodeProvider. (edit 1/2015: this is now Exor, which you can use separate from my game frameworky bits.) Scripts are just C#. On the first startup, Tracksuit (which is open-source, btw, use it in good health and send me pull requests (edit 1/2015: now Clank, itself soon to be open-sourced as well)) walks your mods/assets directories for .cs files and compiles them, caching the results for future runs, and loads them as their own assemblies. There’s some mod-level metadata to define mod dependencies used by the mod compiler to compile dependencies in the proper order and expose them as dependent assemblies to code further down the dependency tree. Attributes declare entry points and object unique IDs for use in other content; I kind of reinvented Mono.Addins in the process but couldn’t quite come up with a good way to reuse that instead of bolting in my own simple assembly-walker stuff (and I didn’t really want to be its new maintainer, either).

This whole approach doesn’t work on iOS, obviously. But that’s not a big deal, because what does work is precompiling the mod projects (all my content .cs files live in a .csproj) and embedding them. Already tested it. Works like a champ. My biggest concern thus far is security, because while .NET supports AppDomain and some security stuff, Mono (Mac and Linux) sure don’t. Then again, Minecraft mods are Java and can do anything they want on the system. There might just have to be some caveat modtor in there.