Is there a catalog of standard conventions floating around out there?

I am just curious to know if there are any particular industry standard ways of doing certain things.

for an example in the game that I’m making I am attaching my particle effects to each individual bullet. When it hits flesh, it spurts red blood. When I hit a wall it makes a puff of dust and sparks. And so on.

Now I know that it’s on the bullet because I made it that way.

but if I were working in a large group who is to say where they would expect that to be?

Would some people expect the effect to be on the targets?

Would some people expect them to be on a separate pool?

and of course this is not explicitly talking about particle effects.

Has anyone sat down and Written a best practices for miscellaneous things like this?

If not, why not?

 

Can your target MOVE? If it can, then impact effect will be attached to the target. Also, target material can determine type of the impact.

 

Someone would decide,document their decision, and communicate it to everyone who needs to know. After that, anyone doing it differently needs a good reason (they can exist) and to document their specific case, otherwise they've done it incorrectly for that project - even if it works.

In reality, though, many projects have people make it up on a case-by-case basis,and just constantly pay the invisible cost of that because they don't know any better.

 

Table of Contents · Game Programming Patterns

you probably already know about this ^, but just in case....

i find stuff like this to be more confusing than enlightening - at least if I start from it. In other words, if I start with academics, it leads to confusion. If I start with practical application, run into problems, then read academics, then I can actually make sense of it.

I think problem with academics is usually the author is more focused on being specifically correct, rather than generally understood, so you end up with non-human friendly language. It is more work to decipher their language than it is to do work on your own and understand problems through experience.

I definitely wouldn't place any heads above your own. Do what makes sense for you, then after you have everything working you can overview what oyu have and see what sort of consistent pattern is emerging naturally, then you can go through and align all the pointy bits until all is following same principle.

With a specific problem like this, you can just jot down all the possibilities, go with whichever is simple/fast to implement it, then when you are at a point of needing to refactor, you can consider if other options might bring the total system into a more coherent whole.

 

yes

 

Early on, definitely. As you gain more experience, though, you'll start to spot areas where thinking multiple steps ahead can save time (i.e. reduce complexity or workload) further down the road.

That is of course not relevant until you can reliably see multiple steps down the road.

 

I thought the particle effect would be on the thing being impacted and not the bullet?

Your approach needs smart bullets the fx on object approach reduces complexity.

Mind you what happens with lots of different objects and lots of projectiles then you need a projectile/object collision fx table/system.

Given how common this is in games why doesn't Unity have a collision/fx table?

 

Yeah, in my own programming journey i am at a point where i have learned one thing, so now when i make a new system or refactor i have this one thing in mind. Turns out this one thing that I have learned is the Observer pattern, but even though I came to understand this idea on my own, still when i read about it it sounds terribly confusing. Makes me question if i really understand the principle. But if I am able to find some practical examples, then I see that they are doing same thing that I was doing.

So that is where I am coming from.

Of course if I started from 0 and went to college courses for comp sci i would probably learn all the jargon and maybe that stuff would make more sense, but neither me nor the OP i think come from that. We are trying to start ffrom step 1,000,000.

 

Even as someone having studied comp. sci. I feel quite similar as you.
It's tricky. Not very sure how to get ones mind to make a really direct connection between the actual code and the abstract principles that are described.

In every case when you want to improve your skills by learning design patterns, it remains crucial to involve examples as well, not only the theory.

 

It's not just about study, it's about experience. I guess that theoretical study could eventually get you to the same point, but the best people have a mix of both.

Anyway, comp sci is about how to make computers do stuff. Fundamentally, it's about working with and transforming information. Most rookies believe that when they get to the point where they can make code reliably do what they want it to do that they're good, they've mastered programming. And from a certain theoretical perspective, that's true!

But from a practical perspective, here's a fundamental truth: every single piece of code you write is for a human being.

As such, when I'm thinking about making new functionality for a bit of software I don't just think about making it work. That's not enough. I also think about stuff such as how content will be made, how things will be tested, and how to design stuff now so that changes later don't break content people already made with it. All of which requires understanding that goes past comp sci, and into human behavior and the processes behind developing, shipping and supporting a game.

All of which is to say: if you want to get good then study is important, but so is building and shipping stuff, and using the opportunity to learn how to take humans into account in your code design.

 

Design Patterns (refactoring.guru)

I just found this recently. Human friendly description of common design patterns and refactoring methods. Very helpful. Also looks like author is from Ukraine, so maybe buy the book too if its helpful.