C# design patterns? reflection? wtf is this stuff?

News & General Discussion
1

okay… so i guess hot shot programmers and stuff throw lingo around i have no idea how to learn these things…

reflection? … idk what that means exactly…
design patterns?
singleton?

stuff like this… whats this stuff? LOL
I guess its methodologies? … doesnt really have anything to do with … required to actually work with???

so… ive learned some C# … variables, data types, collections, methods, events delegates, working with GC, structs/propertys, classes, encapsulation, inheritance, interfaces, LINQ, exception handling, lamba,

alot of material i can find talks about these things…
what about “hot shot programmer lingos” LOL

guess its entirely unnecessary for a single guy to know? its just team/ working for someone crap? LOL
(dont really want to work programming seems boring as F … i mean, working on some1 elses crap? ew…)

my background is modding and tinkering, read some ebooks, youtube tutorials, edx.org class on C#,
split my time learning C#, unity, blender, substance, lmms, guess im not proficient in any one area, have enough knowledge that i could be making a pretty sweet 3d game now, but want to become proficient in all.
… made a ton of simple projects to learn basics of things…

i see this site has a $80 book or whatever it is about design patterns C# Abstract Factory Design Pattern … but if its something only really needed for a job, i dont care about it LOL (altho yea)

okay… like here: Covariance and Contravariance (C# and Visual Basic) | Microsoft Learn
“Reflection” is among the list to the left side…
is this list ‘complete’ … like is that ALL the… “reflection lingo type things” to know?

lol… guess looking for general advice or something? :slight_smile:

2

I guess its Software Engineer type stuff? … lol
lol idk when you go to learn C# … they never talk about these things… or … i suppose the majority of material is about the basics… well, i want to know the next level…

okay a book on amazon “C# in depth” … doesnt say anything about these things ^ (judging by table of contents)

various code people share, they use these lingos.

3

These are more advanced design concepts. Keep in mind that the C# we use in Unity is not technically a complete application. Design patterns kind of make more sense when you coding the entire application as various classes. We are basically using these classes to extend objects most of the time.

Singletons are something you’ll see done in Unity. The basic idea is that you only want this class to instantiate once. An example might be a GameState or MusicManager class (or both). For example, these things stay loaded and do not get reinitialized between levels.

Encapsulation, and Single Purpose Design are some other popular patterns that you’ll see in game programming. Encapsulation refers to “hiding” the properties/variables of a class from the other classes. A very simple version of this is basically you should never manipulate variables in one class from another. Instead you provide a function for other classes to call that manipulates the data with whatever arguments you might want to pass in. Single Design Principle is the idea that each class should do one thing. For example, a ParallaxCamera class really shouldn’t be handling game state or player score.

To be honest, a lot of this stuff is something you’ll probably do on your own through trial and error. It matters a lot more on a team where there has to be a standard. You get enough people with their own ideas on how to code on a project and it can hacky and ugly quick.

6 Likes
4

thanks!
yeah i was thinking too maybe i could extend my learning to Visual Studio, and universal apps for Windows or something,

but yeah thanks for helping clarify, so it is team… standardization concepts, for the most part.
heheh i was all sorts of confused when i wrote the OP …

yeah i figured/ have read alot of it is stuff you end up using alot just naturally… but i suppose ill have to go and learn the lingos

5

The jargon is good to learn for design patterns…if only because if makes it easier to talk about things. E.g. instead of “making a non-static class with inheritance an essentially static class” you say “singleton”.

Reflection is mostly a .Net/Mono thing. A very useful thing though. It lets you get details about classes, variables and method signatures at runtime. Things like “this method is named X, and was decorated with these attributes, which were populated with these other values”. It’s also kind of a pain to get started with. I’m also not very good at explaining it without code (and typing code on my phone is…unpleasant).

1 Like
6

Singletons probably get used more in games than anything else, I can understand them being hard to learn because an out of context search for them will give you plenty of negative feedback for them haha. Ok, singletons…

You know how static variables work, yes? If a variable is static, it’s available to anything via Classname.StaticVariable. A singleton is a static variable of the class.

public static Game singleton = this;

That is usually how mine are setup. A singleton of my game manager. Then any script anywhere can access the public variables of Game, via Game.singleton.publicVariable. Want to find enemies without using GameObject.Find? Declare a public list of enemies in Game. Then on your enemy start function, you can do Game.singleton.enemies.add(self); and when your player needs to access them your player can call Game.singleton.enemies and iterate through the collection.

Reflection I don’t really use myself since there as less performance heavy workarounds to achieve the same effect. Of course there are cases where something can only be achieved with reflection, like dynamically loading assemblies. I don’t know what reflection is and I don’t know what “dynamically loading assemblies” means but I know those words together are accurate. If you’re really curious about it look into dynamically loading assemblies with reflection :stuck_out_tongue:

Design patterns really goes out the window with games. Or rather, there are more options. Brief example : a singleton is a common practice. Even UNET has a singleton (even called singleton) for its network manager.

check it out in the docs, NetworkManager.singleton :smile:

4 Likes
7

Use only the stuff you need to keep your code as simple as possible, clean but simple, despite software engineering aficionados sometimes rolling their eyes at such things. There is value in the stuff for certain but it is also easy to get so caught up in it you end up over-engineering everything. That makes everything more convoluted more difficult to update. The patterns are to make software applications easier to maintain, remove spaghetti code structure and so forth not to complicate things just for the heck of it.

1 Like
8

Reflection is a powerful and useful set of tools for manipulating code from code. I have a set of attributes that I use to avoid having to manually wire stuff up in editor.

[FromParent]
protected UIPanel Panel;

[FromGameObject]
protected UILabel Label;

All these really translate to are GetComponent calls, but marking it on the field like this is really clear. Reflection let’s me write code that scans the class for these tags, get the fields or properties they’re connected to and populate them.

I don’t really use these tags anymore, and I’m not even sure I think they’re good practice at this point. But they were damn convenient and very clear.

Reflection can do a crap ton of stuff that isn’t normally possible.

But it’s also not really something you generally want to do in game dev, unless you’re building out some tools that are on the more ambitious side.

1 Like
9

The reason for this is, reflection is slow. Pretty much, reflection means that your assembly is reading from itself to get information that it couldn’t normally get in ‘normal’ runtime.

Design patterns are good things to know; they’re recipes that solve common problems. They’re not always useful, though.

Singletons are a design pattern that are reviled by some because they introduce global state - as a result, this is considered an anti-pattern to object-oriented programming, where things are objectified to avoid global state. Global state is considered bad because it complicates maintenance. If you need a set of functions that exist “out there”, you might consider writing a static class.

Now, Singletons are still good to know for other reasons. I have a Unity Code Pattern™ of my own that I call “Manager Object.” Pretty much it’s a game object that persists across scenes, and has code to self-destruct if an object of the same type already exists. It’s global to the game, but doesn’t break the code’s compartmentalization. This is because, the way Unity works, even if you create a static class when scenes change the state gets dumped…including that static class that exists “out there.” Only an object with “DontDestroyOnLoad” A) continues existing, and B) keeps its state, which is what I want.

You can see this in action in my PersistentSingularObject behavior.

4 Likes
10

@AndrewGrayGames I have had my fair share of concurrency issues from singletons (yaay for classes that are great-grandchildren of a singleton base…so you have no idea that you have a static class >.<). But an instance that they are useful in, like you say, is that you can inherit from them (you can’t with static classes). Granted, this can lead to the aforementioned skull/wall destroying issues.

1 Like
11

The potential downside being that this all happens at runtime, right? So if done wrong there could be performance hangs?

1 Like
12

Considering Unity is built on reflection magic, you’ve probably experienced these issues before.

1 Like
13

That’s true. I’ve found few times where one would want to inherit from a Singleton, but it is possible, so I find it entirely believable, and inevitable that someone has, or will. Further, it was or will be the best possible solution for some problem, downsides notwithstanding.

I like my component implementation more, because it’s at least understandable. You know that the component is set up to persist across scenes. It also doesn’t interact with anything else directly; it merely composes the game object, with the other things that the Persistent Object needs to do its job.

1 Like
14

This…

1 Like
15

It’s the same concepts that programmers have used before but repackaged. So essentially it’s new lingo designed to make older developers feel inadequate. A bit like slang. Just buy a book on C#.

16

Fo rizz’, G-drizz. Now shake a leg and go ham on that biscuit.

2 Likes
17

Yep, and when you use unity you are using a pattern without even knowing it. It’s called, surprisingly enough, composition or component design. Most people don’t realize it because they are dragging and dropping components.

4 Likes
18

And this answer is what makes the OP’s questions worth it. Design patterns are something of a rabbit hole that, once explored, leads deeper, but also leads to useful insights. Components are a great one to know.

In fact…

There’s a great book that you can read for free, called Game Programming Patterns. I bought a hardcopy from Barnes and Noble, but it was worth it - while the author of this work talks about certain ‘Gang of Four’ patterns including components, he goes into some patterns that are specific to Games work. The OP should read that, it will be of great use.

3 Likes
19

Most assuredly. If I could refactor the codebase at work to use composition in the places it makes sense, I’d do it in less than a heartbeat.

I’d also refactor out a lot of the singleton use…I’m guessing it was a case of some architect before my time that had just discovered the singleton pattern and went “yaaay! Erything must be singelton!!1!!” -.-

1 Like
20

See what I mean? Inadequate linguistics.