As of writing this, BMUD has:
6 folders,
35 files
The folders are: Core, Commands, Objects, OLC, Other, Services, World.
Core has 'low level' stuff like booting up, bitshifting stuff, defines/constants, and some map-based initialization.
Commands has all of the game commands.
Objects has a file for every object type used frequently (atom.dm, turf.dm, client.dm, datum.dm, room.dm, trace.dm, menu.dm, help.dm, character_template.dm, room_cluster.dm)
OLC contains files for the toolset that developers can use to build/modify the world
Other contains some text manipulation procedures.
Services contains subtypes of the _service object, a datum used in a library that I wrote that loads up services in a package-system sort of way.
World contains defined turfs, and stuff relating to the 'world' map.
However, as I work on BMUD its getting increasingly annoying to have things grouped like this; I figured it might be a nice way to structure things, but its more of a hindrance than anything else atm.
I'm curious about others managing large projects, and how they split up their files. What have you done, what did you find that worked for you, and what didn't?
The problem I'm having is that I find it annoying to go to several different files, to modify a system for something (I just had to edit something in mob.dm, mapping.dm and turf.dm to modify the same general aspect - Perception of surroundings).
| |
So far things seem to work better having them grouped in folders (for me).
For my SR engine that I'm working on from scratch here's what I have so far: 79 code files (not including xml files) 15 folders Folders are: code: where all of the code exists -areas: code for areas. -engine: code specific only to the engine. -lib: libraries I've written for the engine that can be used for other projects. -obj: code for objects. -turfs: code for turfs. -pages: code for my content panel for different pages it uses. data: where all of the data exists -css: css code used in the engine (offline purposes). -gfx: folder containing other folders for graphics (maps, mobs, objs, turfs) -images: html images (for offline purposes) -music: music of course -sfx: sound effects -xml: contains all of the xml for various features within the engine. The engine is pretty big, but it seems very easy to work with since I use the folders as filters to view the code. As far as the engine running, it's pretty good and handles cpu usages very nicely (staying at 1-2%). I'm using the engine for my upcoming RPG Soul Reaper. I started working on the engine sometime in January. | |
With Cerulea, I have everything in one folder. The first file, AACerulea (so it'll show up on top alphabetically) has all the definitions, atom & datum, world and client code.
Then I have one for area variables, one for area verbs, one for area procs... with the mobs and objs I have a lot for verbs and procs. For instance, I have two code files for with mob procs, three for mob "social" verbs, two for mob "useful" verbs, one for mob "skill" verbs, one for mob "combat" verbs, plus two more files for all the procs associated with the mob verbs... and I've only coded about a third of what will be in the game so far... then so on for the objs too. I keep the size of the code files such that I can navigate through one without getting too annoyed. Then I've got special files for procs associated with lists, procs for character generation, procs for saving, procs for the parser, procs for allowing GMs to edit things... Cerulea has no maps or icons (though I'm not sure whether that makes things easier or harder). I like having everything all lined up alphabetically on the left. The game is very complex in terms of how it handles incoming information, but I think in some ways it's simpler to work with. For instance, if I type "say Hello," the parser takes the info and sends it to the say() verb. The say() verb calls usr.Action("say") to see whether I'm using the default Say() proc or a custom one. In the default Say() proc, it checks what language I'm speaking and how good I am at it, and calls Desc1()... the 1 meaning first-person... to give me my message, and evaluates everyone in the room to see how well they understand the language I'm speaking, using Desc2() to give them their message. Both Desc1() and Desc2() call usr.Descmaster() as a final check, so any formatting the user has chosen for their personal display can be inserted. Only with Descmaster() does what I typed into the parser finally get displayed. So it sounds complex... but it makes things a lot easier to change. If I want to alter something in how information is presented to the player... say, if I wanted to turn the text green for some reason... uh, if the character had drunk too much... I could do it in Descmaster() rather than changing every verb. Likewise if I wanted to make an NPC who spoke a magical language everyone could understand, I wouldn't actually have to write a new language into the game, altering all the procs that deal with language... I could just make a custom Say() proc for the NPC. | |
37 dm files in one folder. I, too, sort them by general function (IE main.dm, prompts.dm, social.dm, rooms.dm, parser.dmi, etc.).
Sometimes it can be really annoying to hunt down something, though. I have issues like you describe in perceptions and movement functions, which stretch across several files. | |
My worst problem, I don't organize anything.
| |
I put all my icons in an icon directory with subdirectories for turf, mob, object.
I haven't yet, but plan on putting all my maps in a maps folder, with subdirectories for each map (each map has like 3 files associated with it.)
The player system hasn't been built yet, but I'll probably have a players directory, with subdirectories by letter, and then a directory for each client key (each player will have 3 files associated with them).
And I'm still messing around with xml and haven't been able to get it to work from anywhere other than the root directory, but once I solve that, I'll have a system directory where I'll put all the configuration stuff.