I like your variable naming convention. It's basically what we started doing already. Whatever naming convention we settle on should be put up on the wiki as a guideline for everyone. On Thu, Jul 9, 2009 at 1:16 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote: > hey for the global variable thing w/ a bunch named similar things i > completely agree. > > on my todo list is to make it so global vars have to be pre-defined in a > special file where you have to give their name, and a description of what > they are for. > > i think for location specific information we would use a similar format as > the art like... > > MysticForest/LowerForest/ForestA1/Chest1Opened > MysticForest/LowerForest/ForestA1/Door1Opened > > etc > > then for player stats do something like > > Player/Stats/Strength > Player/Stats/Agility > > etc > > what you think? > On Thu, Jul 9, 2009 at 12:20 PM, Kent Petersen <kentkmp@xxxxxxxxx> wrote: > >> Basically implementing the organization system is a bit of tedious work. >> We would need to tell svn to rename/move all the folders. Then we would need >> to go into every map, enemy, script used and make sure that all the links >> still connect right. There will be lots of room for human error >> >> Global variables - I'm betting there are going to be tons of them. I >> forsee there being a lot of flags to see if something has been done or not. >> I also forsee a problem with similarly named/functioned variables. For >> example I already have a variable to see if you talk to the old man for the >> first time but there will probably be a variable later for talking to him on >> another visit. I'm betting that any area with a lot of dialogue will need >> global variables to keep of what was said, all stats will need them, etc >> >> I don't know about organization I think it could go either way. We should >> just pick one and run with it. >> >> >> On Thu, Jul 9, 2009 at 12:12 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote: >> >>> Yeah your concern makes sense. >>> >>> I was thinkin we could have a "props" folder in /art/models/ and break it >>> down into subfolders by type (ie furniture, trees, etc) so that for things >>> that were re-used in multiple places we'd put it there. >>> >>> Eric's idea took that one further that we could just have "common" >>> folders whereever needed. >>> >>> Like if something was re-used in the "mystic forest" we could have >>> /art/models/mystricforest/common/ where all the shared stuff across the >>> areas of the mystic forest go. >>> >>> so we'd have location specific stuff, and then also common folders at >>> various scopes that had art that was shared within their scope. >>> >>> make sense? >>> On Thu, Jul 9, 2009 at 12:07 PM, Nick Klotz <roracsenshi@xxxxxxxxx>wrote: >>> >>>> I believe we should build a file structure that breaks things down by >>>> type, rather than local for models. Textures should be broken down by >>>> area. >>>> Say you have multiple types of an enemy Knight. Say, a Dark Knight and a >>>> Light Knight; dark knights are habitable in some obelisk; light knights are >>>> habitable in a temple. Lets say later on you want to use both knights in >>>> the same area, perhaps a "final area" or an arena of some sort. >>>> >>>> Instead of having duplicate entries for Dark Knight and Light Knight in >>>> /art/models/mobs/obelisk/darkknight, lightknight, darkknight texture, >>>> lightknight texture, etc etc. >>>> /art/models/mobs/temple/ >>>> /art/models/mobs/arena/ >>>> /art/models/mobs/finalarea/ >>>> >>>> or having to fish around in various folders looking for where to script >>>> in the mob and appropriate texture, you could just go to... >>>> >>>> /art/models/mobs/Knight >>>> /art/textures/mobs/Dark, Light >>>> >>>> >>>> Similarly it would apply to traps, building structures, etc. A pillar >>>> used in FirstTemple may be able to be used in another temple using a >>>> different texture, even the floors and walls can be reused many times. >>>> >>>> /art/models/buildings/floor/floorsize rather than having different >>>> floor/wall models for every map (which will eventually create TONS of >>>> reduntant files) >>>> >>>> /art/models/buildings/structures/pillar >>>> then call the appropriate textures by >>>> >>>> /art/textures/buildings/firsttemple/pillargranite >>>> /art/textures/buildings/obelisk/pillarmarble >>>> >>>> >>>> There are a lot more uses than what's listed above, but that should give >>>> everyone a decent idea of what I'm going for here. >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jul 9, 2009 at 1:44 PM, eric drewes <figarus@xxxxxxxxx> wrote: >>>> >>>>> well nick the issue is that there is no perfect way to do it that would >>>>> suit all of our needs, basically i think we just need to pick something >>>>> and >>>>> be consistent - there are downsides and upsides to almost any system when >>>>> you're talking about the depth and diversity of art, etc. these folders >>>>> will >>>>> contain. Definitely if you can come up with something more efficient >>>>> we'll >>>>> all be happy but I just don't know if a drastically better method exists >>>>> >>>>> as far as changing file structures go, i would say, maybe we should >>>>> start now on the void map stuff and we can go back and do the cavemap when >>>>> we revisit it... although i don't entirely know what it will entail in the >>>>> back end changes >>>>> >>>>> >>>>> On Thu, Jul 9, 2009 at 2:34 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx>wrote: >>>>> >>>>>> good question on global vars, we have so few of them its hard to tell >>>>>> what they are going to be used for yet. >>>>>> >>>>>> what do you think, do you have some ideas? >>>>>> >>>>>> And sounds good for scripts following the same format and I think >>>>>> peeps are for keeping file types seperated. >>>>>> >>>>>> For implementing the new naming structure we could do it now or wait >>>>>> til after this milestone. >>>>>> >>>>>> I'm all for waiting but its up to you and nick and eric and katie etc >>>>>> if you guys want to migrate now or after the milestone >>>>>> On Thu, Jul 9, 2009 at 11:25 AM, Kent Petersen >>>>>> <kentkmp@xxxxxxxxx>wrote: >>>>>> >>>>>>> I think its a good system. I think scripting should take the same >>>>>>> format. >>>>>>> >>>>>>> How would you like to name global variables? >>>>>>> >>>>>>> What do you want to do about implementing the new naming structure? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 9, 2009 at 11:10 AM, Alan Wolfe <alan.wolfe@xxxxxxxxx>wrote: >>>>>>> >>>>>>>> oh and eric clarified that the first half of the game is broken up >>>>>>>> into chapters, but the second half isnt. >>>>>>>> >>>>>>>> so breaking the files up by location means we have both halfs of the >>>>>>>> game covered by the same system which is nice. >>>>>>>> >>>>>>>> It seems pretty good, are you guys down w/ it too? >>>>>>>> On Thu, Jul 9, 2009 at 11:01 AM, Alan Wolfe <alan.wolfe@xxxxxxxxx >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Eric just brought up the point that maybe we should divide by area >>>>>>>>> instead of chapter. >>>>>>>>> >>>>>>>>> I kinda like it cause it simplifies things. >>>>>>>>> >>>>>>>>> So like for the voidmap we'd have... >>>>>>>>> >>>>>>>>> /Art/Models/TheVoid/VoidMap/ >>>>>>>>> /Art/Models/TheVoid/FortuneTellerTent/ >>>>>>>>> /Art/Models/TheVoid/Temple/ >>>>>>>>> >>>>>>>>> (with subfolders in there as necesary) >>>>>>>>> >>>>>>>>> and then lets say the next area we go to is a big forest that has a >>>>>>>>> bunch of diff areas, if the forest was named like "mystic forest" we >>>>>>>>> could have folders like... >>>>>>>>> >>>>>>>>> /Art/Models/MysticForest/LowerWoods/WoodsA1 >>>>>>>>> /Art/Models/MysticForest/LowerWoods/WoodsA2 >>>>>>>>> /Art/Models/MysticForest/AlpineArea/ >>>>>>>>> etc >>>>>>>>> >>>>>>>>> ::shrug:: hows that sounds instead of the "by chapter" idea? >>>>>>>>> On Thu, Jul 9, 2009 at 9:34 AM, Nick Klotz < >>>>>>>>> roracsenshi@xxxxxxxxx> wrote: >>>>>>>>> >>>>>>>>>> *thinking* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jul 9, 2009 at 10:46 AM, Alan Wolfe <alan.wolfe@xxxxxxxxx >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for the input Chris >>>>>>>>>>> >>>>>>>>>>> "but we would try to not make a lot in case the game can't handle >>>>>>>>>>> it." >>>>>>>>>>> >>>>>>>>>>> there is no problem with the number of files or directories there >>>>>>>>>>> are, in fact i think more is better because that means we have more >>>>>>>>>>> detailed >>>>>>>>>>> organization. >>>>>>>>>>> >>>>>>>>>>> "In addition to that, we could zip or rar multiple textures into >>>>>>>>>>> one file" >>>>>>>>>>> >>>>>>>>>>> The game doesnt constantly scan directories or anything like >>>>>>>>>>> that, and storing the files in zip files would increase the load >>>>>>>>>>> times cause >>>>>>>>>>> the contents of the files have to be unzipped when loading the >>>>>>>>>>> assets. >>>>>>>>>>> >>>>>>>>>>> We could do uncompressed files like wad files. That would just >>>>>>>>>>> hide our assets so people couldn't steal them or alter them as >>>>>>>>>>> easily. >>>>>>>>>>> >>>>>>>>>>> That might be a good thing to do eventually but we need an org >>>>>>>>>>> scheme for the wad files so are back at the same org problem (: >>>>>>>>>>> >>>>>>>>>>> But you are also for keeping the different types of files in diff >>>>>>>>>>> directories, thanks for that input too! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 9, 2009 at 3:05 AM, Chris Riccobono < >>>>>>>>>>> crysalim@xxxxxxxxx> wrote: >>>>>>>>>>> >>>>>>>>>>>> This is a really tough one Alan, I don't envy you for having to >>>>>>>>>>>> tackle it :) >>>>>>>>>>>> >>>>>>>>>>>> I thought hard on it and came up with a few things. A simple >>>>>>>>>>>> content >>>>>>>>>>>> based folder structure could work, so that the game can call >>>>>>>>>>>> files >>>>>>>>>>>> from appropriate folders easily. >>>>>>>>>>>> >>>>>>>>>>>> So it would have folders for each type of file: >>>>>>>>>>>> >>>>>>>>>>>> /models >>>>>>>>>>>> /textures >>>>>>>>>>>> /lua >>>>>>>>>>>> /sound >>>>>>>>>>>> >>>>>>>>>>>> In those folders you could make subfolders based on needs, but >>>>>>>>>>>> we >>>>>>>>>>>> would try to not make a lot in case the game can't handle it. >>>>>>>>>>>> >>>>>>>>>>>> In addition to that, we could zip or rar multiple textures into >>>>>>>>>>>> one >>>>>>>>>>>> file, and have the game read into that file when loading a >>>>>>>>>>>> model. >>>>>>>>>>>> That could help when a lot of files have similar names and don't >>>>>>>>>>>> need >>>>>>>>>>>> to be scanned constantly in a directory. >>>>>>>>>>>> >>>>>>>>>>>> I can't think of more right now, but I agree that we need to >>>>>>>>>>>> find some >>>>>>>>>>>> way to organize things soon. >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 8, 2009 at 8:27 PM, Alan Wolfe<alan.wolfe@xxxxxxxxx> >>>>>>>>>>>> wrote: >>>>>>>>>>>> > Ok so this topic keeps coming up, maybe it's time to figure it >>>>>>>>>>>> out (: >>>>>>>>>>>> > >>>>>>>>>>>> > ============= >>>>>>>>>>>> > Question 1 >>>>>>>>>>>> > ============= >>>>>>>>>>>> > >>>>>>>>>>>> > How do we want to organize files? >>>>>>>>>>>> > >>>>>>>>>>>> > For instance one way, if our game is broken up into chapters >>>>>>>>>>>> (i think it is >>>>>>>>>>>> > but is that right eric?) we could organize by the chapter >>>>>>>>>>>> something first >>>>>>>>>>>> > appears in, as well as location. >>>>>>>>>>>> > >>>>>>>>>>>> > For instance! voidmap and tent art could go in... >>>>>>>>>>>> > >>>>>>>>>>>> > /Art/Models/Chapter 0/Voidmap/ >>>>>>>>>>>> > /Art/Models/Chapter 0/Tent/ >>>>>>>>>>>> > >>>>>>>>>>>> > then, lets say we start working on a town that leads to a >>>>>>>>>>>> forest that has a >>>>>>>>>>>> > lot of different maps (and lets say this is for chapter 2), we >>>>>>>>>>>> could put the >>>>>>>>>>>> > art in folders like... >>>>>>>>>>>> > >>>>>>>>>>>> > /Art/Models/Chapter 2/UberVille/ >>>>>>>>>>>> > /Art/Models/Chapter 2/UberVilleSewersA1/ >>>>>>>>>>>> > /Art/Models/Chapter 2/UberVilleSewersA2/ >>>>>>>>>>>> > /Art/Models/Chapter 2/UberVilleSewersB1/ >>>>>>>>>>>> > /Art/Models/Chapter 2/UberVilleSewersB2/ >>>>>>>>>>>> > /Art/Models/Chapter 2/MysticForestA1/ >>>>>>>>>>>> > /Art/Models/Chapter 2/MysticForestB1/ >>>>>>>>>>>> > /Art/Models/Chapter 2/MysticForestC1/ >>>>>>>>>>>> > /Art/Models/Chapter 2/MysticForestC2/ >>>>>>>>>>>> > >>>>>>>>>>>> > the "A1", "C2" etc is like, grid coordinates of the map >>>>>>>>>>>> (letters are X axis, >>>>>>>>>>>> > numbers are 1 axis?) so that for places with multiple maps, we >>>>>>>>>>>> know where >>>>>>>>>>>> > things are located kind of. It doesnt have to be really >>>>>>>>>>>> strict cause not >>>>>>>>>>>> > everything is square or grid shaped but as long as we do >>>>>>>>>>>> something to give >>>>>>>>>>>> > an idea of location and try to standardize it as much as >>>>>>>>>>>> possible it should >>>>>>>>>>>> > help a lot. >>>>>>>>>>>> > >>>>>>>>>>>> > Ok so you say "well what the heck, you might go to a town in >>>>>>>>>>>> chapter 1 and >>>>>>>>>>>> > then revisit it in chapter 3, where does it go?" so i'm >>>>>>>>>>>> thinking it should >>>>>>>>>>>> > go in the place where it FIRST showed up, so in this case the >>>>>>>>>>>> town would go >>>>>>>>>>>> > in the chapter 1 directory. >>>>>>>>>>>> > >>>>>>>>>>>> > Ok so what about re-usable objects like trees, chairs, tables, >>>>>>>>>>>> treasure >>>>>>>>>>>> > chests etc. >>>>>>>>>>>> > >>>>>>>>>>>> > What if we had a folder like... >>>>>>>>>>>> > >>>>>>>>>>>> > /Art/Models/Misc/ >>>>>>>>>>>> > >>>>>>>>>>>> > and then in there we could have subfolders like "furniture" >>>>>>>>>>>> and "trees" etc. >>>>>>>>>>>> > >>>>>>>>>>>> > That's my rough idea... good? bad? anyone got a diff or better >>>>>>>>>>>> idea? (: >>>>>>>>>>>> > >>>>>>>>>>>> > ============= >>>>>>>>>>>> > Question 2 >>>>>>>>>>>> > ============= >>>>>>>>>>>> > >>>>>>>>>>>> > Right now we have art in one folder, models in a subfolder of >>>>>>>>>>>> the art >>>>>>>>>>>> > folder, and then we have maps, enemies and trap scripts in >>>>>>>>>>>> another folder. >>>>>>>>>>>> > >>>>>>>>>>>> > Do you guys think we should keep files seperated or should we >>>>>>>>>>>> put them all >>>>>>>>>>>> > together? IE just have a "content" directory and scripts will >>>>>>>>>>>> live with >>>>>>>>>>>> > models and textures and sound effects all in the same folders. >>>>>>>>>>>> > >>>>>>>>>>>> > If we have all the files together, on the one hand our content >>>>>>>>>>>> is more >>>>>>>>>>>> > organized cause it's all in the same directory structure, but >>>>>>>>>>>> on the other >>>>>>>>>>>> > hand there will be a lot more files per folder and it might >>>>>>>>>>>> get confusing in >>>>>>>>>>>> > places where there is a lot of art and lots of script etc. >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >