I'm a beginner to game development and am having frequent trouble with designing my classes and structuring my code. I feel I don't know when to separate logic from a class into a new class.

For example, I'm making a game with a grid. I made a grid class that has properties like number of rows, cols, etc. There is a function to be able to visualize the grid, where it generates the cells, edges, and corners. There is also a handful of functions for manipulating grid data for each [row][col] location.

My questions are: Should the visualization code be a part of the grid class? Should the manipulation of data be a part of the grid class? I just don't know when the right time is to separate things or when I am creating too many layers. Are visualization and data unique enough to warrant separating them from the main class?

That is a very common challenge. It makes sense to let a class that knows details about the Grid class draw the Grid. Whether the Grid class itself should do it, and know some graphics interface, or some other dedicated drawing class (friend of Grid) should, is a design choice.

If the project is small enough, I'd also say that one can benefit from letting some general rendering class draw the grid, but with the likelihood of bloat or an eventual refactor.

Don't feel bad about this sort of challenge - with enough experience you'll make better design choices early. Eventually. Perhaps. Sometimes. Nobody is perfect.

@jakemry I vote for separate class. I've done that recently with a grid I used for generating a maze, pathfinding, and spacial partitioning. My visualization class (a friend of the grid) is really just for debugging.

You should prefer to separate logic and representation. The grid should probably not know how to render itself or how to modify itself. A common software pattern that might help you here is called model-view-controller. I would start by reading about this pattern (I'm sure there are many descriptions on the web) and see if you can map what you learn to your situation.

There are likely to be cases where you use the grid without rendering it (e.g. simulating offscreen places) and more importantly different ways to render the same game state from the grid (e.g. realtime main view in third person 3D, realtime minimap from an overhead perspective, exported high quality video).

Even without such slightly advanced usages, defining and respecting a boundary between game data and rendering will produce a simpler and cleaner design.

It depends what you're trying to accomplish. If you're trying to make the next Unreal Engine 5, then stick to the books. If you're trying to make a game, though, do what works and refine it on the next game.

troutsneeze said:

If you're trying to make a game, though, do what works and refine it on the next game.

I'm afraid this sounds like advice to ignore traffic lights because one is in a hurry, but slow down at the next intersection: if a game project is abandoned because it has become too complicated to make progress, the next project might not exist at all.

Afraid I couldn't disagree more, but there's no sense in arguing. I do have over a dozen (probably 2 dozen) published games since the 1990s to back me up.

troutsneeze said:

I do have over a dozen (probably 2 dozen) published games since the 1990s to back me up.

This is the “For Beginners” forum. You know how to “do what works” with small and rare mistakes and you probably don't even see organizing data structures and rendering as a challenge; but someone “having frequent trouble with designing my classes and structuring my code” needs more actionable and specific advice than spending years to reach your level of experience.

Splitting a complex design (here a self-rendering grid) into two simpler and therefore easier designs (here a grid and a renderer) is a safe general principle to follow for a beginner because minimizing difficulty is more important than minimizing effort or code size.

An expert who can predict and avoid mistakes could be confident enough to combine the two systems in order to write less code, but (another useful general principle for beginners) cutting corners is something that should be attempted prudently after you “stick to the books” and succeed.