I do find these "masterclass" style videos extremely helpful; learning about fundamentals is of course very important, but the piece that is often missing (and that unfortunately mostly comes from years of experience) is the "wisdom" of development and architecture design. Great video, and looking forward to more!
Architecture FTW! Agree with most of what Thomas said, esp about modular organization by-feature/system, and trying to understand what game you're making upfront. Couple arch tips: + Start with Screens - try sketching/listing what the player flow through the game would look like. It's a bit like designing your game loop, but gets into more concrete terms of what will the player see/do at each point. You can divide up your architecture this way - things on a single screen are related (same folder, maybe same/related classes), things on a new screen, or a diff gameplay "verb", are unrelated. + Architecture Assets - quality varies, but there are some good genre-template assets on the Store (Unity and GameMaker, not sure about others). If you find one that's well-written & has good support, and matches the type of game you're making, it's okay to use that as a foundation. Just be sure that the code style and support level is a good fit. Some are better for beginners/no-code, others are better for folks who want to write custom code integration. + Teams - if you ask two programmers the best way to add 1 & 1, you'll get five answers 😅 My exp is that communication among the team is essential. Decide from the start what the architectural approach will be, *write it down,* and make sure anyone coming into the project reads & abides by it. This is where stuff like system diagrams, interface/event docs, and processes for new features (or deprecations) comes in clutch.
I just have a single GameManager singleton that lives within a Game scene and has references + getters for the sub managers which aren't singletons, but because everything uses the GameManager to access the sub managers, they're effectively used like singletons. This has worked pretty well for me.
The architecture also depends a lot on the situation if your are a solo dev, a small group or a larger group. Each situation has different challenges, and what works conveniently for a solo dev could cause misunderstandings and conflicts in a group.
Making a game would learn you so much programming skills compared to years of learning tutorials. Thomas seem to be having impressive programming skills 🧠
True, but much of what he said here is a combo of formal school and work experience. Online tutorials can get you far, but a lot of the "boring, but essential" stuff is lacking. Have never heard "gather requirements" in a game-dev video before 😂 Not a bad thing though!
Awesomely special and useful video! Thank you so much for that! This is actually the topic literally NO ONE speaks about, and yet for a newbe like me who started building game from learning art and now am getting into Unity, it's a crucial topic. How to structure your game, even how to create a folder structure for your Unity project? That's golden info, those questions have been nagging me for so long. Thank you, you're the best!
I'm interested in this topic, but don't feel I learned much in the video. It was quite an abstract and high-level description of the general principles. I'd love to see you guys do more like this, if you're into it, but would suggest illustrating each point with one or more specific, practical examples. Still enjoyed the video, though - cheers.
I really like the more technical stuff and how you actually use design patters and architecture. I own the book you reference and was cool to see other people talking about i!
Great video. Even when i didn't fully understand some elements (like what static exactly meant) i still learned something. Also i realized why some tips you and other dev tubers give to new solo devs (such as when you were talking about rewriting code again i kinda realized that is one reason why people suggest to make prototype, demo and full game on separate builds and always start from scratch - one reason probably is because the dev should plan prototype and demo for smaller scale which the code should reflect - also when you were talking about designing game first my brain went into design docs - many times devs just suggest doing them for reasons such as "you can't remember everything" and "it makes it easier to handle the project" but i don't remember anyone mentioning how these design docs also help with coding - because if you already have ruled a mechanic to work in certain way then you should also know if you want to keep the code expandable or.... does the word "static" fit here now?). Really good video and i probably will need to rewatch this again after im done with my demo phase but before i start working on the actual full game.
Typically it's basically one of the two: proper/difficult/thorough extensible development vs easy slap-on development with a major/impassable roadblock. Pretty much always aim for the proper development, otherwise you ain't going far with that project, and most likely end up quitting, because everything is tangled and you'll feel your arms tied to do anything.
Using Unity DOTS makes it even more easier to work on Module Based Development. Create a new project for a POC. It works? Copy-Paste the code as is into your base project and works out of the box. What i found useful is treating each game as a dedicated package to be pushed to the unity store, completely independent, and having a separate folder {POC} that uses the systems. Not recommended for starting with it, but it does make it easy to 'plug and play'
Definitely more of an intermediate topic, but agreed. I am very lazy about writing unit-tests 😅 But maybe also discuss your approach to UI & gameplay testing.
Agree, UML Class and Sequence diagrams can be very useful in thinking through code design. Keep it quick and lightweight - google agile modeling tips. Formal diagram tools can be a pita; just sketches on a whiteboard, paper, or free drawing tools can be enough for anything an indie might need.
I find model diagrams to be more useful for databases & APIs than classes, but I agree that they're excellent for beginners. Can also be helpful for message/event-based systems, to graph out what data needs to be shared, and what should not be.
I'm not a fan of UML. First of all, it is made for OOP business logic and even there, the models barely survive first contact. But i'm a fan of lightweight diagrams that describe how systems interact. Unitys references to other gameobjects makes it easy to build "everyone accesses everyone"-networks or as we call it in programming: spaghetticode.
@@sealsharp I'm not a huge UML fan either, but the issue you're describing is more about bad process. Before Agile infected everything, when we actually paid people to plan & maintain software projects, change management was part of the job. So updating the model & logic docs to be in-sync with any proposed/implemented changes was required for sign-off. Whether those used UML or something less-formal or in-house, the main point was that anyone could review the docs and know for sure that that's how the live system works (or the proposed system under-test).
@@mandisaw Agile: from misunderstood to consulting abomination. ^_^ I think the original "agile" around self-managing teams has some value. The whole business developed out of it with processes around not having a plan, i see why you call it "infected". In reality, software is often developed after a contract is signed and a contract gets signed when delivery date, features and pricetag are all set. How you're gonna do that? Well, making a plan and it better be good.
Regarding the "use UML or no" question: As a solodev I really don't think they're that useful, but I think they can help communication when you're discussing architecture with your colleague coders. It also helps discussion when you're delegating responsibilities, and shows what modules require a more structural approach with interfaces for cross-module-communication, as two different programmers might be coding those modules. They can also show if there's some undetected misunderstanding of game mechanics among devs. (that shouldn't be the reason to do an uml tho)
Architecture spans beyond software. It encompasses the entire pipeline-including art, design, and quality. Interfaces also go beyond software. They are standards for integrating pipeline parts to move a feature from concept to release. Also, check out how experts like Juval Lowy, Carliss Baldwin, and David Parnas define modular architectures to avoid rewrites/refactors when requirements change.
I agree but as a solo dev with a full time job you don't always have time to write perfect structured code. I've tried my best but still certain parts could use a refactor.
architecture is always kinda hard. You plan too much and architect everything perfectly and you will end up wasting a lot of time and make things that could be very simple super complex and on the other hand if you make everything on the go and don't really plan you could end up having to rewrite a lot of code. I honestly like the quick and dirty approach to like be able to playtest an idea but I think this approach can bite you really hard if you don't find the right time to rewrite some systems. I recently did a game jam and I honestly like the game I came up with but to make something more out of I'd definitely need to rewrite a lot of systems as I went for the suuuper dirty approach for a lot of things. I think at that point I'd basically have to rewrite most of the game lol
my codebase is a tangle of hacked solutions and comments that say //todo refactor this there are always more functionality and bugs to fix so going back to actually fix the code structure can feel like a tedious luxury unless the bug you are fixing pertains to the actual code structure
well I used to be all project structure and no game mechanic at all. Then I started to work on focusing on game mechanics. Then I tried to make commercial viable game, but failed. Then I wondered why I failed....A lot! We need something which could be visually representing our vision of the game, so we don't get demotivated too early. Then we could approach whatever we wanted to do. Some might want to start with front-end stuffs, some might want to back-end stuffs, some might want to work on assets. Everyong have their own comfortable workflow. The key is to make sure we have solid goals and something to make us stay motivated.
I strongly believe the motivation to do work that must do, but don't want to do, cannot be sourced from the work itself. Balancing your life outside of the work, keeps you working. In every game there is stuff that's not interesting that connects all the interesting parts together. But it needs doing, and if you can only work while you want to work, truth is, you'll never finish anything. So, managing to work on what you don't care about, isn't about learning to care about it (though you should slow down, take pride in it and polish it like your name was gonna be on it) nor is it about finding joy in it. Your feelings about working, can't be the factor that makes you work. Feelings change, work never does. It's about having balance in other places in life, so when it's time to work on the hard stuff - You dive in each time. Dreadless and committed. Sitting with it until it's done, and then taking your free time to refuel and rest. What kills people is often the dread, and you can't force yourself to love something you dread. Silence that, stop looking for a finish line or an exit, and just, sit with it. When you are calm and submitted to the work, do it for as long as you planned. Then stop, and live your life, knowing the same time tomorrow, you'll submit to the work again. Most people struggle with where they are because they are focused on where they want to be. Unaware, the choice focus on the reward, keeps you from earning it. Submission of your mind and desires into the moment you've committed yourself to, without struggle, and without paying attention to anything beyond that moment, helps you complete the task with pure focus and without the need for motivation or the desiring pain to want to be doing something else. Like a cold shower, just stay in it. It's done when its done. And you'll feel better finishing than starting every time. Motivation is unfortunately a trap. If you let it guide you, it will always guide you to nowhere.
@@honaleri I have to disagreed with you. First of all the motivation to work for me is NOT the fuel to push me to work on something but the level of interest in something which I have. I can work without motivation but I won't be able to stick with something if it's not interesting enough. We just have different approach in life, that's all.
@@dreamingacacia That's exactly what I'm saying. Your level of interest can't be the thing deciding if you stick with something or not. Or in the end, you will stick with nothing. It's not about the way you live your life, its about how the human mind works. In all passions and efforts, there are moments of lull and disinterest, and for most that's the end, nothing finishes. You asked why you failed. This is probably why. And it will repeat, every time, if you rely on your interest to decide for you if you will follow through. In the writing community, people who don't finish their books always stop at the same position, the moment they weren't excited anymore. People in the art community, can't finish their drawings at the same moment, when the work outweighs the expressive fun. People in the game design community, stop at the same point, when the amount of reward they can visual see as progresses, slows down too much, and they can't feel thrilled about all their updates. They all suffer the same illness. Requiring their emotions to dictate their actions. In other words. Needing to feel interested in order to be motivated to finish. The work can't be finished if its fueled by how interested you are. It can however be finished it its fueled by commitment. tldr Motivation = The level of interest. They are identical forces.
@@honaleri that's why we have to disagreed. While I could understand some level of your perspective, I don't think you understand mine. What's the point in sticking with something you lost interests? I built my workflow around my nature and I'm perfectly fine with don't stick with stuffs which I no longer have fire. I have confidence that I could finish what I started, but that's still have to follow the rules that I made for myself. Like I said, it's a matter of different approach in life. Nothing is true, everything is permitted.
@@dreamingacacia I understand your perspective perfectly. All things you or anyone ever do in life, will contain moments that are not interesting. Everyone meets those moments. The ones that only value a task in so far they enjoy ever moment of it, will never finish anything. The ones that value what they aim to, more so than every moment of the act of doing it, will survive the process into success. The people who fail, always fail the same way. For the same reasons. I was just answering the question. Why you failed. If your methods worked, you'd have a game. Correct? Perhaps I'm mistaken. Regardless... There is truth everywhere, but few are willing to seek it out. Fewer still know it when they find it. And even fewer will use it, once they know it. The point in sticking with the things you lose interest in, is necessary to completing any task. You'll not find any profession, or hobby that is always only interesting. If you let those hurtles stop you, ever direction you head will lead you back to nowhere. I pray you don't lose time to that endless circle. Many lose their whole life to it. And never finish anything they start... And everyone's nature is mostly the same...that's the source from which I speak. Your nature demands interest, but no task will ever supply enough. Many people take the route you take, only those who leave it eventually,...make something in the end. Good luck regardless.
Would love a talk from thomas about pathfinding for management games, or games where the pathfind map changes a lot in general, I know that usually everyone goes with A* but how do you plan your map? Specially if not a grid based
You might want to revisit the basis of A*, the why, not just the how. It's basically just a list of positions/nodes - the nodes don't have to be in a grid, and the list can be dynamic over time. You can have pathfinding that recalculates the nodes/map before doing the character movement, but it could get expensive if you're doing it too often (like every frame). But you can find a balance.
@@mandisaw The balance would be recalculating the nodes and connections whenever you build something new, but I cant visualize how I would position the nodes in 3d space :/
@@viniciusantonio2253 The nodes are just data, the pathfinding is just logic. You can make the data mean whatever you need it to - passable/not-passable, high cost/low cost, near/far, etc. Mapping the nodes used for pathfinding to real-world space can be a separate, one-time-only thing. Maybe look up some tutorials on doing dynamic 2d procedurally-generated levels/mazes (e.g. for roguelikes). That would likely have similar logic around dynamic nodes & pathing.
Thanks for covering this topic. ----- I spent unnecessary effort to prepare the code & architecture ; then I stop after I realize the game is scalable but not playable after few months. (hide the pain 👍)
Only make the code extendable for the current project and its planned features. Dont try to make "clean extendable code" for an assumed later project. Its likely never going to be reused as is anyways, but rewritten or just reusing specific parts. I also plan in several early prototypes that get rewritten latter. With the main project only build when all core mechanics where tested in seperate prototypes. The worst enemy is complexity.
dont bother drawing a detailed class diagram if you're a beginner - just draw some rectangles representing your modules and draw arrows showing how these modules communicate and reference each other, it'll be enough trust me
Not a real game unfortunately, (almost) all our thumbnails are using midjourney generated art, including this one. The prompt for this specific one was: low poly 3d, castle construction site, birds eye view, fantasy medieval, game, crane, --ar 16:9 -M
I think most architectural experts would select design patterns to fit the scale of the project. Wildly over-engineering a small project because you have a dogmatic objection to a particular pattern is not good design, at least in my opinion.
@@JackFoz454 Sorry, I can't think of any project size, which doesn't benefit from unit testing and is too small to use aprox. 200 loc for a service locator. It simply doesn't exist. On the contrary - a service locator is a pattern to speed up the development of smaller projects, as it makes reuse of components a breeze. I stay to my statement - there is no justication of a singleton except the service locator. Nothing dogmatic about it, it is pragmatic. Period.
@@SunSailor If the singleton pattern has no benefit for small and beginner projects, why do you think it's so ubiquitous in small and beginner projects? If your solution really were objectively better in all circumstances, would it not proliferate accordingly?
@@JackFoz454 Because people don‘t know it better. Don‘t see any real argument in your post. There is no justifiable reason to use a singleton not managed by a service locator. If you don’t understand that, your skills are not developed enough to understand. Doesn’t make the singleton right. Continue learning, and you may understand, rookie.
@@SunSailor I'll ignore the weird personal attack, but feel free to reflect on what it says about the strength of your own argument. My argument is that singletons are widespread in small and beginner projects because they are simple and effective in small and beginner projects. You claim that your alternative is objectively better, and the only reason it hasn't caught on is that the rest of the software world is not as clever as you. Good luck with that.
Honestly have never seen a video with as much bad advice in it as this one. You would make a better game faster if you did the exact opposite of what they say.
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
Your eyesight didn't get worse, it just seems that I didn't get my manual focus 100% right for this video, sorry!
-M
Dammit, I already ordered new glasses.
Oh I thought it was my blasted game dev eyes 👀 lol
@bitemegames the red border in the thumbnail is really bad, I thought I already watched the video😂
I'll be honest, I thought shit RUclips will not stream in 1080p it's stuck at 480p 😅
The camera is focused on the plant in the background
Always enjoy hearing programmers talk about the ways they approach architecture, great video!
I do find these "masterclass" style videos extremely helpful; learning about fundamentals is of course very important, but the piece that is often missing (and that unfortunately mostly comes from years of experience) is the "wisdom" of development and architecture design. Great video, and looking forward to more!
Architecture FTW! Agree with most of what Thomas said, esp about modular organization by-feature/system, and trying to understand what game you're making upfront. Couple arch tips:
+ Start with Screens - try sketching/listing what the player flow through the game would look like. It's a bit like designing your game loop, but gets into more concrete terms of what will the player see/do at each point. You can divide up your architecture this way - things on a single screen are related (same folder, maybe same/related classes), things on a new screen, or a diff gameplay "verb", are unrelated.
+ Architecture Assets - quality varies, but there are some good genre-template assets on the Store (Unity and GameMaker, not sure about others). If you find one that's well-written & has good support, and matches the type of game you're making, it's okay to use that as a foundation.
Just be sure that the code style and support level is a good fit. Some are better for beginners/no-code, others are better for folks who want to write custom code integration.
+ Teams - if you ask two programmers the best way to add 1 & 1, you'll get five answers 😅
My exp is that communication among the team is essential. Decide from the start what the architectural approach will be, *write it down,* and make sure anyone coming into the project reads & abides by it. This is where stuff like system diagrams, interface/event docs, and processes for new features (or deprecations) comes in clutch.
I just have a single GameManager singleton that lives within a Game scene and has references + getters for the sub managers which aren't singletons, but because everything uses the GameManager to access the sub managers, they're effectively used like singletons. This has worked pretty well for me.
The architecture also depends a lot on the situation if your are a solo dev, a small group or a larger group. Each situation has different challenges, and what works conveniently for a solo dev could cause misunderstandings and conflicts in a group.
Making a game would learn you so much programming skills compared to years of learning tutorials. Thomas seem to be having impressive programming skills
🧠
Don't tell him that, his ego is already big enough 😂
But yeah, I'm lucky to have him!
-M
True, but much of what he said here is a combo of formal school and work experience. Online tutorials can get you far, but a lot of the "boring, but essential" stuff is lacking. Have never heard "gather requirements" in a game-dev video before 😂 Not a bad thing though!
Awesomely special and useful video! Thank you so much for that! This is actually the topic literally NO ONE speaks about, and yet for a newbe like me who started building game from learning art and now am getting into Unity, it's a crucial topic.
How to structure your game, even how to create a folder structure for your Unity project? That's golden info, those questions have been nagging me for so long. Thank you, you're the best!
I'm interested in this topic, but don't feel I learned much in the video. It was quite an abstract and high-level description of the general principles. I'd love to see you guys do more like this, if you're into it, but would suggest illustrating each point with one or more specific, practical examples.
Still enjoyed the video, though - cheers.
Great video, would love to see more similar one, was very informative and feel like we got a lot from it.
I really like the more technical stuff and how you actually use design patters and architecture. I own the book you reference and was cool to see other people talking about i!
Great video. Even when i didn't fully understand some elements (like what static exactly meant) i still learned something. Also i realized why some tips you and other dev tubers give to new solo devs (such as when you were talking about rewriting code again i kinda realized that is one reason why people suggest to make prototype, demo and full game on separate builds and always start from scratch - one reason probably is because the dev should plan prototype and demo for smaller scale which the code should reflect - also when you were talking about designing game first my brain went into design docs - many times devs just suggest doing them for reasons such as "you can't remember everything" and "it makes it easier to handle the project" but i don't remember anyone mentioning how these design docs also help with coding - because if you already have ruled a mechanic to work in certain way then you should also know if you want to keep the code expandable or.... does the word "static" fit here now?). Really good video and i probably will need to rewatch this again after im done with my demo phase but before i start working on the actual full game.
Typically it's basically one of the two: proper/difficult/thorough extensible development vs easy slap-on development with a major/impassable roadblock. Pretty much always aim for the proper development, otherwise you ain't going far with that project, and most likely end up quitting, because everything is tangled and you'll feel your arms tied to do anything.
Everytime I see/hear about guild architect I get more excited. Gonna be buying it for me and a few friends on release!
Using Unity DOTS makes it even more easier to work on Module Based Development. Create a new project for a POC. It works? Copy-Paste the code as is into your base project and works out of the box. What i found useful is treating each game as a dedicated package to be pushed to the unity store, completely independent, and having a separate folder {POC} that uses the systems. Not recommended for starting with it, but it does make it easy to 'plug and play'
Super excited for this video thanks guys!
Great video as usual. Glad to see Thomas is ok!
5:04 We need a video on how to write tests!
Definitely more of an intermediate topic, but agreed. I am very lazy about writing unit-tests 😅 But maybe also discuss your approach to UI & gameplay testing.
Agree, UML Class and Sequence diagrams can be very useful in thinking through code design. Keep it quick and lightweight - google agile modeling tips. Formal diagram tools can be a pita; just sketches on a whiteboard, paper, or free drawing tools can be enough for anything an indie might need.
I find model diagrams to be more useful for databases & APIs than classes, but I agree that they're excellent for beginners. Can also be helpful for message/event-based systems, to graph out what data needs to be shared, and what should not be.
I'm not a fan of UML. First of all, it is made for OOP business logic and even there, the models barely survive first contact.
But i'm a fan of lightweight diagrams that describe how systems interact. Unitys references to other gameobjects makes it easy to build "everyone accesses everyone"-networks or as we call it in programming: spaghetticode.
@@sealsharp I'm not a huge UML fan either, but the issue you're describing is more about bad process. Before Agile infected everything, when we actually paid people to plan & maintain software projects, change management was part of the job. So updating the model & logic docs to be in-sync with any proposed/implemented changes was required for sign-off.
Whether those used UML or something less-formal or in-house, the main point was that anyone could review the docs and know for sure that that's how the live system works (or the proposed system under-test).
@@sealsharp And you can write spaghetti code in any system - that's a PEBKAC situation 😄
@@mandisaw Agile: from misunderstood to consulting abomination. ^_^
I think the original "agile" around self-managing teams has some value.
The whole business developed out of it with processes around not having a plan, i see why you call it "infected".
In reality, software is often developed after a contract is signed and a contract gets signed when delivery date, features and pricetag are all set. How you're gonna do that? Well, making a plan and it better be good.
Regarding the "use UML or no" question: As a solodev I really don't think they're that useful, but I think they can help communication when you're discussing architecture with your colleague coders. It also helps discussion when you're delegating responsibilities, and shows what modules require a more structural approach with interfaces for cross-module-communication, as two different programmers might be coding those modules.
They can also show if there's some undetected misunderstanding of game mechanics among devs. (that shouldn't be the reason to do an uml tho)
Those food plate icons look amazing! I hope you use them as a baseline for the UI.
This honestly makes me wish I was able to comprehend code so I could enact on the ideas I have rotting away right now.
Architecture spans beyond software.
It encompasses the entire pipeline-including art, design, and quality.
Interfaces also go beyond software.
They are standards for integrating pipeline parts to move a feature from concept to release.
Also, check out how experts like Juval Lowy, Carliss Baldwin, and David Parnas define modular architectures to avoid rewrites/refactors when requirements change.
I see this video was filmed before the last livestream, in which you confessed to Thomas's murder
only 17 months to decide which engine to use? i need to level up
I suggest Defold
Silence your inner self and just go Godot or Unity. Also, avoid Defold. (that was my inner possessiveness speaking)
@@ultimaxkom8728 how dare you
Someone finally just answered the question instead of 300 pages of unrelated childhood bullshit. You've done a service.
I'm a software developer, so this technical video was interesting for me
Guild Architect looking sick. :D
I agree but as a solo dev with a full time job you don't always have time to write perfect structured code. I've tried my best but still certain parts could use a refactor.
Concrete examples would be huge! Talking about it at a high level can sometimes be difficult to understand for me
architecture is always kinda hard. You plan too much and architect everything perfectly and you will end up wasting a lot of time and make things that could be very simple super complex and on the other hand if you make everything on the go and don't really plan you could end up having to rewrite a lot of code. I honestly like the quick and dirty approach to like be able to playtest an idea but I think this approach can bite you really hard if you don't find the right time to rewrite some systems. I recently did a game jam and I honestly like the game I came up with but to make something more out of I'd definitely need to rewrite a lot of systems as I went for the suuuper dirty approach for a lot of things. I think at that point I'd basically have to rewrite most of the game lol
my codebase is a tangle of hacked solutions and comments that say //todo refactor this
there are always more functionality and bugs to fix so going back to actually fix the code structure can feel like a tedious luxury unless the bug you are fixing pertains to the actual code structure
well I used to be all project structure and no game mechanic at all. Then I started to work on focusing on game mechanics. Then I tried to make commercial viable game, but failed. Then I wondered why I failed....A lot! We need something which could be visually representing our vision of the game, so we don't get demotivated too early. Then we could approach whatever we wanted to do. Some might want to start with front-end stuffs, some might want to back-end stuffs, some might want to work on assets. Everyong have their own comfortable workflow. The key is to make sure we have solid goals and something to make us stay motivated.
I strongly believe the motivation to do work that must do, but don't want to do, cannot be sourced from the work itself.
Balancing your life outside of the work, keeps you working.
In every game there is stuff that's not interesting that connects all the interesting parts together. But it needs doing, and if you can only work while you want to work, truth is, you'll never finish anything. So, managing to work on what you don't care about, isn't about learning to care about it (though you should slow down, take pride in it and polish it like your name was gonna be on it) nor is it about finding joy in it. Your feelings about working, can't be the factor that makes you work. Feelings change, work never does.
It's about having balance in other places in life, so when it's time to work on the hard stuff - You dive in each time. Dreadless and committed. Sitting with it until it's done, and then taking your free time to refuel and rest.
What kills people is often the dread, and you can't force yourself to love something you dread. Silence that, stop looking for a finish line or an exit, and just, sit with it. When you are calm and submitted to the work, do it for as long as you planned. Then stop, and live your life, knowing the same time tomorrow, you'll submit to the work again.
Most people struggle with where they are because they are focused on where they want to be. Unaware, the choice focus on the reward, keeps you from earning it.
Submission of your mind and desires into the moment you've committed yourself to, without struggle, and without paying attention to anything beyond that moment, helps you complete the task with pure focus and without the need for motivation or the desiring pain to want to be doing something else.
Like a cold shower, just stay in it. It's done when its done. And you'll feel better finishing than starting every time.
Motivation is unfortunately a trap. If you let it guide you, it will always guide you to nowhere.
@@honaleri I have to disagreed with you. First of all the motivation to work for me is NOT the fuel to push me to work on something but the level of interest in something which I have. I can work without motivation but I won't be able to stick with something if it's not interesting enough. We just have different approach in life, that's all.
@@dreamingacacia
That's exactly what I'm saying. Your level of interest can't be the thing deciding if you stick with something or not. Or in the end, you will stick with nothing.
It's not about the way you live your life, its about how the human mind works. In all passions and efforts, there are moments of lull and disinterest, and for most that's the end, nothing finishes. You asked why you failed.
This is probably why. And it will repeat, every time, if you rely on your interest to decide for you if you will follow through.
In the writing community, people who don't finish their books always stop at the same position, the moment they weren't excited anymore.
People in the art community, can't finish their drawings at the same moment, when the work outweighs the expressive fun.
People in the game design community, stop at the same point, when the amount of reward they can visual see as progresses, slows down too much, and they can't feel thrilled about all their updates.
They all suffer the same illness. Requiring their emotions to dictate their actions. In other words. Needing to feel interested in order to be motivated to finish.
The work can't be finished if its fueled by how interested you are. It can however be finished it its fueled by commitment.
tldr
Motivation = The level of interest.
They are identical forces.
@@honaleri that's why we have to disagreed. While I could understand some level of your perspective, I don't think you understand mine. What's the point in sticking with something you lost interests? I built my workflow around my nature and I'm perfectly fine with don't stick with stuffs which I no longer have fire. I have confidence that I could finish what I started, but that's still have to follow the rules that I made for myself. Like I said, it's a matter of different approach in life. Nothing is true, everything is permitted.
@@dreamingacacia
I understand your perspective perfectly. All things you or anyone ever do in life, will contain moments that are not interesting. Everyone meets those moments. The ones that only value a task in so far they enjoy ever moment of it, will never finish anything. The ones that value what they aim to, more so than every moment of the act of doing it, will survive the process into success. The people who fail, always fail the same way. For the same reasons.
I was just answering the question. Why you failed.
If your methods worked, you'd have a game. Correct? Perhaps I'm mistaken.
Regardless...
There is truth everywhere, but few are willing to seek it out. Fewer still know it when they find it. And even fewer will use it, once they know it.
The point in sticking with the things you lose interest in, is necessary to completing any task.
You'll not find any profession, or hobby that is always only interesting. If you let those hurtles stop you, ever direction you head will lead you back to nowhere. I pray you don't lose time to that endless circle. Many lose their whole life to it. And never finish anything they start...
And everyone's nature is mostly the same...that's the source from which I speak. Your nature demands interest, but no task will ever supply enough. Many people take the route you take, only those who leave it eventually,...make something in the end.
Good luck regardless.
Would love a talk from thomas about pathfinding for management games, or games where the pathfind map changes a lot in general, I know that usually everyone goes with A* but how do you plan your map? Specially if not a grid based
You might want to revisit the basis of A*, the why, not just the how. It's basically just a list of positions/nodes - the nodes don't have to be in a grid, and the list can be dynamic over time. You can have pathfinding that recalculates the nodes/map before doing the character movement, but it could get expensive if you're doing it too often (like every frame). But you can find a balance.
@@mandisaw The balance would be recalculating the nodes and connections whenever you build something new, but I cant visualize how I would position the nodes in 3d space :/
@@viniciusantonio2253 The nodes are just data, the pathfinding is just logic. You can make the data mean whatever you need it to - passable/not-passable, high cost/low cost, near/far, etc. Mapping the nodes used for pathfinding to real-world space can be a separate, one-time-only thing.
Maybe look up some tutorials on doing dynamic 2d procedurally-generated levels/mazes (e.g. for roguelikes). That would likely have similar logic around dynamic nodes & pathing.
@@mandisaw thanks man, I will check it out
Thanks for covering this topic.
-----
I spent unnecessary effort to prepare the code & architecture ; then I stop after I realize the game is scalable but not playable after few months.
(hide the pain 👍)
Only make the code extendable for the current project and its planned features. Dont try to make "clean extendable code" for an assumed later project. Its likely never going to be reused as is anyways, but rewritten or just reusing specific parts.
I also plan in several early prototypes that get rewritten latter. With the main project only build when all core mechanics where tested in seperate prototypes.
The worst enemy is complexity.
Thank you from Brasil
You guys are awesome! Thanks
What is a ‘klaus diagram’? Cannot figure out what this is…
It's a "class diagram", it shows how your different code classes are linked to eachother and what variables they store. -M
@@bitemegames oh thanks!!
Singletons is your best friend for data managers. So the NetController, UserDataController, etc. would be singletons
What documentation software are you using at 9:15?
Wiki.js -M
In your game, Guild Architect do you use a unity asset for the outline? Can you tell me which one? I've been searching for a good one for a long time.
Yes, we use the quibli shader, which has an anime-aesthethic: prf.hn/l/RlDJOqn
-M
Awesome video
dont bother drawing a detailed class diagram if you're a beginner - just draw some rectangles representing your modules and draw arrows showing how these modules communicate and reference each other, it'll be enough trust me
My first line of code would have been "hello world"😢
I am curious, which game is in the thumbnail ?
Not a real game unfortunately, (almost) all our thumbnails are using midjourney generated art, including this one.
The prompt for this specific one was: low poly 3d, castle construction site, birds eye view, fantasy medieval, game, crane, --ar 16:9
-M
I was wondering... why not name it Guild Master? If the name is not taken, go for it. Guild Master sounds so much cooler
It's taken. We wanted that name first as well. -M
Day 2 of asking for Melon-Pan tier list.
You never use a singleton in code except the service locator. Period.
I think most architectural experts would select design patterns to fit the scale of the project.
Wildly over-engineering a small project because you have a dogmatic objection to a particular pattern is not good design, at least in my opinion.
@@JackFoz454 Sorry, I can't think of any project size, which doesn't benefit from unit testing and is too small to use aprox. 200 loc for a service locator. It simply doesn't exist. On the contrary - a service locator is a pattern to speed up the development of smaller projects, as it makes reuse of components a breeze. I stay to my statement - there is no justication of a singleton except the service locator. Nothing dogmatic about it, it is pragmatic. Period.
@@SunSailor If the singleton pattern has no benefit for small and beginner projects, why do you think it's so ubiquitous in small and beginner projects?
If your solution really were objectively better in all circumstances, would it not proliferate accordingly?
@@JackFoz454 Because people don‘t know it better. Don‘t see any real argument in your post. There is no justifiable reason to use a singleton not managed by a service locator. If you don’t understand that, your skills are not developed enough to understand. Doesn’t make the singleton right. Continue learning, and you may understand, rookie.
@@SunSailor I'll ignore the weird personal attack, but feel free to reflect on what it says about the strength of your own argument.
My argument is that singletons are widespread in small and beginner projects because they are simple and effective in small and beginner projects.
You claim that your alternative is objectively better, and the only reason it hasn't caught on is that the rest of the software world is not as clever as you. Good luck with that.
Honestly have never seen a video with as much bad advice in it as this one. You would make a better game faster if you did the exact opposite of what they say.
Any examples? How would you make it better? They give pretty common advice, so it'd be interesting to hear what you would give as advice.
@@sataStrike Why are you questioning him, and not just taking his word for the gospel that it is! How dareth thee. /s
omg gays unsub