Sign up for the Level 2 Game Dev Newsletter: eepurl.com/gGb8eP

I'm so guilty of trying to design every single thing I write as if I'm going to eventually sell it as an asset. I kinda figured on an instinctual level that this was a flawed approach, but it's good to hear a pro tell me that yeah, I really ought to try to chill and let the code in my personal projects be as specific as it needs to be. Great video as always! It's easy to get carried away and put everything in a single Player class, but when you remind yourself that you can put as many components as you need to on a GameObject, it really opens up a lot of breathing room.

@ThousandAnt

2 жыл бұрын

I think this is a pretty common "perfectionist" type approach where as developers we want to make the most perfect, elegant extensible system and forget that the goal is to get THIS game out the door.

@joao13soares

2 жыл бұрын

Relatable

@clekroken

2 жыл бұрын

This sounds very familiar :p

@callmedeno

2 жыл бұрын

@@ThousandAnt I figure it's a latent maths instinct in developers / engineer types. Most developers I knew never really bothered much with Maths but then they go and try to reduce everything to the most elegant / general solution :P I know they would love it if they were introduced to it through proper education (not the shit way we present in school) because it's the exact same experience just often without the tedium of writing everything explicitly. For someone who is a dev I think not studying maths is like not exploring one of your senses, it's like not appreciating visual art, what music does to our ears, or not testing good food. The desire for maths is always there but instead gets expressed as overengineering. Which is fine for study, but will kill every project because there is no bottom to the questions they're really asking :P

This is a fantastic, simple way to organize your code. I'll be using this!

Another reason to use this approach is reusability. If your systems work in isolation, there's a good chance they'll be able to give you a head start in future projects. I have a custom Projectile Launcher system that I exported into a unity package, so that I can easily drop it into any new project that requires launched projectiles. :)

@ligofleyens9131

2 жыл бұрын

I highly recommend you to start making git repositories for them, as you can both import them into your project easily as any other Store Package via the Import Git utility, or explore and download only the files or fork the whole repository for new functions and purposes.

I don't think people discover how very high quality these contents are, I would prefer using an interface to establish contracts between systems, makes the code more fluid and decouple on a whole new level but I'm glad someone talked about this on KZread.

My "systems' designed from "feature sliced" mindset. Same idea different words. Good video

I do this a lot already and take advantage of opportunities to make some general purpose components that can be used in multiple systems. After a while on a project, I've made enough components that I don't need to actually code anymore to add new content or mechanics, until I need to do something very specific or make a component have additional features like using a layermask to optionally filter collisions.

"Plan. Get it working. Then make it good." Certainly, as you get more experienced, you can write your code to be scalable and flexible right off the bat, but if you're still learning, I think the best thing you can do is write down what you want your code to do. Pre-plan it such that you have a list of conditions it needs to satisfy at minimum. Then get the code working as quickly as possible. When that's done, then worry about clean up/optimization. This is useful for multiple reasons: - You waste less time because you took the time to plan beforehand, meaning your time will be better focused during implementation. - You can get quick feedback on your system(s), allowing you to make notes about what works and what doesn't about your gameplay. - You can return to your code and refactor it with a purpose in mind, rather than optimizing for cases that your game may never trigger.

@Nors2Ka

2 жыл бұрын

Planning is the very last thing you should do as a beginner. Get out with this terrible advice.

@ElboxD

2 жыл бұрын

I'd add to this that you'd be actually finishing projects. Can't remember how many times I wasted time thinking about the system instead of writing the code and improving upon it.

As a non-professional coder, I had to learn concept like this the hard way, with the help of software-dev friends, aswell as youtube videos like this one, or uncle Bob's conferences. Now, at my humble level, I come to the conclusion that, I get the best results when I write code to make it work on day 1 (ofc I try to structure it day 1). But I come back on it the next day, and refactor it seriously, to get a fresh perspective and to clarify my code. So i don't have to bang my head on a wall when I have to read that code in 6 months.

This new Relaunch of the Channel is Awesome !

I thought one day "why should I re-create something I've already wrote?" It's definitely the approach I have now and have had for some time now. And it has been enhanced by using Unity Package Manager (UPM), now most of my code is split into packages that I can add to a project and keeping project-specific code in the /Assets folder of a project. When I started using UPM it was a mess, I was trying to learn how ASMDEF files worked too (I had no idea) while also trying to modularize my code based on what it does. It's definitely something that you'll learn to balance as you say in the video - getting it to work and generalize the code. Part of the fun though! Great video as always, cheers!

I was once contracted to port a game where the player class had over 65k lines of code... it was also written in UNITYscript, which meant that every time I would change code it needed to convert from UnityScript -> JavaScript -> C# , I'd have to wait literally mins every time I wanted to access the editor again. There might have been an additional conversion from C# -> C++ there but I dont recall if that happens when swapping to the editor or only whenever I'd have to make a console build (which took almost an hour). I still get flashbacks from that project.

