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.
( http://www.wizards.com/default.asp?x=d20/article/srdarchive )
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.
( http://en.wikipedia.org/wiki/The_Dark_Eye:_Blackguards )
( http://en.wikipedia.org/wiki/Neverwinter_Nights_2 )
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.
( http://dndsrd.net/spellsTtoZ.html#wish )
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.