Organization

W65

Active Member
May 31, 2018
779
840
At least some of you all out there are programmers. What software or other techniques do you currently use to keep your classes organized? I know lots of folks just sit down and throw stuff into code, but I'd like to at least try a little structure for once. Currently I work in Java with the NetBeans IDE, if that helps anyone.

Game design folks are welcome to comment on their organizational strategies, too--less storyboarding and more for setting up game mechanics. I'd like to be a little more neat than "throw ideas into a spreadsheet," but I have no idea what I'm doing.
 
  • Like
Reactions: Marzepain

Elvishious

Afterglow Developer
Game Developer
Mar 9, 2018
149
419
Hey,
So in order to keep my classes organized, I usually make a (I learned UML in class when we were learning OOP with Java and C++) if the system i'm coding is too complex for me to remember all the links between those classes. For that i'm using (the desktop version ofc).
Most of game design workflow leads to the spreadsheet. It's the best way to put you idea fast on something that will not be lost through time (depending on your organization). If what you wrote is too complex or is worth saving to be shared with team members, just use Draw.io
 

Zaon

Newbie
Dec 20, 2017
35
37
I'm not sure about your level of expertise or how exactly your question was meant, so feel free to yell at me if I'm talking to you like you're 5.

I write mostly C# and C++, I haven't worked with Java in years, but a very general guidelines when writing software can be applied to any language.

First, I don't use any tools for organization other than my IDE (Visual Studio and Visual Studio Code, both professionally and for my hobby projects), though I hardly use any of its features either (again, in terms of organization). I just group things into modules/packages/assemblies/whateveryouwannacallit. The most important part is simply to differentiate parts of the code that do a specific task, and limit that code to only do that task. This alone obsoletes most tooling needed to keep code organized.

I'll just give a very general example, as I don't know your particular use-case. Say you want to make a game. Games need controls (let's not talk about VNs for now). Obviously whatever engine you're using is probably providing the core mechanics of that, but you'll still want to map the controls to your world and how your character moves in it. But it has nothing to do with other game logic, it's just an interface between the human and the game. As such I would make a separate module/package/assembly/whatever for it. This will isolate it from your other code which already helps with code organization and teaches you how to keep things that don't belong together separate.

Second, and this will likely garner some hate, don't overuse software patterns. My quality of life increased by an order of magnitude once I learned that software patterns hinder as much as they help and are easily replaced by a few core guidelines. They introduce so much boilerplate, with little to no benefit. They make your code very inflexible and changing a little bit always requires lots of work. They also introduce "code" that does nothing but abstract away implementations that needs not to be abstracted away, for some perceived benefits that rarely apply. Code simply evolves faster than patterns can keep up with.

Third, and this will also not be very popular and already clashes with the previous poster (sorry Elvishious, no offense!), don't use spreadsheets and graphs.

Either you use them before writing your code. That way they lock you into a specific design which, when you get around to finally implementing it, you may I realize doesn't work. That's because theory doesn't always pan out, you tend to not always consider everything. And even if it does pan out, once you introduce a slight change your design may not fit anymore, and you need to redo the graphs.

Or, you do them after you write your code, not to dictate your project, but to document it. That I can see a reason for, especially if you need to communicate it to people external to the project, like if you have a client who needs to consume your API. Those cases are few but they exist. If you only use it to document it to yourself though, it's normally a sign that your code isn't organized very well internally, and instead of writing graphs to document it for you, I always found it better to rethink the design and make the code speak for itself. Ideally few public facing methods that communicate exactly what they're doing, and as little redundancy as possible.

Now, these are all very high-level and generic ideas, but your question was a bit vague :) Generally the more people you get the more different and conflicting advice you'll get about things like UML graphs. The thing that helped me most was experience. After a few years actively doing it you simply get a better feel for what does and doesn't work for you.
 
  • Like
Reactions: Winterfire

Winterfire

Forum Fanatic
Respected User
Game Developer
Sep 27, 2018
4,849
7,130
I use the black box method, each thing does its thing as it should, all organized without using any external help.

Of course, despite having a clean design you might need to edit or add stuff so I always make sure to properly comment everything up so future me won't curse at me.
 

groo.m.com.com

New Member
Nov 15, 2018
1
0
I use the various UML diagrams to describe the basic architecture and design of the app. I've also learned it is a good idea to comment at least the parts of the code that are not overtly simple, as even the code you wrote yourself may look strange after six months 8,) These will also be a great help, if your project grows and more devs start to work on it.
 

W65