Trying to implement when I can, finding the right level of abstraction in a program is art as much as it is science

Your camera looks better than my real life vision

Responding to your ad around 2:30, I actually would prefer content that will help bridge the gap between studying a language from a book or Codecademy or the like to actually being able to construct a workable game program. Because I've done a lot of the former, and never really been able to figure out how, or find resources on how to get to the latter.

How do you not have more subs? The production quality here is phenomenal! /edit Also, nice beard, bro!

The important thing when introducing abstraction is to ask yourself "which problems do I need to solve with it", not "which problems could I solve with it, in case I need it sometime in the future". Coding against clean interfaces and building reusable components is super important, but you should never spend more than 25-33% of the time in designing your systems. You never make the correct assumptions until you build and use it anyways.The other big danger with abstractions is that you make it harder to follow the control flow. You end up writing a lot of pieces that work, but don't fit together if you don't understand why and then something is called at all the time.

New viewer here. I liked this! I enjoy seeing you impart good programming habits. People start self teaching and getting things working but don't necessarily know how best to work in teams, so these bite sized lessons are invaluable.

This is so important for sanity on long projects.

When thinking about where my strong suits are I would always say, "I am good at breaking down problems into little pieces" but after watching this video I think it's more along the lines of I think of things as systems. That isn't to say that breaking down problems and thinking in systems are the same thing, rather I've always been good at isolating the core functionality of a feature and building it in a way where it can be used in multiple contexts. Sometimes I think I take it too far XD "Thinking in systems" is a better way of explaining this type of thought process! So thanks for the extra wrinkle!

My problem with this kind of system thinking or thinking about "doing it correct" can have a paralyzing effect. Games have many things that differentiate them from programming tools for example, and sometimes a little bit of that "dirty" code can really be the most efficient solution. Heck, trying to fit something under one paradigm that is as complex as a game is impossible. PS. I have to say that your energy seems much more sincere in these new vids. Good job!

@lpnp9477

2 жыл бұрын

Definitely true. Generified solutions are not always optimized for speed and that's one thing you must account for in games programming. Players will appreciate a high frame rate but not that you made an interaction class that works with any game object. Less error prone is more important than frame rate, but high frame rate is more important than ease of scalability in my opinion.

@pixboi

2 жыл бұрын

@@lpnp9477 I have some kind of genericness/performance OCD but nowadays I lean mostly to my own ergonomics of having to write code.

@lpnp9477

2 жыл бұрын

@@pixboi a lot of people have that compulsion, myself included. You are not alone haha Sometimes you gotta stop yourself and be like, will I realistically reuse this? Could going too generic affect performance? Then it's the uphill battle of fighting the urge to overpolish

@THEspindoctor84

2 жыл бұрын

agreed! It's easy to get paralyzed by thinking about all possible future changes in you're game, and having to maybe account for them in the future.

@halivudestevez2

11 ай бұрын

try to focus on one or very few thing, do not write more, then needed NOW. Go step by step.

Thank you Charles for the video, you make valuable content about very important topics. I'm new to Unity but work as a full-time, full-stack software engineer since 26 years and in my experience, it is exactly as you said, it is possible (and important) to find a way between quickly building features (that managers often call "productivity") and keeping the code clean and manageable. It is good when the developer can think in systems from the beginning of the project, but if it is not the case, re-thinking / refactoring is worth the effort. Keep up the good work!

Great video Charles and I love this approach. I definitely think breaking things apart this way makes it easier to set "guard rails" for yourself and avoid making reckless couplings and connections between systems that don't need it. Having clean structure helps keep future-you honest when you're trying to put stuff together. Looking forward to digging into these architectural topics more in the future!

Probably the best description for a "systems approach" that I've heard so far! Keep up the good work Charles. ^^

I love these kinds of videos. Thanks! I've been making my code in a very similar way for a while now. I did saw some improvements here that I will add though. When i get started organizing my code like this, I feel like I could just keep on doing it for ages without actually making a game.

I tried my best to make my code like that But also very generalized. Seeing you doing it really gives me a way better perception on how start making some systems i never tried because of análisis parálisis.

This helped me so much. Thank you! Love your videos♥

I always try use a systems approach but yeah sometimes you just need it to work so you don't go insane but coming back to refactor the code before it gets to out of hand I think is one of the keys. Love this content keep it coming.

I'm slowly working this into my dev flow.

Your videos brighten up my weeks. I've switched completely to DOTS, and I'd love more videos on DOTS and systems design!

@Bankoru

2 жыл бұрын

I still can't go full DOTS given how little attention Unity has put into it.

@DonAlonzo

2 жыл бұрын

