As a beginner, how can I write structured, scalable code ?

Unity Engine
1

I have been programming since last 4 year (Studying Computer Engineering ) and ‘OK’ (not very good) with it.

form my understanding there are two major parts in unity’s C# programming

  1. the Unityengine programming : things like GameObjects, RigidBody etc etc
  2. the C# programming : things like Delegates, namescapes, etc etc.

I am able to write simple game( spaghetti code) with some help and reference but do not have any experience with C# .

So my problem is , how can i write a scalable, modular code in unity C# so that i can make changes quickly.

which things are i need to learn like StrangeIoC ( tried but can understand it ) or something like very advanced C# (delegates, namespaces etc )

when i make game i tend to repeat my sourcecode again and again, i dont have any centralised control over my modules and find myself facing difficulties after game is half done

The problems i face are like TO MAKE A GAME MANAGER, MANAGE SOUND, MAKE A SETTING PAGE, SAVE GAME INFORMATION etc etc and to implement these i end up writing another script which basically is a redundant…

I HOPE you guys understand problems i am facing :frowning: .

2

something like very advanced C# (delegates, namespaces etc )

This made me laugh lol.
Learn about delegates, events, and inheritance. I think those are very helpful.

1 Like
3

C# is an object orientated language. There’s various ways to work with and implement object orientation (Components, Inheritance, Interfaces, Polymorphism), all of which you should do some research on if you haven’t already. The Unity tutorial section gives quick and easy to understand examples of implementing object orientated code, take a look at the intermediate section

Basically each class should handle a single task. For example, if you have a class set up for managing sound, then any other class that might need to produce sound shouldn’t actually produce the sound itself, rather it’ll create an instance of or access your sounds class and call members of that sounds class. Some managers that don’t need to be instanced multiple times could even go the singleton route

Somebody here could explain better then me, but for the most part it’s all been thoroughly explained many times before on this forum and articles across the web. Look into object orientation. If you’re not making mistakes or producing errors, you’re probably not learning. So don’t be afraid to make mistakes, and if you have to spend time debugging an error it’s time well spent.

1 Like
4

thanks :smile:
well this is advance for me :stuck_out_tongue:

5

Yess this is exactly kind of thing i am trying to do with my programming . to centralize everything so that i do not have to change my code at more than one place.
I will definitely take a look into that
thanks

I did not get this part. are you referring to singletons ?

6

I would classify inheritence slightly below intermediate level programming. It can be sort of ignored in the Unity Component Style but still has many uses.

Event’s and delegates are intermediate level stuff as they are more advanced functions (sorry to actual programmers if I over simplifed that :smile:). When you start getting Events with EventArgs they become really powerful (I have not learnt these yet).

Namespaces shouldn’t be that important right now unless you are building reuseable collections of code across multiple projects. All a namespace is basically a collection of code (scripts, classes etc.) that belong together that you can call on. By default it assumes you are using the code in the current namespace. However if you made a class the same name as a system class (for example a math class) you can specify which class you want to use either System.Math or YourNamespace.Math.

Advanced stuff I’d call the polymorphism stuff mentioned earlier. Though it is linked to inheritence, basic inheritence is easy to understand by comparison. The Unity ref tutorials listed earlier lists them as intermediate so I’m wondering what they classify as hard/advanced.

A rough guide to the “Managers style” (if you don’t know). You have a GameObject that you attach the different manager scripts (Sound manager, GameManager, etc.). you can then in the other scripts add:

    public GameManager Gm;

In the inspector drag the GameManager gameObject into the variable in the inspector,
or if you want to link them in code dynamically (like if you are spawning an object in realtime):

    public GameManager Gm;
    void Start()
    {
        Gm= FindObjectOfType<GameManager>();      
    }

GameManager is the name of the Script or class you want to reference on the gameObject. You can replace it or add more like “public AudioManager Am;”.

More generic advice for modular code. Sorry if you already know this stuff.
Basically there is a point where you need to look at planning. Some people like rapid prototyping and then refining the code while others plan from the beginning and build off that.

The stuff about changing things once in a localised area is important. There are multiple things to consider for modular code. One avoid hard coding. Even if you know that a value will always be the same, make it a constant variable. You can also make a static variable that should only exist once and be referenced much easier then normal variables.

Try to make functions more vague/generic (for lack of a better word). Instead of a making seperate shoot functions make one that you pass the weapon, speed and the like.

1 Like
7

First up ask for a refund on your engineering degree, you should have covered this in this first few months of software engineering.

The best way to learn to write extendible code is to write code, then try and extend it. You’ll quickly learn what is extendible, and what is not.

Some general hints

  • Keep it modular. Each script should do just one thing.
  • Keep it short. Anything over a couple hundred lines should be split into multiple scripts. Any method that gets over a couple dozen lines should be split
  • Don’t repeat yourself. Ever. Any time you write the same code twice it should be it’s own method.

These are not hard and fast rules, once you have figured out why they are there then you can ignore them. But follow them until they make sense.

Just checked out strangeIoc. Don’t bigger with dependency injection for now. While dependency injection is a powerful technique for modular code, it’s not the only technique, or even a standard technique for Unity. Learn the basic C# stuff first, like events, delegates, interfaces, inheritance. Learn he basics of reflection as well.

Trying to use a dependency injection framework without this knowledge is like trying to fly a 747 before you can drive a car. While possible, it seldom makes sense to do so.

1 Like