• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Poigahn

How Do You Organize Your Thoughts ? Data Files ?

5 posts in this topic

  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.

0

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
1

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
1

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.

1

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 :)
1

Share this post


Link to post
Share on other sites

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

renderer

    world rendering

        lighting / shadows / ...

        rendering voxel terrain

    3d character models

    texture and shader / material management

    ...

game logic / server-side logic

    entities / AI

    physics

    world stuff

    player stuff

    ...

client-side / input-handling / UI

common

    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, ...).

infrastructure

    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.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0