We usually refer to the scene you are describing as a "Metrics Gym" and you are completely correct that it's a great habit to create these as early as possible. Keep up the great content!
Tim at 1:26, On the projects I worked on we called them Environment metrics map. Thighs like partial / full player cover height, exact step placements for a ladder, monster closet vent size - because monster animations were already baked for a set amount of space volume. Max jump height as was mentioned, anything that involved backed animations and all level design rules are defined on these blockmesh / whitebox or grey box.. so many names haha, would typically be setup in pre-production by the lead designers, animators and artists and then used as a reference bible by the production team. I worked as a environment artist so I always checked my work against these levels to ensure items listed above were correctly scaled. Most of the time id just ask a designer since they had all those values memorized. I know this video is a year old but just want to say I love watching your content, been around since the PS2 era so quite nostalgic for me to hear your old dev stories :) Thank you for sharing them!
This is gold. I’m a software engineer in tech and I’m comfortable building general software. But with game dev, I wasn’t sure what process to follow. Hearing about the “units room” and different ways of isolating functionality/constraints was super helpful. It was also nice to hear about reset/save/load. I saw some similar logic in the Doom 3 source code.
Great video! It instantly made me think of an interview with Sam Lake, him being asked what his favourite game mechanic is. And his answer was that simply moving through a fictional world is the most basic AND most exciting mechanic of them all. And I also think, there's still so much to explore.
i absolutely love this so much as a solo indie dev. i can do most tasks from coding to art myself, but the way you explain things gives me such a strong framework for a development cycle
On the opening introduction it sounds more like coding lifecycle stages than organizing game code. 🤷 The rooms I think Tim was trying to describe in games which are for testing are called "dev rooms".
Thanks for sharing these stories and insights. I feel like I've been binge watching your channel for a week now. It's great having you pass all this knowledge down.
I appreciate stuff like this. I've always wanted to do game dev, but I don't live in an area where there's lots of those opportunities, so that's just not the direction my career went. Videos like this gives me a slightly better picture of how things go and what to expect if I ever do make that jump (especially now that remote work is a thing, and I'm older and could actually afford to move).
I really need to start my videos later in the morning. The sun is rising later every day, and I don't like how things look with my ring light. This video was shot using only the light from my monitor.
I don't do any kind of game development, but I love learning about it due to the technical and design challenges it poses! Your videos are incredibly insightful and digestible
Speaking of "don't start coding until enough design is created" I am now curious about an opinion on development methodologies, from someone more structured to something more agile...
I believe there is a balance between those two. Agile methodologies apply to more minimum viable plans when you are not sure how things work and trying to do something creative. That's when you want to see how things work, what should be kept or cut, etc. If you already know how everything works from the start, then development can go with more sophisticated and feature complete design.
Agile in RL is just a buzzword serving those who cannot code to keep their jobs by spewing buzzwords. The design of this guy here is highly agile while maintaining the amount of structure needed. Like with all things the right dose makes the poison.
Moleneux/bullfrog/bedroom coder method is the opposite. You start with a small prototype and iterate design through gameplay, there is no fixed code - almost everything will be thrown out and rewritten at least once. Once the flow is there - then you put it to a design doc of some sort and walk from there.
This is exactly the kind of content I am looking for from someone with your knowledge and experience. Thanks a bunch and I look forward to more technical videos in the future. It is so extremely helpful to get this kind of insight into an industry that is usually so secretive.
You are one amazing man, Tim. Thanks for these daily videos. From reading the comments section here, you mean as much to me as you mean to them! I salute you, Sir! o7 Have a great day! And God Bless.
I deal with serializing exactly the same way. I eventually changed objects to use a single function for streaming. Nearly every data type in my engine supports streaming with the single function, apart from POD types. It looks something like void Stream(file &io) { io.TX(&a); io.TX( &b ); io.TX( &c ); }, where the templated TX() function saves or loads generic types, depending on which mode the file was opened in. If TX() is called on something other than a POD type, the system automatically redirects to its object.Stream(io). It has worked pretty well for me. Some types are definitely easier to serialize than others, but it helps tremendously to break it down and have every data object deal with its own streaming.
Oh yeah, Ratchet & Clank 2 had the Insomniac Museum as a hidden area to go to. It included lots of voice overs of the developers, unused assets, etc. It also had a playground with a gridded surface, different heights for jumping limits, slopes for sliding limits, etc. Pretty much a testbed or concept area for the movement at least.
11:00 That set of 5 function names is helpful. I've made a few game demos, but never thought to structure things that way. Thanks for sharing. -- Edit: I disagree with keeping functions short for the sake of keeping them short.
About your edit: it's called clean coding. It's much better to write 4 functions with 20 lines of code than a big ass function with 300 lines and several code sections that are literally copypasted. If you are not the only one who is working with such code, you are making your work mates job harder, introducing technical debt and actually costing money to the company you work with. That's the reasoning behind making functions as short and simple as possible. If you want more info about clean coding, i'd suggest you the book from Robert Cecil Martin "Clean Code: A Handbook of Agile Software Craftsmanship". Best regards
@@richmindbcn there is a lot of room between 4 functions of 20 lines and 1 function with spaghetti code. In my amateurish opinion, functions should be broken according to... well... functions. Not size. And in case you're working in a team, a particular near-atomic functionality should not be assigned to more than one person anyway, so there shouldn't ideally be a situation where more than one person is working on the same function.
@@sen7826 after 10 years working in the sowtware development industry, i'm going to give you my honest perspective : - You are right about functions being broken to functions. But, in the analysis phase, you will break a bigger function into smaller parts, not for the sake of being short, but for the sake of being maintainable. Smaller functions have less use cases to test. And it's easier to find bugs on shorter code. - Then you have quality indicators. Many companies have tools to measure code quality (e.g. Sonarqube). You may have size constraints such as functions not being longer than 100 lines or classes not being longer than 2000 lines, and you have to adapt to those constraints, or your commited code might be rejected until it meets those constraints. - And finally, i want to mention workload distribution. Tasks (like developing a new functionality or fixing a bug) use to be assigned by priority and availability. There might be a possibility of finding a bug in that code and the original developer is not available (or even not in the company anymore). Yes, only one person is going to maintain that part of the code (you are right about that), but that doesn't mean it's going to be the same person for the whole life of that application. And i could even add the fact that many companies externalize their IT needs into sowftware dev companies, hiring them for 2 years then hiring a different company for another 2 years, rinse and repeat. Hell, i remember having to modify some mainframe code written in the early 70's. TLDR: you are mostly right, but it's not always that simple.
Currently mocking up a neighborhood. To test distances, scale and the like. Thanks for confirming I'm not just "making work." BTW, really like the positive attitude you bring to these discussions.
I've been sporadically watching your videos for a few weeks and I've found them extremely useful for the RPG I'm working on, especially the more practical ones like the dialogue or loot table videos. I know you probably have a massive backlog of ideas but I'd love to see more like them! I don't usually comment but I had to when I heard you talk about the Init/Reset/Exit/Load/Save functions. I have the exact equivalents of those 5 functions in my core classes as well. I liked to think I came up with this setup on my own but now I'm realising that this is most likely another one of those situations where as programmers, despite differing coding styles, we tend to converge towards certain patterns... And as a programmer, patterns make me happy. Thanks, Tim, you made my night :) Since I'm here and talking about patterns. I might have a question for you. Have you ever heard of a book called "Design Patterns" by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides? If so, have you used any of those patterns in your games? If yes, which ones and for what purpose?
I only recently came across your channel but I've been really enjoying these videos. I'm a non-game developer but it is interesting to hear the parallels and differences with non-game development. As a follow up or related video it would be cool to hear about the testing strategies and even the tools such as source control, CI tools etc. used within the games industry for coding, things like unit tests, integration tests and when and how QA comes into it. Thanks again for the great videos and take care!
Ooooooooooooh! My favorite topic thank you! Learning code architecture and applying designs to code there are many many nuances in between. Reset is the exact solution for some issues in object pooling technic for recycling instantiated objects in runtime. Good reminder thank you very much :)
Love it! Especially the end - realizing I could break methods up completely changed programming for me. Also, not sure what kind of camera you have, but I know many of them have power bricks that you can buy for AC power. They're basically a battery with a cable attached to it.
Time - what I think would be something interesting to see, would be : - stories publishers presentations - stories about why publishers accepted/rejected certain projects - how publishers and publisher hierarchies have changes from the past to the present
In some of the companies we had levels for testing as well, we called them playgrounds or gyms. It is much easier to go there, fast load because there is not that much to load, fast test because everything you need is nearby. Also, method sizes around a screen are ideal. Too short and they clutter the code, too long and you get lost inside them. I try to keep them about that size, but it's not always possible. Specific methods like getters and setters are excluded.
Init, Exit, Rester, Save/Load - hmmm Much more often we can see that the system of saving and loading is done through a destructor/constructor in a complicated way) It's funny, but it sounds VERY logical in the context of "making video games" and partially contradicts the OOP design of the program. I like the ECS concept (entities+components+ systems) - as part of it, you can create a separate "system" for saving data for each of the main systems. And for "entities" to specify, it is enough to specify a "flag" - to need to save or not. Ultimately, any program is just a collection of data. And OOP is just a recommendation...
Hi Tim, you just mentioned the difference between props and ground-clutter in passing. Could you one day talk more about the process of finding sensible categories like that for all of the assets that one can expect in an rpg? Cheers!
Hello Tim, thanks for these great videos. How do you know when to give up on a project? I’ve had couple abandoned project and sometimes I wonder if I had continued them I would’ve made something great.
Hey Tim! Quick question! Something that blew me away a couple years back was when Ron Gilbert was talking about CI/CD principals and unit tests on his GrumpyGamer page. These topics rarely get brought up in game development, but someone such as myself, a programmer in the fintech world, deals with these concepts all the time. It always piques my interests when the worlds of corptech and game dev sort of blur lines. I also recall John Carmack and others talking about static code analysis, code reviews, paired programming, and other topics that we see in the corptech world quite a bit in the past few years. I'm guessing these have been getting more and more prevalent in the game dev world. What is your opinion on these more "corporate" tools and ideologies being used in the game development world?
This is sound advice! I like the early init trick to minimize fragmentation! Was it tricky to use this paradigm in really huge games like Arcanum with only a small subset of the world being in memory at any time? What collections of object types (UI, quest system related, etc) stayed always in memory until the player exited the game? Thanks again for this excellent technical video! Have a great day 😊
Tim, have you watched Westworld? I feel like the show, similarly to the movie Inception, deals subtly with philosophical questions tied to game design and I'd love to hear you take on the show.
You're "single screen function" is the same method my brother uses for our game. In school they teach it as your functions having "high cohesion" and "low coupling" or in laymans terms. Functions should do ONE thing. If you try to describe your function and the world "AND" escapes your lips. Too complicated, that needs to be it's own function. Your function should only know about the things it NEEDS to in order to do its' job. If your function adds two numbers together. Then only allow it to take two numbers. Don't go passing objects that contain the numbers it needs. One thing I do with newer coders is I teach em how to unit test early. Cause writing a gigantic function is easy. Testing it is hard and they will naturallly break it up to not have to write the crazy tests it would take to test it.
Hi Tim. Could you give some experience feedback about the code architecture or methodologies you like to use? Not game engines like Gogot or Unity but instead ECS, Events, abstractions... Thanks a lot for your feedback and thanks for the games.
Hi Tim, I was wondering if there's any design pillars (kinda like your "a typical Obsidian game" where it's almost a given) that you try to have for every game you're developing?
Do you have any tips on a professor developer learning art or finding someone to help with the art for a indie game? I can handle and love all the technical stuff but a lot of game development is art not code.
I disagree with reset method as an idea for 99.99 percent of things. It is too hard to guarantee statically all states of obj would be reset after month and month of iterations and extensions on big code base, and failing to do so would generate too many bugs. Just destroy actor and spawn new onw.
More! More on practical game design and coding, please.
Yes, please!!
Seconded!
Yes, please, it's great to hear about the coding aspects. Love to know about how a save file works.
I agree!!!! The simple things like this are so awesome to hear about!
Fifthed! This is great, very useful stuff.
Talking about practical game design, coding, architecture, even if just a little bit, it's always a blessing!
We usually refer to the scene you are describing as a "Metrics Gym" and you are completely correct that it's a great habit to create these as early as possible.
Keep up the great content!
This channel is gold. I don't even want to be a developer, but this nuts and bolts stuff is fascinating.
And the war stories are great too.
yupp. A wonderful pragmatic.
Tim at 1:26, On the projects I worked on we called them Environment metrics map. Thighs like partial / full player cover height, exact step placements for a ladder, monster closet vent size - because monster animations were already baked for a set amount of space volume. Max jump height as was mentioned, anything that involved backed animations and all level design rules
are defined on these blockmesh / whitebox or grey box.. so many names haha, would typically be setup in pre-production by the lead designers, animators and artists and then used as a reference bible by the production team. I worked as a environment artist so I always checked my work against these levels to ensure items listed above were correctly scaled. Most of the time id just ask a designer since they had all those values memorized.
I know this video is a year old but just want to say I love watching your content, been around since the PS2 era so quite nostalgic for me to hear your old dev stories :) Thank you for sharing them!
This is gold. I’m a software engineer in tech and I’m comfortable building general software. But with game dev, I wasn’t sure what process to follow. Hearing about the “units room” and different ways of isolating functionality/constraints was super helpful. It was also nice to hear about reset/save/load. I saw some similar logic in the Doom 3 source code.
I have a feeling that this video will help a whole lot of non-programmers communicate *much* better with their programmer teammates!
Great video! It instantly made me think of an interview with Sam Lake, him being asked what his favourite game mechanic is. And his answer was that simply moving through a fictional world is the most basic AND most exciting mechanic of them all. And I also think, there's still so much to explore.
Thanks Tim! I grew up on your games and getting advice from you today just fills me with joy.
i absolutely love this so much as a solo indie dev. i can do most tasks from coding to art myself, but the way you explain things gives me such a strong framework for a development cycle
Yes! Always a joy listen to Tim with my cup of coffee! Perfect timing ah!
On the opening introduction it sounds more like coding lifecycle stages than organizing game code. 🤷
The rooms I think Tim was trying to describe in games which are for testing are called "dev rooms".
I don't do coding but I love game design videos of all types. Very interesting stuff!
Thanks for sharing these stories and insights. I feel like I've been binge watching your channel for a week now. It's great having you pass all this knowledge down.
So glad you started making videos, we need more knowledge and guidance from people like you 🙏 thanks boss!
I appreciate stuff like this. I've always wanted to do game dev, but I don't live in an area where there's lots of those opportunities, so that's just not the direction my career went. Videos like this gives me a slightly better picture of how things go and what to expect if I ever do make that jump (especially now that remote work is a thing, and I'm older and could actually afford to move).
then get started today, it's not an easy industry to get in on, even at an indie level
Tim addresses us from the void, part 67
I really need to start my videos later in the morning. The sun is rising later every day, and I don't like how things look with my ring light. This video was shot using only the light from my monitor.
@@CainOnGameseven if it was pitch black I’d listen to you talk about games
damn I assumed these were being recorded at night, not the early morning 💀 @@CainOnGames
@@CainOnGames We understand, shoot the videos whenever you want, the content and what you say matters, not the visuals.
I don't do any kind of game development, but I love learning about it due to the technical and design challenges it poses! Your videos are incredibly insightful and digestible
Speaking of "don't start coding until enough design is created" I am now curious about an opinion on development methodologies, from someone more structured to something more agile...
I believe there is a balance between those two. Agile methodologies apply to more minimum viable plans when you are not sure how things work and trying to do something creative. That's when you want to see how things work, what should be kept or cut, etc. If you already know how everything works from the start, then development can go with more sophisticated and feature complete design.
Agile in RL is just a buzzword serving those who cannot code to keep their jobs by spewing buzzwords. The design of this guy here is highly agile while maintaining the amount of structure needed. Like with all things the right dose makes the poison.
Moleneux/bullfrog/bedroom coder method is the opposite. You start with a small prototype and iterate design through gameplay, there is no fixed code - almost everything will be thrown out and rewritten at least once. Once the flow is there - then you put it to a design doc of some sort and walk from there.
This is exactly the kind of content I am looking for from someone with your knowledge and experience. Thanks a bunch and I look forward to more technical videos in the future. It is so extremely helpful to get this kind of insight into an industry that is usually so secretive.
You are one amazing man, Tim. Thanks for these daily videos. From reading the comments section here, you mean as much to me as you mean to them! I salute you, Sir! o7
Have a great day! And God Bless.
I deal with serializing exactly the same way. I eventually changed objects to use a single function for streaming. Nearly every data type in my engine supports streaming with the single function, apart from POD types. It looks something like void Stream(file &io) { io.TX(&a); io.TX( &b ); io.TX( &c ); }, where the templated TX() function saves or loads generic types, depending on which mode the file was opened in. If TX() is called on something other than a POD type, the system automatically redirects to its object.Stream(io). It has worked pretty well for me. Some types are definitely easier to serialize than others, but it helps tremendously to break it down and have every data object deal with its own streaming.
Oh yeah, Ratchet & Clank 2 had the Insomniac Museum as a hidden area to go to. It included lots of voice overs of the developers, unused assets, etc. It also had a playground with a gridded surface, different heights for jumping limits, slopes for sliding limits, etc. Pretty much a testbed or concept area for the movement at least.
11:00 That set of 5 function names is helpful. I've made a few game demos, but never thought to structure things that way. Thanks for sharing.
-- Edit: I disagree with keeping functions short for the sake of keeping them short.
About your edit: it's called clean coding. It's much better to write 4 functions with 20 lines of code than a big ass function with 300 lines and several code sections that are literally copypasted. If you are not the only one who is working with such code, you are making your work mates job harder, introducing technical debt and actually costing money to the company you work with. That's the reasoning behind making functions as short and simple as possible. If you want more info about clean coding, i'd suggest you the book from Robert Cecil Martin "Clean Code: A Handbook of Agile Software Craftsmanship".
Best regards
@@richmindbcn there is a lot of room between 4 functions of 20 lines and 1 function with spaghetti code.
In my amateurish opinion, functions should be broken according to... well... functions. Not size. And in case you're working in a team, a particular near-atomic functionality should not be assigned to more than one person anyway, so there shouldn't ideally be a situation where more than one person is working on the same function.
@@sen7826 after 10 years working in the sowtware development industry, i'm going to give you my honest perspective :
- You are right about functions being broken to functions. But, in the analysis phase, you will break a bigger function into smaller parts, not for the sake of being short, but for the sake of being maintainable. Smaller functions have less use cases to test. And it's easier to find bugs on shorter code.
- Then you have quality indicators. Many companies have tools to measure code quality (e.g. Sonarqube). You may have size constraints such as functions not being longer than 100 lines or classes not being longer than 2000 lines, and you have to adapt to those constraints, or your commited code might be rejected until it meets those constraints.
- And finally, i want to mention workload distribution. Tasks (like developing a new functionality or fixing a bug) use to be assigned by priority and availability. There might be a possibility of finding a bug in that code and the original developer is not available (or even not in the company anymore). Yes, only one person is going to maintain that part of the code (you are right about that), but that doesn't mean it's going to be the same person for the whole life of that application. And i could even add the fact that many companies externalize their IT needs into sowftware dev companies, hiring them for 2 years then hiring a different company for another 2 years, rinse and repeat. Hell, i remember having to modify some mainframe code written in the early 70's.
TLDR: you are mostly right, but it's not always that simple.
Mr Cain, this video is pure gold!
Currently mocking up a neighborhood. To test distances, scale and the like. Thanks for confirming I'm not just "making work." BTW, really like the positive attitude you bring to these discussions.
I've been sporadically watching your videos for a few weeks and I've found them extremely useful for the RPG I'm working on, especially the more practical ones like the dialogue or loot table videos. I know you probably have a massive backlog of ideas but I'd love to see more like them!
I don't usually comment but I had to when I heard you talk about the Init/Reset/Exit/Load/Save functions. I have the exact equivalents of those 5 functions in my core classes as well. I liked to think I came up with this setup on my own but now I'm realising that this is most likely another one of those situations where as programmers, despite differing coding styles, we tend to converge towards certain patterns... And as a programmer, patterns make me happy. Thanks, Tim, you made my night :)
Since I'm here and talking about patterns. I might have a question for you. Have you ever heard of a book called "Design Patterns" by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides? If so, have you used any of those patterns in your games? If yes, which ones and for what purpose?
I only recently came across your channel but I've been really enjoying these videos. I'm a non-game developer but it is interesting to hear the parallels and differences with non-game development. As a follow up or related video it would be cool to hear about the testing strategies and even the tools such as source control, CI tools etc. used within the games industry for coding, things like unit tests, integration tests and when and how QA comes into it. Thanks again for the great videos and take care!
Ive just discover this channel and I love it. Thank you for sharing your knowledge
What an absolute legend you are, Tim!
Ooooooooooooh! My favorite topic thank you! Learning code architecture and applying designs to code there are many many nuances in between.
Reset is the exact solution for some issues in object pooling technic for recycling instantiated objects in runtime. Good reminder thank you very much :)
Thanks Tim your videos always help so much and are incredibly compelling.
Love it! Especially the end - realizing I could break methods up completely changed programming for me.
Also, not sure what kind of camera you have, but I know many of them have power bricks that you can buy for AC power. They're basically a battery with a cable attached to it.
Woh, this is exactly the situation I'm in right now. Making a simple design doc to use as a fallback when I start developing code
Wow this is so interesting and helpful I’m super happy you have decided to create this channel :)
Time - what I think would be something interesting to see, would be :
- stories publishers presentations
- stories about why publishers accepted/rejected certain projects
- how publishers and publisher hierarchies have changes from the past to the present
Great stuff as always Tim, thankyou!
love the rotating shelf light!
In some of the companies we had levels for testing as well, we called them playgrounds or gyms. It is much easier to go there, fast load because there is not that much to load, fast test because everything you need is nearby.
Also, method sizes around a screen are ideal. Too short and they clutter the code, too long and you get lost inside them. I try to keep them about that size, but it's not always possible. Specific methods like getters and setters are excluded.
Thanks for sharing so much insight, very helpful as a solo dev
Me, on my two 10k-line files: absolutely agreed :)
Great advise on load/save, I will try that on my next game.
Init, Exit, Rester, Save/Load - hmmm
Much more often we can see that the system of saving and loading is done through a destructor/constructor in a complicated way)
It's funny, but it sounds VERY logical in the context of "making video games" and partially contradicts the OOP design of the program. I like the ECS concept (entities+components+ systems) - as part of it, you can create a separate "system" for saving data for each of the main systems. And for "entities" to specify, it is enough to specify a "flag" - to need to save or not.
Ultimately, any program is just a collection of data. And OOP is just a recommendation...
Got it. Design, work down code and wait for my battery/pc to give up.
Hi Tim, you just mentioned the difference between props and ground-clutter in passing. Could you one day talk more about the process of finding sensible categories like that for all of the assets that one can expect in an rpg? Cheers!
This video was especially valuable for me, thank you!
Another splendid video
thank you from Brasil, your videos are great
Awesome! Thank you, Tim!
Thanks for this I really helped me get started.
Nice, but if I had one absolutely critical advice that could make the life of every coders a billion times easier it would b-
*DEAD BATTERY*
Pretty sure it was the effect of a nullptr exception :D
Listening to this I feel a lot less silly when I'm making a wall of min/max variables in my code lol
Hello Tim, thanks for these great videos. How do you know when to give up on a project? I’ve had couple abandoned project and sometimes I wonder if I had continued them I would’ve made something great.
Hey Tim! Quick question! Something that blew me away a couple years back was when Ron Gilbert was talking about CI/CD principals and unit tests on his GrumpyGamer page. These topics rarely get brought up in game development, but someone such as myself, a programmer in the fintech world, deals with these concepts all the time. It always piques my interests when the worlds of corptech and game dev sort of blur lines. I also recall John Carmack and others talking about static code analysis, code reviews, paired programming, and other topics that we see in the corptech world quite a bit in the past few years. I'm guessing these have been getting more and more prevalent in the game dev world. What is your opinion on these more "corporate" tools and ideologies being used in the game development world?
Your content is amazing
Where can I learn more about standard practice?
This is sound advice!
I like the early init trick to minimize fragmentation! Was it tricky to use this paradigm in really huge games like Arcanum with only a small subset of the world being in memory at any time? What collections of object types (UI, quest system related, etc) stayed always in memory until the player exited the game?
Thanks again for this excellent technical video! Have a great day 😊
I might get super into a game here soon
Good afternoon, Tim :)
Please make a course on game dev. Level deisgn. Story design and programming aspect
Tim, have you watched Westworld? I feel like the show, similarly to the movie Inception, deals subtly with philosophical questions tied to game design and I'd love to hear you take on the show.
You're "single screen function" is the same method my brother uses for our game. In school they teach it as your functions having "high cohesion" and "low coupling" or in laymans terms. Functions should do ONE thing. If you try to describe your function and the world "AND" escapes your lips. Too complicated, that needs to be it's own function. Your function should only know about the things it NEEDS to in order to do its' job. If your function adds two numbers together. Then only allow it to take two numbers. Don't go passing objects that contain the numbers it needs.
One thing I do with newer coders is I teach em how to unit test early. Cause writing a gigantic function is easy. Testing it is hard and they will naturallly break it up to not have to write the crazy tests it would take to test it.
modern engines are a blessing 😢
Man these videos are interesting.
Good morning Tim 🙂
good stuff
Hi Tim. Could you give some experience feedback about the code architecture or methodologies you like to use? Not game engines like Gogot or Unity but instead ECS, Events, abstractions... Thanks a lot for your feedback and thanks for the games.
I'm curious if you have any experience in regards to Story Bibles related to your work
Hi Tim, I was wondering if there's any design pillars (kinda like your "a typical Obsidian game" where it's almost a given) that you try to have for every game you're developing?
Do you have any tips on a professor developer learning art or finding someone to help with the art for a indie game? I can handle and love all the technical stuff but a lot of game development is art not code.
What are some of your most memorable experiences as a consultant?
Thanks Tim
Clearly you need to be booked for consultation by most of the industry
Sounds like unit testing. So the Unit Level?
How much / what kind of math is required to code the games you did?
I disagree with reset method as an idea for 99.99 percent of things. It is too hard to guarantee statically all states of obj would be reset after month and month of iterations and extensions on big code base, and failing to do so would generate too many bugs.
Just destroy actor and spawn new onw.
Don't break up your code!, agreed with everything else.
can you please be my dad?