Advertisement Jump to content
Sign in to follow this  

How Do You Organize Your Thoughts ? Data Files ?

This topic is 1777 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

  Basically what I would like to know is, when you are laying out your code thoughts, how do you organize your Functions and Procedures in your code.

  Do You list them alphabetically ?  Why ?

  Do You group them together based on what they are doing ?  For Example do you group are your math routines together ? Why

  Do you list them based upon their chronological order of use in your code ?  < I realize in main() that it has to be this way, I am more interested in the Functions and Procedures >

  What about you user input files that you save, such as a "SAVE GAME" file.  How do you organize the output.

  I am curious on your thought process and why you chose to do it they way you do.

Share this post

Link to post
Share on other sites

I'm perhaps a bit old school but I don't intentionally organize functions in any particular way. And (you might have seen this coming) it depends on your coding style and experience.


The general approach, though, is based on keeping the scope of each function reasonable. Don't do too much in any one function. The primary benefit of that is you'll find you can reuse a lot of the code you write.


If I've previously coded a similar task, and I want to code a class for that task, I start with the class declaration, pretty much just listing functions I know I'll need. I may "group" Get/Set functions together, but that's pretty much the start. For the function definitions, I may start at the end - that is, write the code that determines the final product for the task. Then I work my way backward from that, supplying helper functions to get information in the form needed for the final product.


If the task is relatively new to me, most often I start at the end - to determine what's needed to create the "output." The final product for the task may be as simple as "output-matrix = this-matrix times that-matrix." I then figure out how to construct "this-matrix" and how to construct "that-matrix." That process works backwards until I get to the input for the task. That process works (for me) if I have the luxury of defining what inputs are required. If the inputs are fixed, i.e., the task is to use something specific to produce the final product, you should know ahead of time that it's possible to do that.


Being basically lazy, I then compile the code to get all the error messages telling me this or that function is not a member of the class, and I add the declarations.

Edited by Buckeye

Share this post

Link to post
Share on other sites

I have a rough outline of where the code should reasonably go in that area of the codebase in my head. The only flaw I remember with my approach is that I might forget that I cannot call a particular instruction because it was not where I thought it would be.


As for data files, I still use good reasoning. Example assume Link to be a game character:


Link > attackLeft > (attackLeft0.png, attackLeft1.png) Same applies to attackRight, etc. They will all go to the Link folder.


The thing is, no matter how many times you organize your thoughts, code will need to be restructured in the future to accomdate for the new features being added to the program.

Edited by warnexus

Share this post

Link to post
Share on other sites

i use non OO procedural c++ syntax, so what calls what determines the order of appearance in the source code. other than that, i clump related data structures and functions into abstract data types - resulting in something very similar to an object - data structures and the code that operates on them, with a well defined API for accessing the data structures.


savegames are basically a core dump of the entire game state.  so they usually start out by saving all data structures in the order they appear, or most important to least important. then as new features are added, these are appended to the end of the load and save routines.

Share this post

Link to post
Share on other sites
I make a sketch design first, thinking about main subjects that my code will have.
This will be my namespaces, i.e for my engine: IO, audio, renderer, d3drenderer, etc.
Then I just start and follow the consistency within the namespaces, which might change during time if I didn't think of something.

On coding style I have my own guidelines/ principles:
- be const correct when adding stuff
- make class members private as a base, create get...() functions to retrieve values
- in my classes prototypes and implementations non const functions first, followed by the const ones
- every function implementation has 2 commented lines above, one about it's goal and the other one about what it does/ returns
- don't pass around stuff when you can use const ref
- only develop what I need for, no "set...." functions for private members when i don't need them at the moment
- error handling everywhere
- .... Etc

I also have a always 100% updated XLS file as code documentation, one line per function. With columns about what's returned, passed, const yes/no etc. Keeping this updated triggers me to once in a while easily improve my codebase, consistency etc.

On data files and filenames, I name headers of a class the same as the class. For example my application (engine) would be called myengine, then the class d3drenderer would be defined in "myengine_d3drenderer.h" etc. This saves lots of time when trying to find specific things.

And no, I don't have OCD :)

Share this post

Link to post
Share on other sites

in my case, things are organized recursively roughly by category, for example:


    world rendering

        lighting / shadows / ...

        rendering voxel terrain

    3d character models

    texture and shader / material management


game logic / server-side logic

    entities / AI


    world stuff

    player stuff


client-side / input-handling / UI


    world loading/management stuff

    voxel terrain stuff

    console related stuff (processing commands, cvars, ...)

stuff for image-processing and video data / codecs / ...

stuff for audio-processing (sound effects, mixing, ...)

assorted math stuff

    vector and matrix functions

    primitive types (AABB / OBB / ... collision-checking, ...)

    things like polygon clipping and similar (clip triangle by plane, ...).


    virtual file-system

    memory manager / GC

    dynamic type and object facilities

    script VM VM / interpreter




within this, things may be broken up into specific topics, for example, within image and video stuff, there might be files or groups of files dedicated to specific image formats or codecs, as well as specific data representations (stuff related to DXT5 or BC7, for example).


however, there may be some amount of overlap, for example, several formats may share things like the DCT / IDCT transforms, as well as a lot of special case-code, such as YCbCr 4:2:0 (or YCbCrA 4:2:0:4) to DXT5 or BC7 conversion logic.


but, this may be kept separate from the renderer, which may just be like "give me those video frames as BC7", and may not really care how the video-decoder stuff does so (or all the hair that goes into real-time BC7 transcoding, or its quality limitations, ...). likewise, the video-codec logic may not need to care about the specifics of how the texture-manager streams stuff to the GPU (PBOs vs glCompressedTexImage2D calls vs ...), its main goal just being to fill the buffers quickly. likewise, the video-codec may have some stuff otherwise irrelevant to the renderer, such as logic to allow it to be callable from VfW or DShow or plug into VLC, ...



beyond this, generally things are organized by similarity.

for example:

BCn stuff

    DXT5 stuff

        whatever -> DXT5 block-level conversion

            variants based on input format (RGBA, BGRA, YUV420, ...)

            variants based on secondary requirements

                slower but higher quality (such as for texture loading)

                faster but lower quality (such as for video playback)

        DXT5 -> whatever (have DXT5, need RGBA, BGRA, or YUV420 or YUV422, for example)

        image-level functions (convert a whole image, flip image, or convert+flip, ...)


    BC7 stuff

        like above, but all over again for BC7...

    BC6H stuff

        likewise, but for floating-point textures...



so, one might end up with a source file dedicated to various "whatever to DXT5" conversion functions, another for "whatever to BC7 mode 5", ...


elsewhere in the engine, it may be a different set of files dedicated to each specific enemy type (enemy-specific behaviors and animations, ...).


or, in an interpreter, files dedicated to various arithmetic operators or array load/store operations or field get/set operators, ... (because we might need versions of the operators specific to various operand types, ...).


a lot of this is not necessarily because anything is particularly difficult, but mostly because of performance constraints and special cases and variations, which may in turn sometimes result in a lot of hair and bulk.

Share this post

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

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!