Sorry your browser is not supported!

I thought this might fit well in Game Design Theory, but that seems to be for non-code related discussion in general (I guess it's a toss up as to what this qualifies as), and General Programming is for non-DB discussion I believe. So it'll go here, but apologies if it does have to be moved.

I'm entering a "start from scratch phase" on my Text RPG Engine/game project. As some may have noticed I have been gone as of late, or very inactive. I'm dealing with ongoing dental problems, and it seems I also like to play Lord of The Rings online much more than write code at the moment!

Maybe I am in the minority but sometimes I feel that "starting fresh" on a project you haven't touched in a while, especially in the very-beginning stages, can really get you back into your groove and restore your enthusiasm for whatever work it is you're doing. I guess some people would call it "major refactoring" as you're doing a total rewrite with an major goal in mind..

So that leads to this topic! I am trying to plan ahead a little in terms of project organization of source code and how many files I want to split my project up across, etc.. I know that in our IDE's we do have helper tabs that list all the variable, types, etc we may have in a given project - but I still like to read actual code in a nice and organized manner.

I am a very modular person in my organizational practices, and was thinking of how I might like to break up the project, in terms of subsystems and the like. How modular are you guys? Do you just prefer to keep "section blocks" in a single/couple files? Are you more modular like me and prefer to split things up?

For my Text RPG Engine I've been thinking about what I want from it, and how I want to use it.. My end game vision is certainly nothing short of complex. I want to maintain re-usability so that something as little as a file path change to a different configuration file and resource directory, or something like that, will be all you need to load a different game, complete with its own unique world of vividly described rooms and objects, with different stats and perhaps even completely revamped systems like a different style of combat, or maybe a feature missing that the user wanted to add, or even allowing the user to turn other features off.

However back to the task at hand.. I think/assume that in the programming world, very few things are taught as the "formal" way to do something beyond basic syntax structure and grouping of related code. Everyone has their own unique management and coding style, commenting style/skills, etc.. But what in your minds, are the necessities of a well-organized project Source Tree?

Using my current project as an example.. I have not finalized anything but this is how it might turn out, or something close..

Project\
Project\Game Data\
Project\Main Source File.dba (contains main game loop)
Project\User_Defined_Types.dba (UDT's)
Project\Functions.dba (Contains common functions)
Project\Render.dba (Contains all the display code)
Project\Globals.dba (Global Variables ? )
Project\Parser.dba (Lexer/Parser core to pass input to)

It's a pretty sparse Source Tree for the time being.. But I wonder about the wisdom of keeping global variables and maybe constants too, in separate files so I can easily find something if I need to track an error involving their use. Maybe on the flip side, it would be easier to simply keep your various system components in separate files, but keep all the UDTs and local/gobal variables within marked off sections instead?

The \Data\ directory would obviously hold stuff like the actual game data. The arrays which hold all the rooms, monsters, npc's, item databases and so on.. Right now I've just got a single GUI image stored in there, and part of the rewrite will involve loading that image and pasting it to the screen, and then setting up my text displays over the appropriate elements.


So there it is.. I'm interested to hear how other people structure their projects.

Is there anything I need to keep in mind when organizing, to account for quirks in the compiler and how it may handle stuff differently, based on how spread out it is / what order it is fed in, etc? (I'm thinking like rules similar to functions go at the bottom of a file, etc).. Does the compiler really care that it's being given a function definition here, or a global there, or a UDT from left field?

Ok, here's the issue you and anyone else looking at your code will run into if your project ever gets big and that is searching all over the place in multiple files to edit one class. If you want it to be truly modular then you should spilt everything by classes and as you saw in my thread the class structure:

DBP Source - A Class ¬
Class Structure (Top Down)
- Constants
- UDT's (User Defined Types)
- Declares
- Setup or Initials (Functions used after SYNC ON)
- Function Set For Are Class¬
- > Creator/Operator Functions (ex. Create Object)
- > Update Functions (ex. Update Object)
- > Arguments Functions (ex. If Object Exist)
- Misc (Data Statements or Other Gosubs)

This means everything specific to that class can be found in one place (in one file), it's neatly structured so you know where everything is and if you have to update something, you only need to open that file.

So based on that idea (which is similar to how C++ projects are setup) your project would look something like this:

Project\ ¬
- Game Data\
- Main Source File.dba (contains main game loop)

Then Core Class Stuff ¬
- Core.dba - this will be generic stuff, like maths, timers, input etc... though you can split these into separate files depend on how big your project is. This is stuff that's not specific to a class. But each class requires them and or the main game wouldn't work without them.

Then Class Stuff ¬
- Camera.dba
- Meshes.dba
- Materials.dba
- Sounds.dba
- Shaders.dba
And etc...

I'm not sure if this a "correct" way of doing things or not (I'm entirely self taught, and originally started coding decades ago); but my projects are usually laid out like this...

Projects consist of 2 parts. The first part would be my "Game Template"; which is a series of "modules" which are pretty much the same in all my games; the functions which control the menu/front end stuff, the Timer based movement, screen fading, userinput, media handling etc.

These are all named template_someName.dba.

The second part is the game specific sources; which contains, well, The Game Things like enemy AI, player movement etc. These are all named game_someName.dba, and are usually the only files to be edited.

All my source codes are based on this simple layout.



And the project is linked together in the "main.dba" source file, which starts off by gosubing to all the included sources initModule lable; and then handles the main loop stuff.

I hope that all makes some kind of sense. I've been developing the template files for a couple of years now; and have found it an invaluable way to speed up game dev.