[project1dev] Re: File Organization
- From: Alan Wolfe <alan.wolfe@xxxxxxxxx>
- To: project1dev@xxxxxxxxxxxxx
- Date: Fri, 10 Jul 2009 16:17:59 -0700
and what i mean by that if you are wondering is for instance lets say we had
a walk animation for when you were healthy, and another walk animation for
when you were severely injured.
If we make some kind of animation editor (we should!), the animator might
say they want to use the "player/stats/percenthealth" variable to be what
controls the blending of the animations between normal and injured walking.
that way, the more injured you were, the more your walk would look like the
injured walk (:
yes, our game is going to rule :P
On Fri, Jul 10, 2009 at 3:15 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
> nope, it doesn't
>
> it could possibly in the future as the editor gets more advanced but that's
> a ways off if ever.
> On Fri, Jul 10, 2009 at 3:07 PM, Kent Petersen <kentkmp@xxxxxxxxx>wrote:
>
>> As far as variables go, does it really apply to anyone who isn't scripting
>> or coding?
>>
>>
>> On Fri, Jul 10, 2009 at 2:56 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
>>
>>> yeah exactly.
>>>
>>> it's weird that they are going to use the same format but aren't even
>>> files :P
>>>
>>> kinda confusing but hopefully it makes sense now hehe
>>> On Fri, Jul 10, 2009 at 2:54 PM, Chris Riccobono
>>> <crysalim@xxxxxxxxx>wrote:
>>>
>>>> Ah, I see what you mean. So the variables just need the content to be
>>>> defined first, then you know what to name them. As soon as the
>>>> character system is in place you'll know what to call them, then you
>>>> can use that across the board :)
>>>>
>>>> On Fri, Jul 10, 2009 at 2:30 PM, Alan Wolfe<alan.wolfe@xxxxxxxxx>
>>>> wrote:
>>>> > 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: