[project1dev] Re: File Organization
- From: Alan Wolfe <alan.wolfe@xxxxxxxxx>
- To: project1dev@xxxxxxxxxxxxx
- Date: Fri, 10 Jul 2009 14:30:13 -0700
the variable names LOOK like directories but they arent, it's just that the
"global variables" (ie saved, persistant data of the game) are pulled up by
name, so we needed a way to organize the names so that we dont have a bucnh
of stuff like...
Index
Strength
Strength2
OtherIndex
TreasureChest9opened
Chest9Opened
etc it would be all confusing when we had hundreds of them.
So instead we name the same variables above as (examples):
Minigames/Poker/PlayerIndex
Player/Stats/Strength
Player/Buffs/StrengthBonus
(etc)
(:
as for folders, whatever works for you!
If i have to work in multiple folders i just generally have a window open
for each folder i need to work with but thats just me
On Fri, Jul 10, 2009 at 2:17 PM, Chris Riccobono <crysalim@xxxxxxxxx> wrote:
> As far as I can understand, it looks like the variables will each have
> their own file, and then on top of that, folder structure.
>
> That sounds great for what we're doing so far. I have a question:
> when we have maps within maps, how should we classify that?
>
> For example, the fortune teller tent is linked from voidmap. Should
> that map folder be inside voidmap, or be its own map?
>
> I am also curious about how you guys navigate your folders. Do you
> use win explorer, or do you open each in a new window? When shuffling
> between folders quickly it gets to be tedious, which is why a good
> organization would help, but I am stumped at what to do about it.
>
> 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.
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
>
Other related posts:
