Mysterious Deaths

I have now rewritten my Norman interpreter three times. It is now, so far, this iteration is working great. The previous attempt was riddled with strange silent crashes.
Java would run, reading through the game definition files, performing trimming and substrings and other String parsing methods. Then unexpectedly Java would just crash. No error message, nothing. I spent hours adding output messages all throughout the code, but was never able to pinpoint the source of Java's sudden death.
After giving myself numerous concussions on my desk I decided to scrap the interpreter and rebuild it. This time around I filled every block of logic with try/catches and more comprehensive output messages. And I improved how it processed the files.
So far so good. we'll see how it does as I convert more of my game definitions to Norman Notation.
I would really like to know what methods are prone to causing Java to quietly and horribly die. If this ever comes up again I suppose I'll be spending days and days trying to solve the mysterious mystery.

Impressive Line Count, Dawg

While huge source code line counts make for great fish tales they are no good. At least in the context of this post. So I've created NormanNotation (nrmn), an interpreter for it, and a parser that uses the parsed objects to populate WorldWeaver (My IntFiction game engine) game databases. The problem is my interpreter is kind of basic so far and requires property elements to be on their own line. That means defining an attribute goes from XML's single line to four lines in nrmn!
This makes game definition files very difficult to read. Half of an element's definition is off the screen so all you see are a bunch of closing brackets. Even if your editor does code collapsing it's tough to keep track of where you are in the nested element nodes. So I've updated the interpreter to allow inline properties so instead of:

{object
  alias=sword1
  type=long sword
}

You can do:

{object alias=sword1 type=long\ sword
}

Closing brackets still must be on their own at this point, I'll probably correct that tonight. For most elements it isn't a problem but things like attributes would look weird. So it will go from:

{attribute alias=strength value=15
}

To:

{attribute alias=strength value=15}

Then I'll go through my definitions and make them much more readable.

It's a Thing

Norman Notation is now a thing. I've defined the data serialization language and written a Java parser for it. I converted my XML game definition parser to Norman Notation and the resulting data looks good so far. Now I need to convert all of my game definitions over to it.
I've done a few so far and they're really easy to write. They do use more lines of code though, which makes them more difficult to read at a glance - we'll see if that's a problem. If so I may need to tweak the Notation definition and parser to allow same-line definitions.

A First for Everything

Tonight I created the Norman Notation. I've never tried creating a notation language - or any language for that matter. So far I have come up with a set of rules for the language as well as an interpreter.
The interpreter parses through a file and returns a list of elements each with their own properties and elements. I haven't yet begun converting my XML parser to use nrmn notation. But my test output looks promising. So far game definitions in the new format are much more succinct than XML, however they result in more lines of code - mainly because closing brackets (} or ]) must be on their own lines - but it is much less tedious than writing XML nodes.

What is Norman Notation?

It seems that YAML is not very conducive to defining IntFiction (IF) games for my IF game engine. I still want to move to something less tedious than XML, so after battling with various options I've decided to create my own notation language. Since I'm the one making it, I'm calling it Norman Notation (*.nrmn).
My needs for NRMN are very simple since I'm replacing a basic XML structure. My rules are:
- Minimal markup. I want it to be very easy to write so that game authoring is fun.
- Not indent dependant. Authors should be able to format their source however they want.
- Easy to nest elements. I need it to be easy to define child/parent relationships just like XML.

The only types I need right now are:
- Elements. These are 'objects' that can hold any combination of types.
- Properties. These are key/values and can be defined within an element.
- Content. These contain text, and can be multi-line. They can be defined within an element.

Special characters:
There are only three characters to watch out for:
- Curly brackets {...}
- Square brackets [...]
- Equals = (But only if in properties)
These can be escaped with a backslash \.

Example:
{game
    name=Dragon Deep
    level=0

    {player
        name=Conan
        class=Barbarian

        {weapon
            type=Long Sword
            [description
The long sword is a two handed weapon.
Its blade is dual-edged.
            ]
        }
    }
}

I'm working on building a parser for it now. We'll see how it evolves as I begin to use it.

Let Noobs Eat Cake, Wait I Want Some!

So in reading about Javascript and its relaxed nature has me pondering which is better? Novice-friendliness or strictness. I personally would lean toward the strict end of the spectrum. Although I can get behind a little leniency, just to make life livable. It seems to me that strictness would make debugging much easier and the resulting code much more consistent and readable.
I also kind of like the idea of not doing everything for you. Yes that means more code to write, but it also means you have more control. My current IF game engine is a good example. Whereas TADS or Inform will handle pre-defined commands and output etc, If your needs don't fit neatly into that structure you are in for nightmares. I've taken a more c++ like approach where the game author must define nearly all the commands and output. It's easy to do, but requires more definitions. However, games can use whatever input/output the author wants.
Authors could make their games behave however they want, but at the same time it is strict. If you want user input you must have correctly defined command nodes. To change attributes or move objects or the player etc, you must have a properly defined actionset, and that must contain action nodes, properly defined. Yet it's loose enough to allow an author the flexibility to use the engine how they want. They could even use it as a console based help system if they like.
I remember trying to build an Alice in Wonderland game in TADS, it was a pain just to get the player to be able to drink from the Drink Me bottle. In my engine, you would just define a command with the syntax "drink*" and put an actionset in it.
So I can understand looseness, but couched in a properly strict core structure. You can't define an action node and expect it to behave like a logic node. It seems to me that is akin to some of the flexibility in js. But then again I'm kind of noobish in js.