Can you make SUCCESSFUL games with DIRTY CODE?

👍 Learn to make awesome games step-by-step from start to finish.

🔴 RELATED VIDEOS 🔴

💬 Recently someone pointed me to an interesting post on Twitter where there is some discussion about the value of clean code since the Far Cry code was just leaked and despite selling millions of copies it features some terrible code.
Does that mean you can find success with terrible code? Should you ignore clean code principles?

📝 Some Links are Affiliate links which means it costs the same to you and I get a nice commission.
🌍 Get Code Monkey on Steam!
👍 Interactive Tutorials, Complete Games and More!

If you have any questions post them in the comments and I'll do my best to answer them.

See you next time!

#programming #gamedev #unity3d

--------------------------------------------------------------------
Hello and Welcome!
I'm your Code Monkey and here you will learn everything about Game Development in Unity using C#.

I've been developing games for several years with 8 published games on Steam and now I'm sharing my knowledge to help you on your own game development journey.

I do Unity Tutorials on just about every topic, Unity Tutorials for Beginners and Unity Tutorials for Advanced users.

--------------------------------------------------------------------
- Other great Unity channels:
--------------------------------------------------------------------

[maelhagel]

The main problem with dirty code is that a couple of months later even the people that wrote the code can't understand how it works

[AlexPBenton]

Do: Try to write clean code
Don’t: Only try to write clean code

My first ever Unity project was an ambitious attempt at making my large-scale dream-game. It went great, and I taught myself a lot about programming as I went. The problem though was that as I added more and more half-finished features, I ran into more and more structural issues and bug which could have easily been avoided with a bit of planning ahead. Eventually, it got to the point that almost everything was broken and the code was tied into such tight knots that I couldn’t fix anything without breaking everything else. I finally decided to just restart from scratch, using actually good coding practices, and the difference was immediately and consistently much better. Now I have a working prototype for that game, which is a solid foundation for me to add the rest of the features I planned for without ruining what I’ve already built.

[rod-abreu]

Honestly, this is like a "correct way to hold a pick" when playing the guitar, we need to see whatever way works the best for us.
I'd say, if it's a project with a single developer, and they don't really care about how the code is written and maintained, anything works, but when it comes to having multiple people maintaining the project and thinking about how the game scales, new features are added etc, then making it more component based and modular makes way more sense.
When you have lots of years of experience making games it kind of becomes second nature to write code that looks good and, but even for experience people it makes sense to some times refactor to have a code that ages better. If we have to change all the architecture whenever a new feature is ideated or implemented, then it's clear that we have a big big big issue in the code base.

[RockyMulletGamedev]

I do agree with the original tweet. A lot of people, specially beginner programmers, fall into the trap of over designing and according too much importance to "clean code" without even understanding what is important and what is not. Like I keep seing number of lines of code mentioned like it matters in the slightest. It doesnt.

In a world where you are the only programmer, only designer, only person working on a game in a short amount of time, yeah, you can do that. You decided what your game's gonna be and stuck to it. But any game created over years, by multiple programmers, decision taken by different designers, different managers, games change A LOT to a point where you can't predict what will be decided, if you coded something 2 years ago, that has been used all over the game, by people who stretched what that code was supposed to do and now you are asked to change something in there because of a design decision, you don't scrap it all and start over so it's "clean code" you slap some duct tape in there so it doesnt break the old stuff and can support the new one.

"Clean code" is an intension, not a duty. When you build a house from the ground up, you build it "clean", but once the house needs fixing, you don't bulldoze it and start over, you patch how you can. A VERY important part of game making is to iterate, playtest, rethink, redirect. If someone tell me they know, from the start, exactly what their game will be when released, every tweak, every balancing, every features, I'll simply call them a liar.

[Dilithium]

Every developer should watch this, messy spaghetti code only makes it harder on the developer and I know this from experience when looking back/adding to older scripts in my Unity projects. Even just using comments to explain what each part does in the code really goes a long way.

[nonstopper]

My thought has been. If you're getting paralysis from writing anything because you need it to be clean and perfect (happens a lot to me personally). Just write absolutely everything and get it working. Then when its working, rework anything that is hurting performance or readability.

[TegridyMadeGames]

You can always clean it up later. I've had people tell me in forums I'm going to give up for writing bad code in the past. They are just projecting their own insecurities. I still finished the project.

[alec_almartson]

