Anyone wanna share some techniques and tips on going through your game source and making it easier to navigate, smaller in size, and a more efficient in structure?
Would you be better off to Have many code or Icon files or only a few?
Maybe if we gather enough Techniques, we could create a Dream Tutor BYONDscape article, just a thought. ;)
ID:153287
 Jul 16 2004, 11:53 am
|
|
Folders. Plain and simple. When you've got a large project with a bunch of differnt .dm files it helps to be able to collapse the differnt sections. Ie, I've got all my AI stuff in a bunch of .dm files. If it's in a folder I can just close that when I'm not working on AI stuff and it's out of the way.
Also I find it helps to re-write sections of code when ever I make any major changes to it's structure (or when I write it for the first time) after I'm done with them. It helps to keep things clean and running smoothly. It's also a good idea to make sure that you understand exactly what you're doing instead of just hacking away until it works. | |
I can appreciate folders as well. (Folders are *incredibly* important for resources, but are also important for code files, especially if those code files contain a lot of information -- splitting them up but retaining similar names lets you find what you're after more easily.)
I never like having folders with a depth of more than 1 directory, however. For instance, this is The Haven Seed's directory structure: alpha.dm base_movement.dm body.dm communication.dm construction.dm debug.dm defines.dm economy.dm features.dm graphics.dm help.dm HUD.dm inventory.dm main.dm map.dm mob.dm movement.dm music.dm occupations.dm parser_integration.dm preferences.dm save.dm six_senses.dm social.dm terrain.dm tracker.dm weather.dm chargen/base_chargen.dm chargen/chargen_advan.dm chargen/chargen_attrib.dm chargen/chargen_build.dm chargen/chargen_equip.dm chargen/chargen_ethos.dm chargen/chargen_gender.dm chargen/chargen_loadchar.dm chargen/chargen_name.dm chargen/chargen_occupation.dm chargen/chargen_points.dm chargen/chargen_resume.dm chargen/chargen_skills.dm dmifonts/CharGenFont.dm dmifonts/CharGenFontSmall.dm effects/base_advantages.dm effects/base_effects.dm effects/base_luck.dm effects/effects_abjuration.dm effects/effects_alteration.dm effects/effects_conjuration.dm effects/effects_divination.dm effects/effects_enchantment.dm effects/effects_evocation.dm effects/effects_illusion.dm effects/effects_necromancy.dm prototypes/language_prototype.dm prototypes/specialfx_prototype.dm skills/base_skills.dm skills/skills_armed.dm skills/skills_business.dm skills/skills_craft.dm skills/skills_creative.dm skills/skills_criminal.dm skills/skills_fauna.dm skills/skills_flora.dm skills/skills_knowledge.dm skills/skills_lore.dm skills/skills_magic.dm skills/skills_physical.dm skills/skills_science.dm skills/skills_survival.dm skills/skills_unarmed.dm | |
I always stick everything in one large .dm file, and split the icons up into several different files. I do spend a bit of time running around in the .dm file, but I'm doing this as a hobby, and I never make anything really worthwhile.
I recently made a random map generator that stuffs up on rivers, a dynamic water flow thingy that is slow and doesn't work properly, and a final fantasy style battle system in which I cannot get the animations to work right. Probably none of these will ever do anything more then capture my interest for a short time. I'm rambling! YAY! | |
Wow! Thats a whole lot of code files spuzzum. ;)
Anyone think of any random facts or theories on ways to decrease source size or ways to structure your code so the compiler can get through the source with more speed or any other random ways to improve code organization? I don't know if there are any proven ways, but if anyone thinks they have a theory that might works, please enlighten us. | |
Troglodyte wrote:
Wow! Thats a whole lot of code files spuzzum. ;) Well, to speed up the compiler, load maps at runtime. Don't have huge .dmp files that the compiler has to deal with. I've found that those can *really* slow it down. | |
Troglodyte wrote:
Wow! Thats a whole lot of code files spuzzum. ;) Some one could probley decrease the .dm file size by creating an app that smushes all the lines of code into its smallest form. | |
That's interesting, that would be very useful, a app that smushs code to most compact form, and can unsmush it back to make changes later. Has anyone experimented this?
| |
Some one could probley decrease the .dm file size by creating an app that smushes all the lines of code into its smallest form. Well, there's a few things about that. 1) Compression of code might reduce file size, but if the 4K Challenge is any indication, doing so would make obscene code that would make even a Philosophiae Doctor of Computer Science blush. 2) The time taken to compress a file would be on the order of several seconds: the time saved on a compile would be on the order of less than a second -- if any. 3) The primary impact that I've seen on compile time is the effort the compiler requires to find relative paths instead of absolute paths. For example, say you have the following line of code: mob/chutzpah Now, if 'chutzpah.dmi' is located in the subfolder \icons\creatures\strange, the compiler has to manually look for chutzpah.dmi on the FILE_DIR index table, find it, and then assign the found resource tag to the compiled binary. By going into Preferences in Dream Maker (Options|Preferences) and unchecking the automatic handling of FILE_DIR, a complex project can save more than 200-300% of its compile time. (The Haven Seed went from 28-second compiles to 8 second compiles. The primary contributor, I'm guessing, was the player savefiles, which are indexed by key and character name. E.g., "saves/spuzzum/terondarynas/char.dat") Then, of course, you have to spend a little more effort by typing out the absolute paths to every icon resource: mob/chutzpah ...but I find it well worth the effort -- especially if you compile after finishing a single proc or a dozen or so lines of code (which all DM programmers should, just to capture any errors they might have made =)). | |
Troglodyte wrote:
explain further, how do you load a map at runtime? Well, Lummox JR's SwapMaps library will be able to help. | |
That does seem like a pain for large projects, but if it cuts down the compile time as much as you've said, that's well worth the extra effort. =P
| |
My usual technique for handling all .dm(i,s,p...ect.) Is to place it under folders:
.dm->> CODE FILES ->> (CATEGORY IT GOES UNDER), .dmi->> ITEMS ->> "", .dmp (I usually only have 1 of these with like 100 z lvls), .dms (I don't usually use these.) About the FILE_DIR. Yes, it does cut down A LOT of time. Thats saved me overloading and freezing my computer. ^_^ | |
Just a thought, is it more efficient to group everything or spread them out. Bleh, I lack a better explaination so I'll just show you.
This is everything grouped. ;) world And now chaos. client/North() They are both the same, but other than one being easier to navigate than the other is there any advantages or disadvantages to using the cleaner looking version? | |
i would say the only advantages are that the organized code is easier to understand and navigate, but the unorganized code is faster to write.. i like to keep it organized because i have to modify my codes a lot hehe.
| |
I do that, too...
And then further, I like to put some large commented-out "signs" at sub-categories, so when scrolling, these large red (I prefer to change the DM comment font color to red) "signs" catch my eye at the proper places... For instance, if I have a file for NPCs, and those NPCs are seperated into something like "QuestNPCs" and "EnemyNPCs", then I put one of these "signs" in the middle to point out where one ends and the other begins... I could just put these subtypes into their own seperate code files, but in some cases, the subtypes are such small sections of code that I don't see the point in "wasting" a new code file just for them... Also, in a lot of cases, I like to have as much generality as possible, by programming the parent type with all of the procs the subtypes will need, even if one of them won't use certain procs, or if one of them will use those procs in a different way... But since they all share the same base type and procs, I like to keep them together with their parent definition... (so if I'm looking at "QuestNPCs" or "EnemyNPCs", I can just look up at the top of the file to see their default "Interaction()" proc... or whatever...) And Crispy is definitely right that a lot of overlapping gray areas arise... I find myself moving chunks of code to other files every now and then because I change my mind about where they really belong...lol | |
Comments are nice, they are great for marking sections of code inside a .dm file. For example, I use:
////////////////// //Admin Controls// ////////////////// That makes it stand out a bit more. They say whitespace is a programmers best friend, but I tend to forget that rule. Always, remember to comment complicated code. It makes it easyer to locate problems and remember why you did something. I came accross a problem the other day and it would have been an easy fix if I would have stated why I did something, but I didn't, so I overlooked it as a required thing to do. | |
I agree with Spuzzum. I find that many files, with each file dedicated to a small portion of the overall whole, is a very efficient way to organize the project. Skimming through 1000+ lines of code for a single function or set of functions is not my idea of a fun debugging session. It's much easier to put all the character handling stuff in the character.dm file or the character/ folder. It makes finding things easier.
| |
Basically just experiment, and eventually you'll come up with a configuration that you like.