Why this SKILL will make all your code BETTER!
ฝัง
- เผยแพร่เมื่อ 7 ก.ย. 2024
- game.courses/mp - 2023 Multiplayer Mastery Course - Open NOW!
game.courses/mp/ - Multiplayer Mastery Course - Open NOW
prf.hn/l/1MVvB0Z - 50% OFF | Dev Days Sale - FULL LIST
gamedevguild.c... - FREE AI Ticket
game.courses/b... - 2023 Game Dev Course
![ตีสิบเดย์ [FULL] | นางเอกหมอลำเงินล้าน "อุ๋งอิ๋ง เพชรบ้านแพง" & ไฮโซสาวสุดฮอต "ลิลลี่ เหงียน"](http://i.ytimg.com/vi/jPxQS_EgrJ4/mqdefault.jpg)
Refactoring is something that is crucial to all programmers.
I'll start by making something work and then refactor it as a I go to improve is efficiency or make it more modular.
It's absolutely imperative in the project no time left
Deleting big chunks of code, variables and sometimes entire scripts and still see your game running just like it used to. So satisfying
I emphasize his point on not changing functionality while refactoring.
My biggest weakness is getting distracted with some "cool new implementation" idea and changing functionality while in the middle of refactoring... it ALWAYS ends up as chaos. One thing at a time. I should try override methods more for alternative implementations... 😅
Following other peoples code is absolutely mind bending.
Video request: ive noticed that a lot of unity developers started their programming journey with unity and therefore have quite the knowledge gap when it comes to the actual structure of a program. I think itd be fun to hear someone demystify for audiences a higher level explanation of compilers, linkers, dynamic vs static linking , what all the folders do, Bins etc.
I just remember when starting out I'd treat everything other than my own scripts as a black box and anything outside of that realm was essentially corrosive acid I'd steer clear from
"knowledge gap when it comes to the actual structure of a program"
They truly believe they don't need to learn this. Let them sink.
@@IBelieveInCode I'd hope at some point they get deep enough that it becomes abundantly clear they need to understand how things work. Really it should happen earlier, I remember when it happened for me, at the file system when saving data I was like wtf is a stream and the black box I was supposed to use was just so alien to me I knew that I was basically not even coding i was just interacting with software as opposed to engineering.
And so some lectures on OS cleared a bunch of stuff up and I was able to venture into the realm of lower level programming and then my time in unity started to actually really make sense
Do you have any resources to recommend for learning all this ?
@ElianeGameDev also look up OS university lectures and watch them all, take notes . You don't need to remember it all, you just need the big picture
The cooking pasta in the previews got me.
Even better in my opinion would be to keep track of the previous value of tickets sold, then based on the new value, whether it's higher or lower than the previous you can iterate only over those indexes from the previous to the new value to enable or disable.
While this approach is definitely slightly more efficient, I'd argue that it is a worse solution for this particular case where the number of objects to update is relatively small. You are adding extra state and making logic more complex to parse for human readers without any real gain. I've learned with time that simpler solutions are usually the best ones, even if you have to pay a bit more computationally. However, if there were thousands of objects to update, then your approach become better simply because the computational gain would outweigh readability aspect of the code.
@@FICHEKK Considering he's only mentioned two states, either a single person is added or all are reset, I have to very strongly disagree with you there. The logic could be done in 5-6 lines of code. And if you're not lazy about doing it the code would be quite self-documenting. If I saw code checking for a change in direction or a value and doing something depending on that result it's extremely clear what's going on and why. To see code that simply iterates over all items on a change and sets their state based on something I'd argue has worse readability if anything, because now I have to ask what changes actually occur, the cause and effects aren't as obvious when everything is applied on any update.
While I agree that from a performance perspective the gains in this particular case would be rather small, this channel nonetheless creates videos teaching people how to create games. Despite best efforts many people are going to walk away from this video thinking that particular way of updating state on value change is the proper way of doing things, and the newer folk to game development won't understand the difference between this approach with a few objects versus hundreds or thousands. This is part of the reason we see so many poorly optimized games come out of the indie space, because many of the developers learned a lot of their knowledge from videos that showcase particular ways of doing things without taking the time to explain the circumstances under which it's acceptable to do so compared to other approaches. As an educator he could at least mention that such a method exists.
Hey teacher! Have a great day... I ready for Saturday and in ready for another live stream and I'm ready to keep learning code
continuous improvement is important too (learning new stuff all the time)
Love this type of video!
Jason, do you have any video tutorials for 2D action platformers to follow where it shows how to create a Player get hit knock back effect? Kinda like how the old megaman and castlevania games were. Its easier for me to follow a video of steps how to do it properly My player can take damage and sounds happen when he gets hit but can never get the result i want to have the player get knocked backwards if i walked into the enemy or jumped on it
According to "Uncle Bob", a method does one thing and one thing only if:
*_you cannot meaningfully refactor-extract another method from it._*
So he advocates "extract method" until it becomes impossible to do so anymore.
He also says that the level of abstraction of every call in a routine should be the same, namely one level lower than that of the routine itself - which seemingly would be an inevitable consequence of following his recommendation.
Are his reasons compelling? Yes. I take him to essentially be advocating that you inundate your code with as much semantic content as the code's logic can bare, via the meaningful names you've given to every last little thing you're doing in the code.
Have I ever seen any code consistently take things that far? Nope. (Maybe they do that in pure functional programming, something I've never done.) But I think it's still worth keeping in mind, and is at a minimum the right bias to maintain... to err on the side of smaller and extracting more. Moreover, the performance loss from function call overheads should be ignored until profiling reveals that it matters... and if it somewhere turns out that it does matter, it's straightforward enough to merge the tiny routines into a single bigger routine (whereas going the other direction is more taxing).
Also, local functions can maintain the semantic/intelligibility benefit of a named function call with much less overhead. There's a video by TaroDev where he shows this by examining the IL code from local functions versus private members. I've always loved local functions for routines that I know can be applied only within the specific context of a larger algorithm, since I dislike polluting the intelli-sense and class member list with private methods that will never be used anywhere else but within that one function. (Of course, following Uncle Bob's advice will overflow the intelli-sense and private members... until you refactor those out into their own also-numerous-and-small classes.) However, the performance gain PLUS the semantic/intelligibility gain suggests that local functions should be used liberally even beyond that only-really-makes-sense-here situation. And if they ever do need to be elevated to private members (via DRY), that's easy enough to do (one issue is that they don't appear in member lists, so might not know you have them - a "//local" comment could aid a class search.).
Anyway, that video is TaroDev "Local Functions in C# - Stay Inside Me" watch?v=D7Kf1CY1PNQ
Opps... I hate the bare bear mistake. I hope bears aren't modest.
Refactoring vs Engineers' first rule: if it works, do not touch it.
Yeah but that's the difference between digital and analog. Digital stuff doesn't have to deal with entropy.
I usually, when I code something, leave a good mess after various tests and failed attempts, and I don't write the code itself somehow with performance in mind. Only when I think it's working as it should, do I sit down and change to a much "nicer" solution that will be more efficient and in the process clean up the whole mess haha
i can use a tutorial on how to make my doors that i open, (they have a sphere collider trigger once player enters zone) instead of an auto trigger i would like a BUTTON trigger (E) button and load screen then go into the next scene, i alread have keep player INVENTORY and stats ect though
8:40 Might be a bug (depending on how your game works) or it may be intentional 😅. You don't remove the difference between Time.time and _next_upkeepCostTime.
So over time, "_next_upkeepCostTime" gets further out of sync because each time you update, you add 5 + some leeway.
You may also just += 5 in fact.
Once you start implementing events (Observer Pattern) you really start to get allergic to putting anything in an Update method.
Then you're clearly still a junior, eventually you'll understand that there's nuance and use cases for everything. That mentality you described usually stems from the excitement of learning a new functionality.
But think about it, some of the world's greatest software was written in C with just straight up structs and of data, good use of pointers, functions, and maybe a union or two.
@@IDontReadReplies42069 Totally agree
Easier to read and keep track of things
And more straightforward
@@IDontReadReplies42069 Your second line is what gets me. I see and play all these ancient classic games written 100% from scratch (if you go back far enough), or at best a very basic console SDK or primitive engine. These games absolutely pop despite them not having access to the likes of Cinemachine, C#, cool plugins that could be downloaded in a snap, HLSL, all the modern day cool stuff. All hand hacked in C, or perhaps even pure assembly.
I _do_ have access to all the modern stuff yet the games I produce are still absolute ass. Feels bad man.
The amount of TH-cam tutorials still pimping the old input system on Unity, or abuse and misuse the new one by checking for the Triggered event every frame.
Like... no?
@@IDontReadReplies42069 Thanks for the enlightenment, chief! Eventually I'll understand. Just need a few more snarky-but-accurate TH-cam comments. 😜
Gold medal for funny face on video cover!
Just refsct9red a big chunk of the least fun part of my codebase (very ui heavy, save/load... you may rhink of it like deck building in Heartstone though the game style is d8fferent and has no deck). Wow it feels so good when really old and really shit code disappears and program works again
Jason as programmer do you understand hacking?
No? :) not the kind where I change all my friends grades like they requested at least :)
@@Unity3dCollege
Careful... that road eventually threatens to cause a Global Thermonuclear War.
If you want to get into video game hacking, look into "game trainers". You basically look for a value, say your gold at 1000. The trainer looks through the game for all values that are 1000. Then you change your gold amount. Kill a monster, get 50 gold. You then use the trainer to sieve the results for 1050. You look at all the results that were 1000, and see which ones changed to 1050. You can then change the value or even freeze them.
That's how I did it when I was a kid back in the 90s at least.
Careful though, you'll probably have to download some shady software.