Friday, June 13, 2014

GuildCraft Dev Diary: Part V

Some information today about this project and the Open Gaming License (OGL). GuildCraft's rule set will be derived from a pen and paper RPG with an OGL System Reference Document (SRD).

The OGL was a great idea. It allows an RPG system to become widely known, and gives players a lower barrier to entry when they want to try a new setting or computer game. I'm also convinced that it leads to increased sales for the company that develops the RPG system. )

For non-Germans, one of the big weaknesses of Blackguards was the unfamiliar character building system. It offered both choice-paralysis and character building traps. Neverwinter Nights 2 had a similar set of challenges, but unlike Blackguards it used the well-known D&D 3.5 system. If a player wanted to learn more about the system, there were also a variety of reference websites with searchable versions of the SRD. ) )

My goal is to keep the rules as close as possible to the OGL SRD I base my project off of. Unfortunately, something like the D&D wish spell doesn't translate well to a computer game. The biggest compromises are will likely be with the out of combat rules.
( )

Since I will be using the OGL, the rule changes I need to make will become Open Gaming Content. Rather than do the bare minimum of an in-game codex, I'd also like to provide an online version. For lack of a better name, I'm going to refer to this consolidated set of changes as the Artificer SRD. It will be a complete representation of the in-game rules and also contain a page showing the changes from the base SRD.

Slightly more depth than Diablo 3.

This creates an interesting technical challenge. How best to define this large amount of data and present it in multiple ways without creating a maintenance nightmare?


  • Define the OGL SRD data once.
  • Only define the changes for the Artificer SRD.
  • Create cross-linked articles without manually inserting hyperlinks.
  • Produce two websites, and a set of data for the in-game codex.

XML's similarity to HTML and its human-readability made it a logical choice for the data format. This also implied an XSD file to define a schema for the data. After some consideration, I decided to use C# and LINQ to process the the XML instead of XSLT. Some of the processing I want to do would be difficult or impossible with XSLT, and this was a good opportunity to become more familiar with LINQ.

Less-than-two inputs; three outputs.

It has been a long time since I've used HTML or CSS. Both have improved considerably since then. I'm not using a WYSIWYG editor like Dreamweaver because all of my HTML is dynamically generated. I did, however, find a free program called Brackets that makes authoring CSS a much more enjoyable experience. It allows you to activate a dynamic preview that updates your webpage in real-time as you edit the code.

  • Aside: Seeing the mess that JavaScript is still in, I finally understand Microsoft's TypeScript initiative. I'm glad that my project will only require a single tiny .js file.
( )


No comments:

Post a Comment