#120478 - sgeos - Sun Mar 04, 2007 2:12 am
I am looking a data heavy project. I am thinking about completing the data tables before writing any code. Is there any reason not to do this?
-Brendan
#120481 - tepples - Sun Mar 04, 2007 2:51 am
When building a complex schema, it's best to test parts of it at once, and this needs code. You don't want to have to make deep, time-consuming changes when you realize you have a defect in the schema.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#120517 - keldon - Sun Mar 04, 2007 9:24 am
If the system is designed correctly then it is possible to write the data before writing code, but then the worst case scenario of the data format being a bad one is very damning when you have spent days producing the data. Maybe these problematic situations are more prevalent with beginners and isn't as much of an issue with more experienced people. And having said that it all depends on how much implementation is required. I can think up plenty of data heavy[ish] projects (not necessarily games) where there implementation is bog standard (simple).
#120520 - sajiimori - Sun Mar 04, 2007 10:12 am
If you format your data in a way that's easy to parse and emit, you won't get locked into any particular schema. A little Perl can rearrange a whole database into a new format, as long as the source data is well-formed. I say jump right in.
#120529 - sgeos - Sun Mar 04, 2007 12:59 pm
| sajiimori wrote: |
| If you format your data in a way that's easy to parse and emit, you won't get locked into any particular schema. A little Perl can rearrange a whole database into a new format, as long as the source data is well-formed. I say jump right in. |
The format is a spreadsheet output a tab separated values. Adding new columns/data features is a snap. I'll have to filter it using perl regardless.
-Brendan
#120536 - tepples - Sun Mar 04, 2007 2:38 pm
| sajiimori wrote: |
| If you format your data in a way that's easy to parse and emit, you won't get locked into any particular schema. |
If you have a table with personality info for each of 300 different clones that could move into your 100 acre village (with about 50 living there at once), and suddenly you realize you need two fields describing aspects that you hadn't thought of when you had your level monkeys fill in these personalities, it'll be very time-consuming for humans to generate this data. It's better to get the engine working with 30 possible clones than with 300.
| Quote: |
| A little Perl can rearrange a whole database into a new format |
But what will it do with the nulls?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#120539 - sgeos - Sun Mar 04, 2007 3:22 pm
| tepples wrote: |
| sajiimori wrote: | | If you format your data in a way that's easy to parse and emit, you won't get locked into any particular schema. |
If you have a table with personality info for each of 300 different clones that could move into your 100 acre village (with about 50 living there at once), and suddenly you realize you need two fields describing aspects that you hadn't thought of when you had your level monkeys fill in these personalities, it'll be very time-consuming for humans to generate this data. It's better to get the engine working with 30 possible clones than with 300. |
You can either go the algorithmic template route (code heavy and data heavy), or you can go the hard coded route (very data heavy). Either way, real values will have to be added eventually. You can always "fill down" with a default value until there is time to complete the data. Type changes will probably be time consuming. Great structure changes will result in a lot of work having to be redone; this always happens when things are changed. (Gold changes from a hard coded feature to a generic counter. Flags are merged with counters.)
| Quote: |
| Quote: | | A little Perl can rearrange a whole database into a new format |
But what will it do with the nulls? |
Whatever you want it to. I like to use "fill down" on the data, just to be safe. It also makes the perl filters cleaner.
My goal with this whole thing is make the coding session as short and as clearly defined as possible. I hate bugs and want to minimize the opportunity for them to appear.
-Brendan