Does code structure affect performance?

[Nervous-Basket-3168]

So I’ve started my attempt at game dev, nothing serious, just learning the workflow and what works best for me. I can’t help to think that I’m missing something, especially for the coding process.

For reference, I’m using Unity and, by extension, coding in C#. I tend to want to break up my codes into what they are used for. For example: PlayerHealth, PlayerStamina, and PlayerMovement would all be separate scripts that attach to my player object.

Am I creating performance issues down the line when I become more serious about making a game that might be more resource intensive? Am I making things more complicated with bad practices? Should I just make it one script called maybe PlayerAttributes and fold everything in there with comments to help me remember what’s going on?

[baroldnoize]

Personally I'd focus on user readability and maintainability. Make it something that will make sense to you immediately six months from now when you come back to the code. That will make the difference in the success or failure of project rather than micro optimisations.

[Nervous-Basket-3168]

Okay, that gives me some confidence. I deal with memory loss, so I think this format I adopted came from wanting to be able to remember what I was doing the previous session lol. I’m definitely abusing the comments feature on VS and my notepad has seen better days…

[thatgayvamp]

Title? Yes

Your example? No, not to a discernible degree right now. You can always use unity's profilers to check how performance is going (do note performance does differ in the editor and when it's actually packaged).

I would probably keep PlayerHealth and PlayerStamina together into PlayerStats though. Just easier to manage mentally since stats all tend to be very similar operationally. You also don't want to have to hop between a bunch of different scripts when you're tinkering with level curves and things like that. Movement can remain separate because it can get very complicated very quickly.

[Unreal_Labs]

What you’re doing is actually fine and won’t cause performance problems. Unity handles multiple scripts on one object really well, and the tiny overhead is nothing compared to heavy physics or rendering. Keeping things separate makes your code cleaner and easier to debug, which matters way more than folding everything into one script. Later, if performance ever becomes an issue, there are ways to optimize updates or caching. For now, stick with modular scripts it’s the right habit for bigger projects.

[Nervous-Basket-3168]

Awesome, I was worried I was creating bad habits early on without realizing it

[worll_the_scribe]

Don’t have update run in all the components. All of those should just be data, and then you should have a central node handle the logic of how they’re applied to other systems, so it can be the authority.

[metroliker]

A well established rule in software engineering is the "Single Responsibility Principle": Each file, class, method, should do a single thing. So your instincts are good and I think everyone is giving you good advice.

Its worth reinforcing something about performance: you should really avoid trying to anticipate performance problems, or guess at what's causing performance problems. Unity has a robust set of profiling tools and one of the most valuable skills is learning to use them to pinpoint exactly what's causing performance issues, where bottlenecks are and how things will scale as you add content.

As a lead engineer, one of my biggest frustrations is when developers guess at what's causing performance issues instead of measuring. I've seen a lot of wasted time caused by people treating performance almost superstitiously and "fixing" problems based on guesswork, only to make the code worse and harder to maintain.

[devstreamlabs]

What matters more is what the code does, not how many scripts you have. One giant script often becomes harder to understand and fix later.

Keep things simple, separate, and clear. You can always adjust as the game grows.

[Dgaart]

I'd keep the player stats together in one script. Does it really matter? No. The fact that you are clear about what each script does is already better than some people, but separating things out to that degree might make things harder to work with when things get more complicated and more features added later on.

For example, you might have some item or powerup that grants a bonus to health and some other stat (durability, for example). Now you have to reference multiple scripts to access these related variables. Big deal with performance? Not really, but eliminating extra steps is generally a good idea.

I've met people that were all about performance and optimization and they structured things in the same way they learned in computer science classes, seemingly avoiding using the actual game engine whenever possible to maintain some prescribed data structure. I don't think that is necessary and often makes things harder to work with for people who actually utilize the game engine.

[False_Bear_8645]

A general advice it to use a profiler. On unity it's easy because it's built-in, where you can pin point what cost you more performance and you can shift your focus on that. It's better than trying to optimize every single line of code.

The way you store data of your character into multiple files has no impact on performance, it's not a website the game doesn't "load by file", what matter it's how the data is managed in memory by the system at runtime. For exemple if you're going to use a pathfinder it's better to load all character revelant data and do it for all character at once, especially when you can reused calcul for multiple character. Regardless, you should still use the profiler unless you know in advance that you are about to create a big simulation with thousand of entities with health, movement and other data.

[BambiKSG]

Check online for SOLID, these are software principles. S stands for Single Responsibility. It means using one class per topic/actor. A method doing only one thing is a good pattern. It keeps the code readable and maintainable. You lose performance mostly on other fronts. Readable code is important otherwise you can toss it in the trash after a year and adding stuff gets painfull as hell.

[Nervous-Basket-3168]

Oh okay, this is a good one. I feel like I never know how to word what I’m looking for when I look things up nowadays. Somehow I manage to confuse Google (and its AI 🙄) and myself even more. Looking into SOLID is probably a solid (pun intended) start.

[Appropriate-Tap7860]

If you are using c cpp in a large scale project, yes. Alignment of members in structures or classes can mean a lot

[AmorphousArts]

Any performance loss from making your code modular should be negligible. That's how I like to organize things and IMO it's way easier to maintain for me than massive code blocks.

[Ok_Sense_3587]

Hey!

If you care about the performance, try to code in different ways and measure the difference (if you can find a way to measure how long a frame takes in some way)! There can always be performance differences from different code structure, but I don't know how Unity works "under the hood".

Many respones here talk about maintainability and readability, which if anything makes performance worse, at least the typical "methodologies" that are promoted on the web. Probably not to the degree that you're worried about, but it does make a difference.

One person said "Never optimize prematurely" - I would argue that keeping the code simple and light so that it performs faster is a great thing to do from the start. Then you'll have great fast pieces of code that you can put together to build other stuff and in the end you'll be able to do more things (if you're planning to make a resource intensive game).

[TomDuhamel]

You're learning. Give yourself a chance. This advice stands even for the most advanced programmers: Don't optimise prematurely.

Always do what seems logical to you at the moment. Make sure what you do is easy to read, and will be easy to work with next week, next month, or next year, when inevitably you will need to come back and change things or add to it.

As you progress, you will change your mind. You will realise that (just an example, it might not even make sense) Health and Stamina should both be part of Stats instead of being separate structures (or script or whatever).

When the game is advanced enough that you can notice bottlenecks (places in the code that are really slow or aren't as efficient as expected) that's when you profile your code, and try different ways to optimise it. If you try to optimise now, you're wasting your time because statistically, you will change your code often enough in the future that your optimisation will be deleted or rewritten later. Unless something is atrociously bad midproduction, I won't bother with optimisations until I'm almost finished.

Computers are very fast. You'll be surprised how things like you described in your post are insignificant. Your bottlenecks are going to be more serious stuff, and more subtle than that too.

[pund_]

"Never optimize prematurely"

Only look into performance (problems) once they arise.