• Create Account

Need scary sound effects or creepy audio loops for your next horror-themed game? Check out Highscore Vol.3 - The Horror Edition in our marketplace. 50 sounds and 10 loops for only $9.99! ### #ActualHodgman Posted 03 April 2012 - 11:04 PM I initially started by referring to resources (possibly the same thing as "asset names") however I had a few collisions here and there and I later switched to using file names directly. I didn't like this and I don't like it now, I want to go back to asset names in the future however I am still unsure on how to deal with naming collisions and in general provide a fine degree of flexibility. Perhaps it would be just better to give better naming conventions? Suggestions on rules about resource->file mappings? My build tool scans the entire content directory and builds a map of filenames to paths. If the same filename appears at multiple paths (e.g. content/lvl1/foo.png, content/lvl2/foo.png), then a boolean is set in the map, indicating that this name->path mapping is conflicted. When evaluating build rules, this table is used to locate input files on disk. If an entry from the table is used that has it's conflict flag set, then the tool spits out an error (describing the two paths) and refuses to build your data. This is similar to bad code spitting out assertion failures and refusing to run. Because my particular data-compiler is designed to always be running, it listens to changes to the content directory, and if you create a duplicate file, I can pop up one of those annoying bubbles from the system tray, letting you know you've just made a potential conflict before you even try to build your data. Regarding naming conventions, I can somewhat enforce these by specifying them in my build rules. For example, if I wanted to disallow "foo.texture" and enforce "foo_type.texture", where "type" is some kind of abbreviation, I can set only rules that contain "_type". Let's say one of my "types" is "colour+alpha", and that I want the artists want to author colour and alpha seperately. Rule(TexCombiner, "temp/(.*)_ca.tga", {"$1_c.tga", "$1_a.tga"}) Rule(TexCompiler, "data/(.*)_ca.texture", "temp/$1_ca.tga"		)
Then, if someone sets up a material to link to "foo_ca.texture", the data compiler follows this sequence:
Build: data/foo_ca.texture
*Matches rule: "data/foo_ca.texture", inputs are "temp/foo_ca.tga"
**Build: temp/foo_ca.tga
***Matches rule: "temp/(.*)_ca.tga", inputs are "foo_c.tga" and "foo_a.tga"
***Search content map for "foo_c.tga" and "foo_a.tga"
***Run plugin: TexCombiner, inputs {"content/bar/foo_c.tga", "content/bar/foo_c.tga"}, output "temp/foo_ca.tga"
*Run plugin: TexCompiler, input "temp/foo_ca.tga", output "data/foo_ca.texture"

Whereas, if someone sets up a material to link to something like "foo.texture", which doesn't follow the convention, the data compiler follows this sequence:
Build: data/foo.texture
*Error: No rule matches "data/foo.texture"

### #3Hodgman

Posted 03 April 2012 - 11:03 PM

I initially started by referring to resources (possibly the same thing as "asset names") however I had a few collisions here and there and I later switched to using file names directly. I didn't like this and I don't like it now, I want to go back to asset names in the future however I am still unsure on how to deal with naming collisions and in general provide a fine degree of flexibility.
Perhaps it would be just better to give better naming conventions?
Suggestions on rules about resource->file mappings?

My build tool scans the entire content directory and builds a map of filenames to paths. If the same filename appears at multiple paths (e.g. content/lvl1/foo.png, content/lvl2/foo.png), then a boolean is set in the map, indicating that this name->path mapping is conflicted.

When evaluating build rules, this table is used to locate input files on disk. If an entry from the table is used that has it's conflict flag set, then the tool spits out an error (describing the two paths) and refuses to build your data. This is similar to bad code spitting out assertion failures and refusing to run.

Because my particular data-compiler is designed to always be running, it listens to changes to the content directory, and if you create a duplicate file, I can pop up one of those annoying bubbles from the system tray, letting you know you've just made a potential conflict before you even try to build your data.

