How to write more flexible game code

Writing code that is flexible and receptive to change can be a challenge, but these tips can help you improve your codebase, no matter the size of your game.

The application hierarchy: 00:00
Managing data and logic: 02:32
Use components: 04:01
Dependency injection: 04:38
On design patterns: 05:59
The final tip: 07:37

[diegonorambuena]

My man, the last tip part hit me hard I have spent a lot of time trying to solve the perfect solution, but whenever I start coding, I freeze after a couple of lines and go back to the drawing board. It's endless rn. Thanks for your words :D

[krysidian]

You don't know how glad I am that I found your channels. It's a godsend of useful and concise information and I really hope more people will find it.

[learningforever]

This video is a gem, is CRUCIALfor anyone who is working on any relatively "big" game. For me is the point where I struggle the most, to keep things organized in a way that Im able to look at past code and know exactly where I have to look if I want to check something.

I enjoy your content a lot! Keep it up!

[learningforever]

3:45 you nailed it! Is what happens to me EVERYTIME; I know I have to keep things separated, but when I have to add a single thing is like "huh, but creating just a class/script for this.... I can handle this here". And thats how problems start D:

[pythonxz]

I love that you go over "Tell, Don't Ask.". Everyone should read The Pragmatic Programmer.

[kemeros]

Incredibly well made, useful and concise video that hit close to home. The final tip? Oh man, I hear you and i will need to play it in repeat in my head again and again because... i've been learning theory for a year and haven't done anything useful and mostly forget everything i learn because i don't actually use it.

[bugimplementer]

The final tip is so true!! Thanks for the reminder. Great video.

[NicholasGrigoriev]

I don't know why, but it's your code example for Dependency Injection, that finally made a click in my head, and I finally understood it. (or at least I hope so). Thank you Sir!

[juanloutech]

Very well explained basics of programming (not just game programming)

[queenofsquiggles]

I absolutely love this! The details and the way you explained it was incredibly useful! I'm really interested in good design practices, and this will definitely be a video I reference!

[panampace]

I put off making a state machine for my character controller for such a long time because I thought it was more complicated than it was worth - BOY was I wrong. Setting up a state machine ought to come first in a character controller - makes it SO much easier to add functionality without screwing up another part.

[pedroehler]

The most important thing "it takes time"!

[mbg]

Well said, all of it but especially that final tip. Reasonable, approachable, fun, candid, considerate advice! You sound way too young and spry to be this wise already.

[pabletoday]

These videos of yours are masterpieces

[spudrat]

wowwww this channel is so underrated, just found you, really sick!

[realMenta]

Thank you, really nice tips and easy to understand.

[circusmonkey]

The Final Tip is the only tip that made sense to me which means it is too early for me to watch this video xD

[Rin-qjzt]

you should mention that assumption of structure is actually fine in cases where the architecture is specifically designed for that to be the case. for example, every major location could be a sibling of the same parent node by designe, so they can be switched in and out of memory like legos. assuming that the parent has the same resources it always does is fine, because we never intend on putting a major location anywhere else in the tree.

it's okay for some structure to be designed not to change, and this grants some level of flexibility when coding because it allows an assumption to be made. it depends on what advantages you gain compared to the advantages of staying dynamic.

[ThunderThoster]

Love it! Many thanks for your enlightenment _/\_

[badunius_code]

5:40 that's where I'd argue in favor of using signals.
Because what is presented relies on having a very specific owner.
Signals otoh allows owner to listen to the ones that are relevant and interpret them in its own way