Active Member
May 31, 2018
779
840
Thanks for the replies. I'm more or less looking for things to be doing before I bother sitting down to write any actual code. Basically, I'd like to have my logical organization done ahead of time for as much of the basic structure of the classes as I can. I'm used to just making shit up as I go along, but that doesn't work well with my current and very limited time I can spend actually sitting down to code.

Thankfully, I'm not crazy enough to try to keep my amateur code in line with my amateur development diagrams. I was hoping the state of the art had advanced beyond "UML diagrams in flowchart software" but that seems to be where people are still at these days, and that's fine.
 

Winterfire

Forum Fanatic
Respected User
Game Developer
Sep 27, 2018
4,849
7,130
Thanks for the replies. I'm more or less looking for things to be doing before I bother sitting down to write any actual code. Basically, I'd like to have my logical organization done ahead of time for as much of the basic structure of the classes as I can. I'm used to just making shit up as I go along, but that doesn't work well with my current and very limited time I can spend actually sitting down to code.

Thankfully, I'm not crazy enough to try to keep my amateur code in line with my amateur development diagrams. I was hoping the state of the art had advanced beyond "UML diagrams in flowchart software" but that seems to be where people are still at these days, and that's fine.
Wouldn't that work with pseudocode?
 

W65

Active Member
May 31, 2018
779
840
Wouldn't that work with pseudocode?
Yeah, I dunno. That always felt like more of a tool for very limited code-that-does-stuff, but I guess to an extent it'd be what I'd be using in the diagrams. There's a reason I didn't do this stuff for a living, and it wasn't because I didn't like doing it.
 

Winterfire

Forum Fanatic
Respected User
Game Developer
Sep 27, 2018
4,849
7,130
Yeah, I dunno. That always felt like more of a tool for very limited code-that-does-stuff, but I guess to an extent it'd be what I'd be using in the diagrams. There's a reason I didn't do this stuff for a living, and it wasn't because I didn't like doing it.
Depending on what you are doing and granted that this may not be the best/standard way, you should probably aim to write modular code, something that you can move on from project to project with little to no editing... Basically a black box, write it once following the design (w/pseudocode) you want and make it so that it does not have variables strictly tied to the current project you are doing.

For instance, if I wanted to replicate part of Ren'Py dialogue box on Unity, I would write it just once and could move it from project to project without having to edit it as it would require only standard stuff (feed a textasset/array of string to it and the script does the rest).

Pseudocode can be as limited or complex as you want it to be, at the end it is more of a list of things you want to implement and "how" you want to implement them... It is not a must but it allows you to write the final/real code just once rather than going back and changing it with the risk of breaking some stuff.
 

Atmus

New Member
Mar 28, 2018
10
7
In the planning stage all I do is bullet point the game's features so I know what systems I will need to create.

IE:
Combat System
Inventory System
Store UI
AI
Save Games
Achievements
etc...

If you are using an existing game engine they will sometimes have systems in place that will give you a head start of some of your features.


When it comes to writing classes, one thing that always helps me is to write the code that uses the classes you want to create before actually writing the classes themselves. This helps to prevent creating classes with more functionality than you actually need. It also helps in determining how the class looks and how you interact with it.

K.I.S.S: It's a life saver and an acronym. Similarly I heavily favor readability over cleverness in code. Depending the language you are using there is some pretty cool stuff you can do. But if you come back to your code after a short while, and you find yourself asking what does this code do? Then it's probably too complex, poorly named, or not commented. Most of the time well named functions don't really need to be overly commented. However if you are writing math formulas you might want to comment what the math is supposed to do.

This is a bit preachy, but for the love of sanity, don't use single letter variables. It's cryptic as hell when you come back to the code later, and its a nightmare to search your code for usage of single letter variables.


I totally agree with keeping things modular as other have stated. But I have seen some code bases go over board on this. Basically making every subsystem is own plugin/factory that gets registered and treated as if they to be swapped out with a variation or 3rd-party plugin. Unless of course you are creating a game engine that you plan to give to others. Otherwise you and your team are likely going to be the only ones using the code.

For small games, don't be afraid to have a Game class that in a Initialize/Setup function creates all of your subsystems in a static order.


Uhh, I think I started rambling. Anyways hopefully something in there is useful.
 
  • Like
Reactions: Winterfire

Saki_Sliz

Well-Known Member
May 3, 2018
1,403
990
meh, I make some complex systems, sometimes even custom api's, but for the most part my code is all personal stuff so I just have a google doc somewhere describing the mechanics of the code and organization logic. Any more serious projects that require extensive documentation, since I am not a Computer science major, I never have been given a serious job. Maybe a read me document for some custom arduino libraries or unity plugins, but I find I don't really need to worry about it (since I hardly ever return to old projects and code). But that's just because I'm not the best professional person out there :3