Regarding naming conventions, I can somewhat enforce these by specifying them in my build rules.
For example, if I wanted to disallow "foo.texture" and enforce "foo_type.texture", where "type" is some kind of abbreviation, I can set only rules that contain "_type". Let's say one of my "types" is "colour+alpha", and that I want the artists want to author colour and alpha seperately.
Rule(TexCombiner, "temp/(.*)_ca.tga",	 {"$1_c.tga", "$1_a.tga"})
Rule(TexCompiler, "data/(.*)_ca.texture", "temp/$1_ca.tga" ) Then, if someone sets up a material to link to "foo_ca.texture", the data compiler follows this sequence: Build: data/foo_ca.texture *Matches rule: "data/foo_ca.texture", inputs are "temp/foo_ca.tga" **Build: temp/foo_ca.tga ***Matches rule: "temp/(.*)_ca.tga", inputs are "foo_c.tga" and "foo_a.tga" ***Search content map for "foo_c.tga" and "foo_a.tga" ***Run plugin: TexCombiner, inputs {"content/bar/foo_c.tga", "content/bar/foo_c.tga"}, output "temp/foo_ca.tga" *Run plugin: TexCompiler, input "temp/foo_ca.tga", output "data/foo_ca.texture" Whereas, if someone sets up a material to link to something like "foo.texture", which doesn't follow the convention, the data compiler follows this sequence: Build: data/foo.texture *Error: No rule matches "data/foo.texture" ### #2Hodgman Posted 03 April 2012 - 10:59 PM I initially started by referring to resources (possibly the same thing as "asset names") however I had a few collisions here and there and I later switched to using file names directly. I didn't like this and I don't like it now, I want to go back to asset names in the future however I am still unsure on how to deal with naming collisions and in general provide a fine degree of flexibility. Perhaps it would be just better to give better naming conventions? Suggestions on rules about resource->file mappings? My build tool scans the entire content directory and builds a map of filenames to paths. If the same filename appears at multiple paths (e.g. content/lvl1/foo.png, content/lvl2/foo.png), then a boolean is set in the map, indicating that this name->path mapping is conflicted. When evaluating build rules, this table is used to locate input files on disk. If an entry from the table is used that has it's conflict flag set, then the tool spits out an error (describing the two paths) and refuses to build your data. This is similar to bad code spitting out assertion failures and refusing to run. Because my particular data-compiler is designed to always be running, it listens to changes to the content directory, and if you create a duplicate file, I can pop up one of those annoying bubbles from the system tray, letting you know you've just made a potential conflict before you even try to build your data. Regarding naming conventions, I can somewhat enforce these by specifying them in my build rules. For example, if I wanted to disallow "foo.texture" and enforce "foo_type.texture", where "type" is some kind of abbreviation, I can set only rules that contain "_type". Let's say one of my "types" is "colour+alpha", and that I want the artists want to author colour and alpha seperately. Rule(TexCombiner, "temp/(.*)_ca.tga", {"$1_c.tga", "$1_a.tga"}) Rule(TexCompiler, "data/(.*)_ca.texture", "temp/$1_ca.tga"        )
Then, if someone sets up a material to link to "foo_ca.texture", the data compiler follows this sequence:

Build: data/foo_ca.texture
*Matches rule: "data/foo_ca.texture", inputs are "temp/foo_ca.tga"
**Build: temp/foo_ca.tga
***Matches rule: "temp/(.*)_ca.tga", inputs are "foo_c.tga" and "foo_a.tga"
***Search content map for "foo_c.tga" and "foo_a.tga"

Whereas, if someone sets up a material to link to something like "foo.texture", which doesn't follow the convention, the data compiler follows this sequence:

Build: data/foo.texture
*Error: No rule matches "data/foo.texture"

### #1Hodgman

Posted 03 April 2012 - 10:58 PM

I initially started by referring to resources (possibly the same thing as "asset names") however I had a few collisions here and there and I later switched to using file names directly. I didn't like this and I don't like it now, I want to go back to asset names in the future however I am still unsure on how to deal with naming collisions and in general provide a fine degree of flexibility.
Perhaps it would be just better to give better naming conventions?
Suggestions on rules about resource->file mappings?

My build tool scans the entire content directory and builds a map of filenames to paths. If the same filename appears at multiple paths (e.g. content/lvl1/foo.png, content/lvl2/foo.png), then a boolean is set in the map, indicating that this name->path mapping is conflicted.

When evaluating build rules, this table is used to locate input files on disk. If an entry from the table is used that has it's conflict flag set, then the tool spits out an error (describing the two paths) and refuses to build your data. This is similar to bad code spitting out assertion failures and refusing to run.

Because my particular data-compiler is designed to always be running, it listens to changes to the content directory, and if you create a duplicate file, I can pop up one of those annoying bubbles from the system tray, letting you know you've just made a potential conflict before you even try to build your data.

Regarding naming conventions, I can somewhat enforce these by specifying them in my build rules.
For example, if I wanted to disallow "foo.texture" and enforce "foo_type.texture", where "type" is some kind of abbreviation, I can set only rules that contain "_type". Let's say one of my "types" is "colour+alpha", and that I want the artists want to author colour and alpha seperately.

Rule(TexCombiner, "temp/(.*)_ca.tga",     {"$1_c.tga", "$1_a.tga"})
Rule(TexCompiler, "data/(.*)_ca.texture", temp/(.*)_ca.tga        )

Then, if someone sets up a material to link to "foo_ca.texture", the data compiler follows this sequence:

Build: data/foo_ca.texture
*Matches rule: "data/foo_ca.texture", inputs are "temp/foo_ca.tga"
**Build: temp/foo_ca.tga
***Matches rule: "temp/(.*)_ca.tga", inputs are "foo_c.tga" and "foo_a.tga"
***Search content map for "foo_c.tga" and "foo_a.tga"

Whereas, if someone sets up a material to link to something like "foo.texture", which doesn't follow the convention, the data compiler follows this sequence:

Build: data/foo.texture
*Error: No rule matches "data/foo.texture"

PARTNERS