I've been sitting here, half-heartedly organizing my current recode, and it makes me think.
How does everybody structure the files in their games?
I'm currently using a mass amount of subdirectories to keep track of the mind-numbing amount of icons I need.. and seventeen DM files, each one containing a single element of the game (quests, player mob stuff, monsters, etc).
--Tarmas.
ID:154338
 Dec 27 2001, 5:52 am
|
|
Tarmas wrote:
I've been sitting here, half-heartedly organizing my current recode, and it makes me think. I use libraries for all discrete chunks of code that are usable by multiple games. According to at least one member of Dantom, I do this to an "insane" degree! The game itself is kept as a library, so that my co-conspirators can easily keep themselves updated with the source code. Images are kept in their own library, as are sounds and songs. That is to make uploads/downloads easier on everyone, since once a game is under way the multimedia libraries might change only every few days, while the main code changes daily. Within a game, I used to use a lot of subfolders but now I don't. Subfolders generally obscure things (and tend to be unnecessary if images and such are in their own library). So now I keep it flat, and do a mixture of what Spuzzum mentions. Some files are object-based -- so if a particular kind of object has a bunch of code related to it, like the trenches in DragonSnot, then there will be a trenches.dm file. In other cases where functionality crosses several objects, I usually keep all that in one file. For example, variables and functions related to supporting hubfiles might cross all sorts of objects, but I put all of it in a hubfiles.dm file so that it's easy to visualize and debug. This evolves all the time, also, though it's gotten pretty settled now. | |
My old method was to put all icons in a /icons subdirectory, sounds in a /soundfx subdirectory, music in a /music or /midi subdirectory, and then leave every other file in the main project directory.
I used to have a system where I would simply use 'mobs.dm', 'objs.dm', 'turfs.dm', and 'areas.dm', and then stick relevant code into those.
However, those files quickly would become unwieldy, after which point I would start making new ones, like 'security.dm', 'magic.dm', etc.
Unfortunately, that is a VERY bad habit to get into. As I tend to lose interest in a project sometimes, I often leave a project fallow, which gives the code time to leave my higher memory and sink into archival. Eventually it leaves the archives too, and I lose the memory entirely. Then, when I come back, I can easily figure out what the localised code does... but when I look at one of the 'mobs.dm' etc. files, I get lost.
The new way I see it, *never* put any code that doesn't serve the same purpose inside the same .dm file, unless the DM file is going to be a complete game/library in a bag.
I tend to organise the code into subfolders as well, now. Normally, I sort it by higher-level processes, like /player and /AI and the like, and then inside those folders I make DM files for every subprocess: 'player/inventory.dm', 'AI/brain.dm', etc.
Icons are reserved to their own /icons subdirectory, as before, except they are also sorted in sub-subdirectories that make them more relevant to the subject at hand -- /icons/monsters, /icons/player, /icons/objects, /icons/overlays, etc.
Sounds aren't sorted, as before, as I generally forget about them once I add them, and they are neither crucial nor numerous.