@@Bankoru oh they're definitely putting their hearts to it! Right now I'd assume it's too much of breaking changes to let the community test the latest version. That's probably a good sign, they're redesigning the entire engine to accommodate DOTS. It's too powerful of a technology to back down from.

Nice video! Personally I've always coded with this approach. The level of modularity it provides is crucial in the long term and I just love coding with this mindset! I've sometimes fallen in the trap of over modularizing a system, and it had slowed me more than anything. However by learning more and observing other projects structures, the balance between modularity and implementation for my game specifically is a really nice feeling and has helped me improve the fastest in my progress.

Helpful topic. Thanks!

Great video!! Thanks for sharing. I normally work with an interface implementing an OnInteract function for this. Which eventually allows you to do the same, but a bit more generic when it comes to fitting new interactables in the game.

Nice video! I have been doing this for a while now, however I did not know what it was called and often don't explicitly think about what it means - so it's good to explicitly define boundaries and have clear separation and independence from other systems where it is reasonable. I could be more mindful about that from now on. For a class like the Interactable, I usually start with an interface (IInteractable) and let the Interactor look for that, so that I don't have to depend on inheritance of one specific base class (leaving the MonoBehaviour class aside). If it is reasonable, I can additionally still define an (abstract) base class with shared behaviour or member variables that I expect all or most interactables to have. Another possible method for an interactable I have is to return a name or prompt. So if the player is in reach for a non-automatic interaction, there is a text showing up that says what an interaction would do (not relevant to what the video wants to demonstrate of course, I just thought it would be a neat idea).

Love this topic! I personally try my best to take this approach (even though i did not know there was a term for it). I am also guilty of sometimes putting everything in a single script to get it working and once its working i tend to go back to refactor it in multiple scripts or classes.

@ThousandAnt

2 жыл бұрын

I think putting it all in a megascript to start is actually fine, don't overthink structure until you know that you're making what's needed. Just make sure you're disciplined to go back and clean up, and not just say "it works! moving on!" ;)

Nice video. I've been working a lot with Scriptable Objects as an event system to better support the communication between all those systems. Systems are working together but are not directly linked. Each system does not know, nor need to know, about any other system. (For example, one application is to completely separate the UI or even the sound effects from what triggers it)

I had developed a game two years ago, which is a maintenance nightmare due to its size(hundreds of characters and their unique skills, with freaking if/else statements). Touching that game gave me terrible memories. Then I asked myself if this was the right way to code? I started learning refactoring by accident because "Code Smell" is an interesting word(Yeah, weird reason but true), and slowly gained knowledge about "anti-patterns" along the way. Now I discard shitty codes as soon as I learned a new design pattern or spot some potential repetitive stuff scattered around my classes, and it feels good to keep everything tidy, plus reusability.

Great video!

This is amazing !!!

Absolutely agree 👍 nice explained

Systems Approach or not, I think this technics creates a simple, meaningful and easy to understand API layer for others or your future self to work with. This will ensure future scalability and make it easier to fix bugs.

You are AMAZING

very nice!

thank for the nice video!

These are great videos, thanks for the content. Do you know any book that tackle all these topics? Thanks again

Very nice, you could also, for example, plug this Interactor script on NPCs and suddenly they are also able to collect items now. In this way, game entities behavior emerges from many single responsibility classes working independent.

@ThousandAnt

2 жыл бұрын

This is what I really like about this approach, you're now creating the game world in a more systemic, modular way and there can be some fun, surprising emergent behavior from that in a game design sense.

Great video although i expected some system thinking concepts according to the title :D

Thanks, very useful, could you give more video about how to use interface override and so on, even I know what they are, but I am not sure how to use them, thanks

inventory references all over the place is its own form of maintenance hell…

I was already doing this system approach because I use a lot of assets and they have a lots of scripts designed like that. However I might think of reducing it now, because I was coding everything like I was going to sell it, and that take time

I didn’t know you can have a for loop without any parameters. Is that the same as a while (true) loop?

@Michael-ev6en

2 жыл бұрын

exactly

I'm wanting a few of my games to be mod friendly to where some can even have character systems of their own to degree. But I guess I still need to make sure that the systems I make are too many

Thanks for the video! Splitting up a huge Player script into smaller systems is the right thing to do imo. However extracting them into more MonoBehaviours will result in a huge number of scripts on the Player GO. I feel like this makes it harder to keep track of in the inspector and understanding the update-loop (order, states, etc). Having a "Player"-Script that internally delegates to subsystems like Movement, Interaction, Inventory, etc would make it easier to control, especially when using states. For example if i don't want the player to interact with items, while in air: Would the solution here be to disable the "Interactor"-component when entering the "jump/fall"-state and enabling it when exiting it? In my "hardcoded" statemachine I would simply not call the "Interact-System" in this state, which seems cleaner to me. I'm new to having an editor where this stuff is configured and I still need to get used to it. Everything that is not written in code, but configured in the inspector feels kind of unsafe to me at this point. Maybe this will change once I work with it some more. Anyway, thanks again for the video! :)

