Jump to content
  • Advertisement
Sign in to follow this  
ApochPiQ

Code organization without the limitations of files

This topic is 1468 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
I don't personally have a problem with the standard arrangement of code living in files, but let's consider other possibilities. Would you be more satisfied if instead of a directory structure (where each file must live in a single directory) we had tags, similarly to GMail messages? That way you could tag a piece of code as both "fireball" and "lightning", and you would see it whether you are browsing for "fireball" things or for "lightning" things.

If you are in a Unix-style file system, you can already achieve some of this by making directories for the different tags and using hard links to place the file in any number of directories.

Share this post


Link to post
Share on other sites
I've pondered the tagging idea a bit, and I think it has potential - but it runs into a tricky issue: how do you go from code you can text-edit to data on disk? Ideally that process preserves the ability to do things like diffs and version control.

Share this post


Link to post
Share on other sites

Now suppose I want to view all code related to casting a fireball spell in this particular game - head to toe, from the UI button that triggers the spell to the game logic that handles it to the graphics code that renders it. Throw in audio effects for good measure.

 

This just doesn't make sense in practice much of the time. First, many bits of code and assets are going to be shared common structures without attachment to one specific effect. For two, things like fireballs are data files and definitions, not code, so the organization imposed by source files is quite irrelevant. Third, content creators are especially bad at organizing files or using such tools which is why you so often seen projects with fireball.png + fireball2.png + fireball_final.png + fireball_final_final.png + fireball_test_final_shipit.png + fireball_test_final_shipit2.png and so on.

 

Some engines do completely roll content management into their game editors, though, and some of these then offer tagging facilities. These are separate from the on-disk file structure. e.g. data/textures/vfx/fireball.png might have a corresponding fireball.json file that includes a UUID, "friendly" name, description, list of tags, and other metadata used by the editor for content browsing and linking. This data isn't available in other programs but you can conceivably include an Explorer plugin or the like that makes consumption and modification of that metadata using stock OS UIs a bit easier.

 

This is all for content still. You really, really shouldn't ever need a source file for a fireball or so on. Your source should be a collection of resuable modules/components and higher-level game primitives can be composed out of those. A fireball would be a particle effect, a DamageOverTime component, a physics collision model, some sound files, materials for burn marks and a component that applies them, etc. No fireball-specific source code would ever be required. Content designers can then be free to create lightning balls or so on without ever bugging a highly-paid engineer or having to wait for new builds to be released to the team.

Share this post


Link to post
Share on other sites
I'm using C# most of the time lately on large projects (about a thousand files, so maybe not THAT large of a project), and I don't really have file navigation problems.

If:
- I have no idea what the thing is called: I ask a teammate (or if nobody remembers, I open up the Object Browser).
- I've seen the code: I exclusively use the IDE's navigation functions (go-to-def, find-all-refs, navigate-by-symbol/file-substring, navigate forward/back). This completely removes the need for me to remember which folder a file is in.

As far as where I actually put new stuff:

- Files: Wherever makes sense. For Unity, I just have to make sure to put it in the correct combination of plugins-or-not, editor-or-not, and potentially in a platform-specific folder if necessary. This is more likely for repository management purposes (submodules, etc) than source code organization.

- Classes: Typically one per file. I like short files. Sometimes I use partial classes to split up extremely large classes across multiple files (I usually only feel like doing this for machine code disassemblers since they are essentially just massive nested switch statements). Edited by Nypyren

Share this post


Link to post
Share on other sites

What I've seen is that projects sometimes are split in multiple projects and eventually become a bigger mess that the original code base.

I've tried different structures, both for C# and C++, and I usually keep one file per class and map directory structure to namespaces. For C++, I keep headers and source files together (handy if you just want to browse some files with a text editor instead of working with the full IDE). If I have related structures/functions/etc that are relatively small, I keep them in the same code unit for brevity. Also, I've come to heavily rely on IDEs' code navigation features, and I can't image coding efficiently without them.

 

I've also noticed that no matter how I start a project, once it grows into something used by customers, it always degrades into exceptions to the rule. Different formatting here, different file/directory structure there, folders with lots of files in them and then folders with just a single file.

 

I wouldn't worry about it, this is what Ctrl+F or Ctrl+Shift+F are for. When I learn a new code base, I don't always rely on the IDE's navigation features, as some names may be used in strings, etc, so finding in all files works better. But it's always a pain.

Share this post


Link to post
Share on other sites

Interesting line of thought Apoch, but is the file structure on the disc really the problem? What if we could afford to write our own IDE to handle all file-related stuff for us?

 

With a custom IDE, the IDE itself could decide how to map the code written into different files on the disc, ideally without intervention from the developer. Then, the IDE could display a custom "view" on the code in whichever way you prefer. To solve the issue of navigating around and tracing paths through code, maybe it would be possible to generate some sort of "code-flow-graph" that maps the connections between methods or code-fragments in the code base. This could be partially automated (like a recursive call to "Go to definition"), but there still has to be a lot of intervention for more obscure connections, starting with virtual methods (MethodX takes an ISomething and calls a virtual method on it, where does this go to?) and harder-to-trace things like event queues in multithreaded applications or network serialization (Cast fireball? Well we are playing an MMORPG and first have to ask the server if we can do this and then a frame later or something the control-path of "casting a fireball" resumes). This would require some sort of meta-information about the code, i guess similar to the tags that Álvaro mentioned. This is potentially error-prone, just like writing comments, because the meta-information has to be kept in sync with the actual code. But if you were to provide that information during creation of a code-segment, maybe this could be simplified a little. Just as regular code is grouped into modules, upon creation of a new code-element (could be a class or a global function or whatever) this particular code-element could be assigned one or more "domains", like "memory allocation", "unit movement" or "casting fireball". A domain would be similar to a namespace or package, but it maps more directly to "use-cases" in the application and is independent of the underlying grouping of code-fragments. 

Then it would be possible to map a code-path for domain "casting fireball" starting from a given point. This could then also be displayed in a single document or in multiple connected documents or whatever is convenient.

The domains would also have the positive side-effect of making dependencies between code-pieces easier to track (though I'm sure this is somehow already possible with some tools). 

Thinking about it, if you get a new code-base from someone who has worked with this IDE and followed its rules, you would open the project and could display a high-level "domain overview" showing all the different elements of the whole code-base. 

The downside would be that version control has to be somehow integrated into the IDE and has to work with the meta-information too. 

 

Could be fun to try out if that would even work or if it is a stupid idea biggrin.png All in all I personally would prefer an approach that lets me work with code without having to deal with how it is stored on the disk instead of creating a new storage scheme smile.png

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!