Handmade Unity

Hello everyone, I'm a High School student going into College, one of their courses is game development using Unity. I was wondering if any of you have any tips to make it not completely insane with OOP. I know Mike Acton works on Unity to make it more DoD-ish, which is nice, but I fear that there might still be nonsense behind it all, are there any tips that y'all can give about this?, general or not.

Edited by Dania Rifki on
DOTS framework is for that. It is a completely different way to structure data in your Unity game. Instead of OOP classes you make small structures. And at the end everything executes in multiple threads & SIMD optimized. Note that it is pretty large investment if you want to structure your game to use DOTS.

But DOTS won't cover all, there's still plenty of regular Unity API to use. If you want to use Unity, then you'll need to use it - there's no way around it. OOP in Unity is much more sane if you are thing about OOP as in Java or in C++. In C# it is much nicer. And it's still OK if you want something ready-to-use, instead of writing your own stuff. Good thing about C# and Unity is that once you want to do something more advanced, Unity offers plenty of choice to do that easier - PInvoke with native code, GPU compute shaders, etc...
My advice would be to not make every thing a game object with a monobehavior derived class. When I first used Unity, everything I created was a C# script created from the Unity ui and I never created classes that weren't derived from monobehavior. But since it's C# you can create regular classes / struct and pass them to functions instead of creating GameObjects everywhere. I don't know if it's a good thing to do in Unity and it has been a few years since I used Unity.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public struct game_state_t {
     public player_t p1, p2;
     public board_t board;
     ... // Only data in here, no functions.
}

public static class game_t {
    
    // Here are game logic functions...
    public static void update( ref game_state_t state ) {
        ...
    }
}

// This is the starting point of the game, it needs to be attached to a game object.
// And it probably needs to persist across level change.
public class main_t : MonoBehaviour {

    game_state_t state;

    void Start( ) {
        state = new game_state_t( );
    }

    void Update( ) {
        game_t.update( ref state );
    }
}

Edited by Simon Anciaux on Reason: typo
I used unity a bit last year. I think the best part of it is learning alot of game engine concepts & using an API you might expect from an engine. Seeing how they do ECS can give you ideas if you made your own engine. Like Simon said, you don't have to create a gameobject for everything, & you can program alot of code seperate from game objects.

I ported my C game code to unity & basically put the whole game in one game object class which was like 3000 lines. The only thing that I needed to change (apart from the syntax) was rendering the quads, which was initing a sprite object.

But I think at the end of day, what do you want to get out of the course. I think doing your own game engine on the side, while learning unity can be a good way to go.

Edited by Oliver Marsh on
OliverMarsh

But I think at the end of day, what do you want to get out of the course. I think doing your own game engine on the side, while learning unity can be a good way to go.


I want to learn how to make games, and how to approach things with a sane mindset.
Yea, Im not sure if I can add much, but working in unity the biggest thing I found was motivation, Im way more motivated to make a game using a handmade engine. I just didn't find it as interesting in unity. And I didn't think it necessarily came from using c# oop but from the ability to nderstand things at a deeper principle, which is more rewarding & interesting.

The other thing that made unity not as rewarding is the unity editions. They go through editions so fast & can feel like your building something on something that's constantly changing, & things can break etc. I think then it feels more like IT support & less creative programming. But again this is my feelings, & everyone has they're own take on things.

As I see it unity is good for learning broad scale game concepts like: the world has a 'camera' that the user sees through, the camera can have an orthographic or perspective projection, there are different spaces like world space, screen space, game objects have some logic the manipulates their properties each frame
, 3d objects have materials etc.

The downsides are: wanting to understand these at a deeper level, wanting finer grained control of things.

Do you see yourself working in a game studio? Or as a indie developer? I think whatever you do, as long as it generates motivation & joy, your going to get good at it & therefore give you the ability to apply for jobs in that area, wether it's engine development or gameplay programming.

Sorry if this is a bit of a ramble. If you posted some of the subjects the course does, that could give a better idea of what the course covers.

Edited by Oliver Marsh on
The course is mainly 2D stuff, I've done some from scratch 2D game programming before so it might help. at the end there might be some 3D?, I think.
It's me again 😝

Probably can't add anymore but there's nothing wrong with learning unity, and alot of what you learn is highly transferable to other engines & game programming. Learning unity is no small feat in itself & in doing so, you're bound to learn how games are made.

I know renaud benbard, programmer on fez & below game uses unity, & likes it & no doubt he's a very good programmer.

One fun thing you could do is choose some gameplay stuff from games you like, like an inventory system from Zelda or particle effects from windwaker etc. & Try and reproduce it. Or make a complete clone of the games.