• Create Account

### #ActualScarabus2

Posted 04 April 2013 - 08:53 AM

Oh if you are in a position to set up a proper XML schema/tool workflow, do that! LEON was created for our own needs and made available to anyone that aren't able or willing to make that leap from a more notepad-based workflow. And to avoid misunderstanding let me reiterate that LEON partially stems from my own desire to create something for the fun of it.

We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.

Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.

Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.

​I agree that ambiguity is bad, but I honestly don't believe LEON is a large enough format to warrant much worries about that. Some rules are implicit, yes, but only where it makes sense.

If someone writes:

description: "He was a tall
and handsome man."


the parser (or I, rather) assumes they didn't want to keep the whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):

description = ("He was a tall
and handsome man.")


The worst example I can think of is if someone meant to write this:

enemy-health: 100


enemy-health 100

that would be a valid value to LEON but not a valid value to the game. But this isn't much different from any typo in any format, and by setting a flag in the parser you can catch this error at runtime.

### #5Scarabus2

Posted 04 April 2013 - 08:52 AM

Oh if you are in a position to set up a proper XML schema/tool workflow, do that! LEON was created for our own needs and made available to anyone that aren't able or willing to make that leap from a more notepad-based workflow. And to avoid misunderstanding let me reiterate that LEON partially stems from my own desire to create something for the fun of it.

We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.

Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.

Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.

​I agree that ambiguity is bad, but I honestly don't believe LEON is a large enough format to warrant much worries about that. Some rules are implicit, yes, but only where it makes sense.

If someone writes:

description: "He was a tall
and handsome man."


the parser (or I, rather) presumes they didn't want to keep the whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):

description = ("He was a tall
and handsome man.")


The worst example I can think of is if someone meant to write this:

enemy-health: 100


enemy-health 100

that would be a valid value to LEON but not a valid value to the game. But this isn't much different from any typo in any format, and by setting a flag in the parser you can catch this error at runtime.

### #4Scarabus2

Posted 04 April 2013 - 08:51 AM

Oh if you are in a position to set up a proper XML schema/tool workflow, do that! LEON was created for our own needs and made available to anyone that aren't able or willing to make that leap from a more notepad-based workflow. And to avoid misunderstanding let me reiterate that LEON partially stems from my own desire to create something for the fun of it.

We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.

Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.

Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.

​I agree that ambiguity is bad, but I honestly don't believe LEON is a large enough format to warrant much worries about that. Some rules are implicit, yes, but only where it makes sense.

If someone writes:

description: "He was a tall
and handsome man."


the parser (or I, rather) presumes they didn't want to keep the whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):

description = ("He was a tall
and handsome man.")


The worst example I can think of is if someone meant to write this:

enemy-health: 100


enemy-health 100

that would be a valid value to LEON, but not a valid value to the game. But this isn't much different +from any typo in any format, and by setting a flag in the parser you can catch this error programmatically.

### #3Scarabus2

Posted 04 April 2013 - 08:49 AM

Oh if you are in a position to set up a proper XML schema/tool workflow, do that! LEON was created for our own needs and made available to anyone that aren't able or willing to make that leap from a more notepad-based workflow. And to avoid misunderstanding let me reiterate that LEON partially stems from my own desire to create something for the fun of it.

We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.

Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.

Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.

​I agree that ambiguity is bad, but I honestly don't believe LEON is a large enough format to warrant much worries about that. Some rules are implicit, yes, but only where it makes sense.

If someone writes:

description: "He was a tall
and handsome man."


the parser (or I, rather) presumes they didn't want to keep the whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):

description = ("He was a tall
and handsome man.")


The worst example I can think of is if someone meant to write this:

enemy-health: 100


enemy-health 100

that wouldn't be a valid value, at least not to the game. But this is not much different from any typo, and by setting a flag in the parser you can catch this error programmatically.

### #2Scarabus2

Posted 04 April 2013 - 08:44 AM

Oh if you are in a position to set up a proper XML schema/tool workflow, do that! LEON was created for our own needs and made available to anyone that aren't able or willing to make that leap from a more notepad-based workflow. And to avoid misunderstanding let me reiterate that LEON partially stems from my own desire to create something for the fun of it.

We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.

Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.

Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.

​I agree that ambiguity is bad, but I honestly don't believe LEON is a large enough format to warrant much worries about that. Some rules are implicit, yes, but only where it makes sense.

If someone writes:

description: "He was a tall
and handsome man."


the parser (or I, rather) presumes they didn't want to keep the whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):

description = ("He was a tall
and handsome man.")


### #1Scarabus2

Posted 04 April 2013 - 08:36 AM

Oh if you are in a position to set up an XML schema and hook it all up to a visual tool, do that. LEON was created for our needs and those that aren't able or willing to make that leap from a cruder "notepad-based" pipeline.

We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.

Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.

Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.

I honestly don't believe LEON is a large enough format to warrant much woes that are associated with other formats. Some rules are implicit, yes, but only where it makes sense.
If someone wrote:

description: "He was a tall
and handsome man."


the parser presumes the user didn't want all that whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):

description = ("He was a tall
and handsome man.")


PARTNERS