do you analyze, or design gameapp components and systems visually (class diagrams or sketch) - at least sometime? or you just "feel" them?

Soooo when will the unit of work video will go up?

this video saved me alot of pain

when should i use abstract class and interfaces?

What instances would using an abstrt Base class or interface be a better fit compared to a monobehavior component? Or is using composition over inheritance the way to go with Unity?

In my experience this is the only way if there's more than 1 programmer on the team and\or if you can't work on your project regularly and often. Learning and debugging monoliths takes time and is a nightmare in general. And if you for some reason fell out of your development loop - you'll have to do it over and over again or start your project from scratch.

Oldschool vim simulator? I really like it too :)

Thanks for the video. I know these are targeted at a more medium level audience, but it would be helpful to me if the bits of code shown on screen lingered a bit longer to let me mind connect what is being said to what I am seeing. Thanks again. Looking forward to more.

In my experience, approach like this also enable a unit test to be implemented. Whay you don't use interface instead of abstract class?

@rafaelocariz1384

2 жыл бұрын

You can create serialized fields of interfaces to link stuff together in the editor

Don't think that if you are solo then you do not work with the team and can write spaghetti. You will have teammate for sure- yourself in the future.

where have you been all my life

3:28 what a strange syntax at line 56: "for ( ; ; ) ..." What "; ; " means? Thanks for video!

@theneerex

2 жыл бұрын

It's a while(true) infinite loop, but with less symbols to write basically

Why do you use for(;;) is there a difference with while(true) ?

don't see in the player class where it's using interactor instance. Yes you should always try to step back.

Yes optimize for the future but not too far in the future. First things first.

What IDE is that?

So yeah, i use this kind of system for interacting with objects in my game world. But, i dont use abstract class, instead i use interface. My question is, which way is good ? Is it abstract way ? Or interface way ?

@ThousandAnt

2 жыл бұрын

I don't think either is better, I've used both and they can both create workable systems.

@hasansadikin1134

2 жыл бұрын

@@ThousandAnt hmm you think so ? I'm new to game development, so thanks for the opinion.. Sometime i doubt the system i made, because of my lack of experience. "Is it this way ? Or there is another better way to do this?" Is what i always thought. And i've become paranoid lol.

@ale-hl8pg

2 жыл бұрын

@@hasansadikin1134 If you understand how interfaces work you're probably ahead of quite a lot of people, I've had an extreme amount of trouble wrapping my head around when to use them as opposed to when to just use abstract classes. You should use abstract classes if you have multiple classes that seem to fit a similar purpose, and reuse the same or extremely similar code, while for interfaces you don't care about the implementation of their methods.

I've been trying to use systems to make my game easier to extend. Hasn't been going very well.

Second again hehe. Any news about the course btw?

@ThousandAnt

2 жыл бұрын

We're working on it! We want to get closer to having the course fully complete before we share further info about timeline, but it's coming along. The demo in the video is the same demo we are using in the course.

Warning for new programmers: THERE HAS BEEN REQUESTED AND APPROVED A SPECIAL PLACE IN HELL FOR THOSE THAT WRITE SPAGHETTI CODE WHERE THEY WILL NEED TO WRITE THE DOCUMENTATION FOR SUCH CODE. -With love, Your fellow programmers

What's that for(;;) loop? :S

@ThousandAnt

2 жыл бұрын

It's like a while(true) loop, it just loops without an end condition.

I noticed at 6:42 might be AI voice modified?

@ThousandAnt

2 жыл бұрын

No it's just a pick up line that we added after the main recording, just slightly different mic placement and levels.

@googleuser4720

2 жыл бұрын

@@ThousandAnt Ah dang, I would have been more impressed if it was AI that did it lol

I've never seen for(;;){}, what does that do?

@notsocasualgamedev

2 жыл бұрын

it's an infinite loop, identical to while (true) { .. }

@__ian94__

2 жыл бұрын

@@notsocasualgamedev ah, cool. Thank you.

Todd Howard: "It just works". :D And we all know how sorry Skyrim state is, even with modders patching it, after a decade.

FIRST

5000 lines is too much for a single class? Uh-oh... My Database class alone is over 10k. ...eep.

So the only drawback is "you can do it wrong". A red flag for advice being terrible.

I always ensure which part of code should be a system, and which should be glue code that links every needed modules to make your game work. Another approach is DRY(don't repeat yourself). When you found duplicated code, you should consider to create a system for it. And when you create a system, you should already have several use cases to back it up. That will avoid overengineering.