For me personally it's about maintaining a "healthy" Balance in the code (and I think Jason Storey emphasized it several times in Jason Weimann's Game Shows... in his words (sort of): " Don't overcomplicate your code: if a feature does not exist today yet (and you doubt it will, in the future): Why creating separate Modules and applying a specific Architecture Pattern??... when... on the other hand, you can just get the thing done in some minutes with a Switch - Case and a couple of Boolean Fields??" (And your Client is not going to notice it, ... and let's not talk about writing "Maintainable Code" there because it's a simple App that will not require Maintenance (it'll rather die and then someone would create another one with another set of features, I'm talking about that kind of simple Apps).

Nevertheless: If you already know beforehand that your game is going to be dealing with some kind of specific Feature (even if it's not implemented right now...) you could take a step forward: take some extra time and create the code modules and apply some Architecture Patterns in advance, but at your own risk... As they said: <<Sometimes it's better to be Simplistic: if your Client asks you to develop a software that does "A", why adding the code structure and mock modules for; B, C and D?>> You will spend precious time, and in the end the EXTRA Code will not be used, so the extra time spend will surely backfire you somehow...

(Conclusion): For me it's about BALANCE: Clean and Organize Code vs. Practicality & Usefulness of following those specific Guidelines for me in this Particular Project.

PS: Nevertheless, there are some "Good Practices" that are part of any good Programmer's DNA, that I will always follow no matter the Project (they are there for a reason: helping you out not to get lost in your 10000 or more lines of code): Good Line Comments and Classes and methods Documentation; using Good Names for everything, ... and even Organizing your Unity Project Folders in a specific and nice way (although that's not a "code's Good Practice ", etc).
The basic Dilemma I was taking about in the above lines was more about: adding (or not) multiple Architecture Patterns to the code, beforehand (or even after some time, which means: Refactoring Code).

[GlassVaultStudio]

While dirty code is great for quick testing, clean code is great for speeding up your game development. It takes more time to set up, but in the end, it saves tons of time and will help get your project published.

We are using your complete course and multiplayer course as the backbone for our first release. Would not even know where to start without your videos.

Thanks for the video!

[sloshedtrain]

Every developer should strive for the cleanest code possible for the sake of future developers that have to maintain and update that code.

[everythingcouldbesimplify]

Inside game engines, I think it is more important to focus on reusability, if you can reutilize the code later in other objects that's good. 100% clean code in game engines, it is impossible to achieve because they rely on too much triggers, events and enable and disable logic, if and else basically

[JasonStorey]

100%, Programming goes through cultural swings like any other industry. Software architecture and design went from earnest helpful ideas to dogmatism, Same with scrum and project management and then questioning and fair criticism of over architecture has now horseshoe'd it way around to now being a glorification of cut corners.

Deadlines and Change in requirements are issues that can effect the give and take between good practices and reality of delivering. Sometimes cutting corners where appropriate is a great way to stay on track and support delivery of projects in a realistic timeframe.

Just as diefying form over function, throwing away useful tools because you want to emulate huge time crunch studios is a startlingly glaring lack of understanding of correlation and causation.
Most project fail because of inexperience, inexperience leads to laps in judgement mostly around complexity and deadlines. "Mess" in code is a consequence of trying to patch the difference.

All projects will have _some_ mess, because all projects will have some new experiences and as a result some laps in judgement. That is fine, that is what experience is.

In short, if you want to make a game, In the giant hierarchy of things that will hold you back/propel you to victory.., code cleanliness is somewhere near the bottom. It supports change and maintenance. For 90% of people you will have much more realistic falls at the hurdles of scoping, time/resource management, failure of project management and failure to position yourself in a market/ failure to put enough resources into marketing to build an audience.

In either case, Clean code is a nice tool to learn, its not the be-all or end-all, its also not the devil. Don't throw away your screwdriver because you bought a shovel, and don't destroy your shed because you think the pyramids are impressive and they didn't use your tools.

[dbweb.creative]

Bad architecture creates roadblocks, where making planned progress can become nearly impossible, or very daunting at best.

[adadventure]

i appreciate your heaty-passion here, but mostly how you kept it cool and paired your perspective with some benefiicial rationality and logic.

from my own experience:
- i often come back to my code weeks+ later and find that i forget details such as context, flow, and what exaclty a piece of code did logically and mathematically. i've started to add meaningful comments (as documentation and other things like *todos* *issues*). i enjoy the process of doing so.
- i personally enjoy learning coding conventions and programming patterns like i would a beautiful piece of art or martial arts discipline. it's aesthetically and experientially enjoyable... and of course, functionally they add depth, flexibility, versatility, scalability, etc to my code and assets.
- if everything is in one file or it is difficult to refactor what is currently coded, then it's hard for me if i want to make a new project and use my basic assets like character controller, camera controller, rigidbody movement script, etc. i'd have to copy, paste, tweak, and decouple the dependencies and more. when i have it all properly factored, separated by concern or relationship, then it's easier to work on one part without having to work on the others.
- i like the KISS (keep it simple silly) approach, which generally for me is about simply just getting things coded and functional, and then gradually and meaningfully, when the project or your learning path demands, just start to refactor and cleanup.

- for instance i coded my first simple logic for ny AIcharacter and it was all done in one script. Now i have changed it so that there is a StateMachine class and a BaseState class to handle the different states, and in the process i now have a reusable base class to create my ai character's state machine and states that will handle a fairly robust set of bheaviors. The StateMachine base class can now be used for other things in my gameworld. The AI character has its own derived CharacterStateMachine class, and its own humanoid based states, that can further be expanded upon by a specific type or individual character. From the experience i can say i see better when and where simple or complex code can be used.
- i've had experience in other languages like basic where i coded the entire logic in one file, or in C++ where i had to code the entire game loop. They were great experiences and showed me when and where cleaneness and modularity would be helpful and preferable.

It's much more clearer and easier to work with when i have logical structure, good (self) documentation and separation of function and concern, especially when the complexity and mass of the project grows.

[moshecristel]

I agree... and I'll add that writing clean code is a discipline that gets easier with practice.

[Buster]

Think the original guy on Twitter misunderstood. Most AAA game code (at last back when Farcry was written) is throwaway code. They work against tight deadlines they start with good intentions but, the closer to release the more and more hacks it gets. Outside the game industry code is continually maintained for years sometimes decades. It is continually refactors, listed, peer reviewed, statically analysed etc..

[Laumania]

Totally agree, clean code is SO important and also agree on that it's a balance.
Before people start thinking that their code is too bad etc. Remember, none of us writes all our code "clean", in first try.
This is actually the most important thing, that I see a lot of devs forget - refactoring!

First, make your code work, then refactor it, so it's simpler and easier to maintain (clean code) as good as possible. Continue like that. Refactoring is not something you do once, you do it all the same in tiny steps, which at the end of the day should make your game cleaner and cleaner.

[almazingsker]

Well now I am going to type out a long-winded comment since I am inspired by your own long-winded comment. For context, I am a web developer who works in C# and Javascript. But before I became a software engineer I was watching your videos to learn how to code using Unity.

I think I sit somewhere in the middle on this argument, but I mostly agree with you. I often view your idea of clean code as being intentional with the code you are writing, and making your code as extensible and flexible as possible so that revisiting it later is easier. This is generally a good approach, because it encourages new developers to really think about what they are doing. This counters one of the biggest mistakes I find junior devs make: They try to code too fast. They see a problem, and they start writing code immediately to try to remedy it. Your clean code principals encourage slowing down, understanding a problem/request as much as possible, then once it is narrowed down, code can be written. That is an excellent practice that saves a ton of time and prevents a lot of tech debt.

Where I tend to disagree is when it comes to working on a team, or in an organization, and NOT as a solo dev. Funnily enough, this is where clean code matters the MOST. Yet, working on a large team like this means inheriting a lot of legacy code. You are often not implementing new features, but adding to existing ones and fixing bugs. You also often have pretty tight deadlines. In those cases, with product teams and managers asking for updates, spending time to make code as clean as possible is not very worth it. In this case, it is usually best to follow the existing styling/code habits of the team and the codebase because multiple people are working on it at once. The challenge becomes: Should I spend a day to refactor these methods and fields into their own class to make the code more modular? If the spaghetti already exists, will i introduce new bugs with this change? Then I will have to make sure the team is aware of this change so they don't get confused as to why that method isn't in the old class anymore. I'll also need to make sure the product manager understands the value of this move so that I can justify spending the time on it instead of squashing that bug that QA reported last night. Sure, it will save time in the future but the future is much less grounded in reality and can be hard to convey to the team. Is clean code worth shaking up the foundations? From a fundamental view the answer is a massive YES, but in practice it is a bit more complex. I think the better lesson to learn as a junior is to understand the values of the team and match up accordingly. Some things are just better off let go in favor of things that have more impact, like adding a new feature or fixing a bug. Unfortunately, lettings things go is a slippery slope and that is how you get the giant classes in Farcry and Celeste.

In the moment, clean code takes more time. But looking ahead, it saves time and makes things easier. The decision that needs to be made is if the problem you are facing can be tackled while looking ahead, or if it is more important to just fix it as soon as possible and push out a change. This also doesn't even take into account code reviews, which I think also remedy a lot of these issues. There's so much to talk about lol

[fannyzero]

I agree with you! As of now, I am taking notes about having a neat code in your 10 hour free course!

[lucasmontec]

I guess its what I always say to people: you gotta know your tools, there are no silver bullets. ever.
1 person team with a small scoped project? code for what you need.
1 person team with a big scope? organize your stuff with known techniques (such as clean code). Otherwise, you shoot your self on the foot later on.
several people team with any scope project? try to do that with no architectural definitions to see what will happen... XD

There are no silver bullets. You have to know what architectural and organizational techniques there are so you can decide how much to use, where to use and most importantly, why you are using it.

It sounds ridiculous when a junior dev wants to justify their spaghetti unredable code with a non-reason such as 'it works'. You can hammer down a screw, it will work sorta-like a nail.