Thank you for replying my question. Your experience shows how that should be done. The way you described it, with can_equip() method, also allows for example, easily implement highlighting items which are equippable to some particular slot, maybe when player mouse over the gear slot.
Yea separating the mechanics and UI is a really great point too, I'm glad he touched on it. That kind of functional compartmentalization is what often gets overlooked by programmers of all stripes.
Brilliant. Hadn't thought of breaking return codes into their own "Can" methods, or even reusing Inventory components across NPCs, chests, etc. Thanks as always, Tim!
Glad having checks and actions for inventory is basically what I did for my inventory code, but also having to branch out for each type of item like stackable or not, etc. Also these technical talks are just as great as wig story talks lol
You talked about the inventory system having its own clean API for use of mostly the UI. Around how many of these would you create, like would you make one for each mechanic in the game or like this whole thing is the combat API?
Multiple, in both directions. Meaning one mechanic, say inventory, might have multiple UI’s, like looting, bartering, and personal inventory. But some UI’s, especially the HUD, might pull from multiple different mechanic API’s, like combat, attributes, and status effects.
Excellent video. I am not a game developer, but your explanation for this type of system might help me in designing a tool I want to build. Getting design tips from someone with so much experience and avoiding pitfalls is appreciated and insightful 😄
Hi Tim, been waiting for a video on this for a while. Thanks so much! This is a rather vague question but could you talk at all about your thoughts on VR, perhaps AR also and just video gaming beyond the traditional medium that we have known it as. Do you see any future potential, for example ideas you had in the past that might now be more viable with certain additional freedoms allowed in something like VR. Thanks!
Not sure how it works for asking questions, so I'll try here in a post. I'd like your opinion on RPGs with no combat. - Were you ever interested in doing a game like that? - If so, or maybe if you just contemplated the idea after playing a title of that kind, what were your (proto?) ideas for ways to substitute combat? (I'm thinking Disco Elysium, basically, which was a great game for me, even when considering only its RPG mechanics. With its use of ideas and personalities connected to traits and bonuses, and also the best amnesiac protagonist I've ever played, 100% integral to the story and to everything you do throughout its development. Only thing I didn't like too much of that game is the use of clothing/accessories to add and remove bonuses. I see it's used together with leveling in order to repeat rolls, so it's a mechanic that might have been somewhat of a necessity, in order to allow the player to enjoy all those wonderful failure scenarios without save-scumming. But it still caused a bit of immersion breaking while playing the game, with my guy changing cloths in front of NPCs before starting a dialogue with them: a very minor complain, when nothing is perfect and there's always room for improvement.) Thanks for your videos!
Hi Tim! Thanks for these videos. I once dipped my toes into the video game industry as a tester and I was wondering what sort of testing tools you have had in your games, tools that let you complete quests instantly or change factions' reactions to your character etc.
Hi Tim, Question related to timing and hiring people. My team and I are currently in the works for our next project and one thing our team needs is a 3D Artst / Modeler. What's your advice / experience on when you should begin the hiring process for a developer position for a position your team currently doesn't have, compared to when the project actual starts, my biggest fear is hiring said person and then them waiting to have work - but at the same time it would be terrible to be ready and be in the middle of hiring said position. Keep up the amazing content as always!
It makes for a nice clean design to use the Observer pattern between the game logic and the UI, Sound, Music, etc. You send off events like dealing damage, gaining mana, etc. and the Sound, Animation etc. subsystems just listen for events they care about and play the Sound, Animation, etc. as appropriate. The game logic itself essentially runs headless.
Question, what are your thoughts on unofficial Fallout games? PC gamer just had an article that featured 5 brand new Fallout games being made by fans based of the Fallout 4 engine. Have you played any of the older fan made Fallout games?
Hi Tim! Sorry I've asked this before and perhaps you chose not to answer it, but it's somewhat related to this video so I thought I'd ask again in case it got missed. When designing the system for items so that many items can be made, it'd be interesting to know how you would/have divided up the item that appears in your inventory, versus the item that appears on the floor (in some games) that you can collect, versus the effect the item has when you use it (if you can) and as a sub-point of the last one, how equipment or ammo fit in to that picture. I feel like it must take quite a lot of planning to make new items easy to create and implement easily.
In that inventory example: its important to have gamedesign define what the inventory must do, and what it will not do. Defining that early on. Else things like "lets make it a grid" or "we should add stacks" can add ugly hacks or require a whole redesign of the code.
Hei, when you said do not couple the inventory and how the menu display I could not agree more. At work I have a "high ranking" that insist on coupling everything because that's how it has always done, and this really effects the quality and the cleanliness of the code I can produce. Do you have any tips to muster through things like this without loosing all motivation for the project? Its a project I have been working on for a few years, and loosing motivation.
Tim, the OOP Guy :D Seriously, there are so many programers today who only know how to write the stuff as is with the reason being "because I need it here now". This video demonstrates that dividing responsibility is important. Thank you, maybe now some devs will ask themselves "does this thing even care about the other thing" more often and write less mangled spaghettios.
I'm not the OOP guy, but even I would most likely separate ui and inventory. Because those are two separate parts of the game. I'm not sure tho, that stalker/tarkov-like UI should be unaware of its visual representation. Because it's kind of crucial for it to be able to fit an x*y sized item AND be an x*y grid with fixed dimensions.
@@zhulikkulik inventory system is aware of sizes/weights etc, but it doesnt use that info. UI on the other hand does use that info but is unaware of how the actual object is stored. UI may impose its own rules (like grid size, amount limits etc) but it does not "store" the item itself. At least that's how I understood Tim's main idea.
Hey Tim, great video as always. I would love to hear your thoughts/opinions on Tutorials on RPGs. Are there different types of it? How does one implement a good tutorial for the genre?
I have a question about establishing a story. Obviously the initial idea will probably start with a setting, but what is the process from there? Do you come up with the beginning and ending and fill in the gaps? Does the story influence the game areas and/or vice versa?
Can you make a tutorial about this topic in particular but for the whole game and dive deeper into the technical stuff? How to make the code maintainable, readable and scalable while still being performant and all...
Hey Tim, have you been doing some shader/particles programming? What's the best place for someone to start learning about it? How do you decide about using one and do you take existing functions/shaders or write it yourself? Cheers and thanks for videos.
Hey Tim, love the videos. Constructive criticism: I think you need to have the mic closer to your mouth, we can hear that the levels have been over boosted and sound a bit clipped.
Hey Tim, I currently work in the industry as a gameplay programmer generalist and I know I'm very good at my job(this is based off others telling me) but I always wanted to do game design roles and I work with designers everyday and actively suggest designs that work well in the game(and end up getting added). When interviewing for game design positions the first thing the recruiter tells me is that on paper I don't qualify as a designer on paper(from my job experience) so they really wanted to talk with me about a gameplay programming position. I have been making portfolio projects and I do get interviews for design positions but always get suggested to be a gameplay programmer instead because they need that more urgently. What do you recommend I should try to do in regards to moving into design positions?
man, maybe you should just do it? It's an unfortunate reality but programmers, specially good ones, are rare. Designers are a dime a dozen so the value a good designer has is woefully underappreciated.
Hi Tim, what ways would you personally recommend for effectively disseminating different types of information in the workplace? Love your work and the videos.
That's a strange separation of concerns - if you have a sword that requires level 12 to use, and the player's just lvl 10, then it's the inventory's job to reject adding that sword, however, if the sword is 4x1 tile sized, and you don't have a 4 tile consecutive free spot on the grid, that's a UI concern?
Hi, Tim. I recently watched the Interview with Alper Çağlar you did a few months ago. I really wanted to know something you've mentioned there you didn't know what were you doing the space between Fallout 1 and Fallout 2 did you find anything since then?
So with grid based inventory there is no validation in inventory mechanics system if two items overlap (despite that data being saved). It is only validated in UI code. Why? I can already see inventory UI bugs polluting saves with multiple items taking same space.
You can decide whether the grid and its restrictions are part of the UI or the mechanics, and that will determine where those checks go. You can easily have a CanAddItemUI() method too that checks to see if the item can fit into the grid.
Appreciate the episode but it's way too technical for me to comprehend. Being an artist and not a coder, I will need some visuals to help explain majority of the coding aspects.
I wish I could describe these systems declaratively using constraints. I want my UI APIs to be like database queries, they don't need to run every frame, just when data changes. I read an interesting paper "out of the tar pit" that talks about something like this.
As someone who has written more than one complex inventory system, I definitely like your design preferences. Separating the questions from the commands is a good strategy to keep the functioning code clean. Even a simple inventory system can become complicated very quickly. My system used a layer mechanic, where equipping a clothing-type item would automatically unequip anything that overlaps the same layers on the same body parts, as well as show the player which items were going to conflict with it before any action was taken. I think my inventory UI module ended up being the most bloated module in the game, with the number of compiled bytes surpassing the character AI module. Anyway, you've essentially started an online gamedev dojo, and we appreciate it very much, sensei.
Hello Tim, First and foremost, thank you for starting this channel. Im listening to you (and your guests) as a sort of podcast while doing my stuff. Given that I grew up on your games, its like re-living "the good old days". I was wondering if there is a chance for you to have a chat with Chris Avellone - not just about the "old days", but i would love to learn more about the background of Tyranny (for example) which to this day remains one of the best modern RPGs that I played (and i loved the writing). What were the inspirations? Its rare that you get to choose not just the "good/evil" but also you can pick your own definition of what even is "good". And if all else fails, you can just say sod it a go full anarchy. its rare for games to actually take into account those choices and having fully written story for those stories (I remember that you could be evil in Baldurs Gate, but the game wasnt really set up to accommodate that playstyle) I would love to hear your take on that
Hi Tim. Can you explain why you separate "AddItem()" and "CanAdd()"? Because it implies you can use the first function to insert an item into the inventory even if you shouldn't (for instance, it would exceed the capacity, or you're putting pants into the hand slot). It also implies that every time "AddItem()" is called somewhere else, it has to be prefixed by "CanAdd()", which sounds like a host of bugs waiting to happen, especially by other developers. I understand separating these - the Add function shouldn't be bogged down with verification code - but isn't it better to private "AddItem()" in this case and expose something like "SafeAddItem()", that runs the check before adding it?
Two reasons. First, CanAdd is frequently called without any attempt to add the item, such as when the player hovers over an item in a chest. The tooltip can say “too heavy to take”. Second, AddItem is needed when an item must be added, such as a quest reward when a quest is completed. You can always make a public SafeAddItem as you suggest.
@CainOnGames Thanks for the answer. I still find it weird to have exposed behavior for adding items that wouldn't pass a "CanAdd()" check. In your example, the quest rewards should pass that check anyway (for instance, having zero weight). Otherwise you could jam items into the inventory past capacity, assuming capacity has a hard limit. If the limit isn't "hard", then it would pass the check anyway, maybe throw a call to the UI. To me it doesn't feel like that check is optional. If you're adding something to an inventory that wouldn't pass that check, something is going horribly wrong.
@@yaginkuYou just made an assumption that might not be in the design, namely that quest items have zero weight. And it's a good question to ask the designer, and to say why you are asking. Because maybe quest items do have zero weight. But maybe there is a spell to summon food, and that food does not have zero weight, but the player can still cast it even if it makes them overencumbered. A parallel set of methods would be CanEquip, CanUnequip, Equip, and Unequip. Let's say your game has cursed items that can be equipped but not unequipped - that's the curse. A special Remove Curse spell is needed to unequip them. The regular unequip code in the player's inventory UI would check CanUnequip before calling Unequip, but the Remove Curse spell would just call Unequip.
@CainOnGames To be fair, it was more of an example, rather than an assumption. I come from the world of web APIs (and the game engine I'm writing is in JS), so I was confused why a "client object" (some piece of code that tries to add an item) would be allowed to circumvent verification. I guess a valid design example would be when a rule is "generally hard" (ex. "player can never carry more than 50 items"), but a failsafe is put in place in case the player must receive an item no matter what. Still, I feel like my lead programmer would give me a very nasty look if I suggested that from a position of a designer. I do agree with the point of removing items though, since it's much less bug-prone. I'd still probably make a separate function for items like these, but maybe it's my tendency to overengineer.
I also took issue with this. I don't have time to go in to right now, but having a public addItem() that can add an item it shouldn't is just asking for trouble, IMO.
Ok, You've handled 'How you Encumber"/Inventory Management...The Question is "Should you Encumber?"/Streamline Inventory Management. As a probably certifiable Hoarder I've often found myself Over Encumbered in games and caught up in a thing I like to call 'The Inventory Management Mini-Game'. Many games handle this differently ranging from Realistic to Fantastic. I find that there is some sweat spot in the middle where Encumbrance matters but, doesn't drag the other game play down by forcing the player to spend hours moving things between containers in game. I also like the idea of Systems that allow players to Opt. Out of Encumbrance in game as I find that if it's too annoying I'm probably going to use some kind of cheat or mod to ignore it anyway. I've also played a few games where DEVs have Monetized the Inventory system which IMO is Manipulative and 'Evil'.
He made a video called "player hoarding" about it. I personally quite like limiting the inventory as an incentive to make a player actually carry unique things rather than just a weight system hoggled by a bunch of tiny things adding to weight. What I have in mind is specific slots for equipment with no limit to miscelaneous stuff.
If you create the AddItem() or RemoveItem() as a bool return, wouldn't that allow items to be able to call animations or other things for the scenario that they are added or not? Rather than a void that won't return any data back. My thinking is that you would call AddItem(item) then inside the function, it determines CanAdd() - say it cannot be added and has returned false. Then we return false out of CanAdd(), then the item that was added can call functions innots own script based in whatever scenario was triggered. Obviously, it depends on the setup and specific game, though. Maybe i misunderstood anyways. Haha, either way, very interesting stuff, Tim 😁
I think the difference would be that CanAdd() fires off the events to notify UI and other systems. No matter who calls CanAdd(), this will always be the case. If you rely upon outside code reacting to 'false', it's up to the code calling CanAdd() to do this in every instance. At least this was my understanding of the thought process. Love these talks though!
Hey Tim! I am digging into VAOs, VBOs, shaders, textures etc. for the first time. Do you have any tips for code organization in this area? Or any other tips about it? Thanks :)
I noticed the audio is a bit brighter and more echoey/reverby with this new setup with the microphone in the shot. IMO it takes away from cozy vibe the old setup used to have, but it might also just be the old "change is uncomfortable" bias so I'm not sure how useful this feedback is.
As a student who built out his first UI heavy game, I went with MVC for my system/UI separation, but in my case the UI is merely actions and UI related tasks, and would never call the inventory directly to check and see if dragging from one grid slot to another is clear, it merely passes the actions from the view. It means there's much less functionality in the UI and the inventory in this case is just waiting to listen to actions for dragging and dropping for example. Would you say this is a problem? Or just another valid approach? Feedback is welcome!
Hey Tim. Think I disagree with you on this somewhat. I'm a generalist who's been coding since the Atari 400. But I'm also a specialist in reusable code, libraries and frameworks. Maybe you're simplifying here and thus I'm getting the wrong impression. You've specified that the Add and Remove methods should never fail and their should be matching CanAdd and CanRemove functions. What happens if CanAdd would return false but Add gets called anyway? Problem. At best undefined. Add and Remove need to either throw exceptions if they aren't valid or should return the same results as CanAdd and CanRemove. Whatever the case it should be 100% consistent and impossible to put the inventory into a bad state or have something fall through the cracks (Add is called and fails silently because CanAdd would be false). The other aspects is the grid inventory. You say the grid layout should be known to the GUI but not known to the inventory component. But that is problematic. What happens if there is technically weight/space available for the item but due to the shapes and sizes of things the item won't fit into the inventory grid? That's a problem, in that case CanAdd should return false but it can't because it doesn't know about the grid. In OOP the inventory that doesn't know about the grid should be one class (Inventory lets say) and there should be an InventoryGrid class that inherits from it and implements a grid. The grid layout and organization ant this point should be known to the component. That way the component can be the single source of truth about the inventory and make sure the inventory is always in a valid state.
I should have specified that CanAdd (and similar methods) only return game mechanics reasons that the add can fail. That’s why a call to Add can be made without a call to CanAdd, for situations where an item is being forced into the players inventory. As for the grid, I’d have the UI know about that. It can have its own UICanAdd, which checks for space on the grid. No reason the inventory layer should know about the UI, especially when other inventories (like merchants or chests) may use different size grids or not use grids at all. If Add failed for other reasons, yes, it should throw an exception.
@@CainOnGames Thanks for the reply and clarification. Regarding the grid, I respectfully disagree. If the inventory uses a grid I see that as mechanics that the component should be responsible for. Keeping UI code separate is best practice, implementing mechanics in UI (the grid logic) contaminates UI code and breaks that separation IMHO. I'd potentially use inheritance to have a basic, standard inventory component and then a descendant that implemented a grid. Then the same interface could be used consistently across both, so CanAdd was always accurate and the coder didn't have to know/check if it was a different kind of inventory and then call a different UiCanAdd method for the correct answer. Neither way is "wrong", this is where coding is more an artform than a science.
Lovely! Could you also talk about which software architectures are suitable for different sub systems such as in-game store, chat, multiplayer? There are a lot of resources to learn about architectures and pattern, in the context of games it would be great to know when or how to use them. Thank you Uncle Tim! Leaned a lot from here.
My inventory array, sobbing, running away after Tim says he doesn't care :( Great vid, your structure implies a bunch of commonly run into issues that I wouldn't have considered just thinking about it!
IMO having equip and can_equip methods is a bad design. Inevitably user will forget to call can_do and force an action which shouldn’t be allowed. It’s better to have equip method which checks for the condition and returns an error if the condition is not met. Pretty much all modern compilers have a way to warn if caller doesn’t check return value of annotated methods so with that users won’t forget to check the error. For example, in Skyrim you can equip infinite number of items if you get arrested multiple times. The moment you leave the prison, all items you had equipped each time you were arrested will be forcibly equipped and your character can end up wearing ten different breast plates. If necessary can_equip method can be added (e.g. to highlight all items that character can pick up) and than equip method would be implemented by first calling can_equip. Similarly, if there are items which are forced to be equipped (e.g. cursed items) there can be a force_equip but the counter to that is that items which can be forced to equip should always be able to be equipped, e.g. weight nothing. The advantage of having equip and force_equip methods is that force_equip is more explicit about it bypassing some checks and because programmers would normally not use it (since they have equip which does the checks they want) it would be less likely to misuse force_equip.
What are your thoughts on MMORPGs, could the genre be improved to make it more like pen and paper RPGs with actually interesting and meaningful story arcs.
This is awesome, I have nothing to do with game development, but now I really want to build an inventory module. This kind of high-level info is fairly rare afaik, love it!
Hello Tim, There's a bit of a "topic" I'd like your thoughts on - Not going to name names, but I feel like there's been a common "problem" in many RPGs (Usually of the large-budget variety) where the *setting* and worldbuilding communicates a life of Hardship, resource scarcity, and 'cold calculations', but the actual gameplay mechanics betray the world's premise and ultimately make the player a Tourist in a Theme-Park as *none* of these "Harsh Realities" of life in the setting apply to the player or their mechanics, which I've dubbed the "Theme Park Problem" in discussions I've had with others concerning the concerned games where this is a thing. Things like a certain scarce economic resource being constantly TELLed about to the player as being life-or-death vital to everyone, but never being SHOWed to the player as the most the player might ever interact with said resource being a Key Item MacGuffin used in a single side-quest or worse, an infinitely farmable item.
Hey Tim: I know that it's not exactly something you probably keep up with, but have you happened to see anything about the Fallout: London project? Incredibly talented group of people have teamed up since about 2019 to create a game-sized conversion for Bethesda's FO4, except set in London in the time between FO1 and 2. Would be great to hear your thoughts on it since they've just released a pretty in-depth trailer about the game's upcoming release and features.
Thanks for this, I really like more detailed stuff like this. I personally (solo indie) use lists of struct pairs: {name, quantity} for various quality of life reasons.
Man, I wish I saw this before making inventory system for my game, my code is a total mess. I would love to see you code system like this in Unity or Godot, it would be really helpful for struggling developers like me
Hey I ma looking to writing a book fallout inspired from nv and elements of fallout 2 while having my unique spin. What are your thoughts if possible to share on this? Thank you.
seems more bug prone to have to have the caller check if you can add to inventory rather than require them to handle an error or pass in a witness type (eg a DidCheckCanAdd type passed into the add() fn)
Thank you for replying my question. Your experience shows how that should be done. The way you described it, with can_equip() method, also allows for example, easily implement highlighting items which are equippable to some particular slot, maybe when player mouse over the gear slot.
Yea separating the mechanics and UI is a really great point too, I'm glad he touched on it. That kind of functional compartmentalization is what often gets overlooked by programmers of all stripes.
Hey those technical talks are pretty great, we need more of those with this level of details
Brilliant. Hadn't thought of breaking return codes into their own "Can" methods, or even reusing Inventory components across NPCs, chests, etc. Thanks as always, Tim!
I don’t know a single thing about game design, nor will I ever have anything to do w it in my career, but I watch all your videos.
Glad having checks and actions for inventory is basically what I did for my inventory code, but also having to branch out for each type of item like stackable or not, etc. Also these technical talks are just as great as wig story talks lol
Love these kinds of talks. More please! How about "spells" or "effects"?
WOW, this video was pure gold. Thank you very much. I would like to hear more about these.
Thank you! These sort of tips are invaluable and help me find a path forward instead of wanting to rip my hair out. Thank you!
As an amateur programmer this was very insightful. Thank you!
You talked about the inventory system having its own clean API for use of mostly the UI. Around how many of these would you create, like would you make one for each mechanic in the game or like this whole thing is the combat API?
Multiple, in both directions. Meaning one mechanic, say inventory, might have multiple UI’s, like looting, bartering, and personal inventory. But some UI’s, especially the HUD, might pull from multiple different mechanic API’s, like combat, attributes, and status effects.
Thanks!@@CainOnGames
Excellent video. I am not a game developer, but your explanation for this type of system might help me in designing a tool I want to build. Getting design tips from someone with so much experience and avoiding pitfalls is appreciated and insightful 😄
As a beginner gameplay programmer, I found this video fascinating. Please make other ones like this about other gameplay components.
Tim in for some more classic wisdom. You always make my morning with your videos 👍
Hi Tim, been waiting for a video on this for a while. Thanks so much!
This is a rather vague question but could you talk at all about your thoughts on VR, perhaps AR also and just video gaming beyond the traditional medium that we have known it as. Do you see any future potential, for example ideas you had in the past that might now be more viable with certain additional freedoms allowed in something like VR.
Thanks!
Have you seen this video?
ua-cam.com/video/STLv3a3gBr4/v-deo.html
Not sure how it works for asking questions, so I'll try here in a post.
I'd like your opinion on RPGs with no combat.
- Were you ever interested in doing a game like that?
- If so, or maybe if you just contemplated the idea after playing a title of that kind, what were your (proto?) ideas for ways to substitute combat?
(I'm thinking Disco Elysium, basically, which was a great game for me, even when considering only its RPG mechanics. With its use of ideas and personalities connected to traits and bonuses, and also the best amnesiac protagonist I've ever played, 100% integral to the story and to everything you do throughout its development.
Only thing I didn't like too much of that game is the use of clothing/accessories to add and remove bonuses. I see it's used together with leveling in order to repeat rolls, so it's a mechanic that might have been somewhat of a necessity, in order to allow the player to enjoy all those wonderful failure scenarios without save-scumming. But it still caused a bit of immersion breaking while playing the game, with my guy changing cloths in front of NPCs before starting a dialogue with them: a very minor complain, when nothing is perfect and there's always room for improvement.)
Thanks for your videos!
this topic is exactly what I needed, I have no clue how to actually structure code just make tiny projects
Love the programming advice just as much as the design advice/stories!
Hi Tim! Thanks for these videos. I once dipped my toes into the video game industry as a tester and I was wondering what sort of testing tools you have had in your games, tools that let you complete quests instantly or change factions' reactions to your character etc.
Hi Tim,
Question related to timing and hiring people. My team and I are currently in the works for our next project and one thing our team needs is a 3D Artst / Modeler. What's your advice / experience on when you should begin the hiring process for a developer position for a position your team currently doesn't have, compared to when the project actual starts, my biggest fear is hiring said person and then them waiting to have work - but at the same time it would be terrible to be ready and be in the middle of hiring said position.
Keep up the amazing content as always!
I react like Bizarro Jerry every time you introduce yourself
It makes for a nice clean design to use the Observer pattern between the game logic and the UI, Sound, Music, etc. You send off events like dealing damage, gaining mana, etc. and the Sound, Animation etc. subsystems just listen for events they care about and play the Sound, Animation, etc. as appropriate. The game logic itself essentially runs headless.
Hi Everyone Its me Tim
Timhh
Thanks for saying so,
Hi Tim. It's me, everyone.
You are missing the commas
"Hi everyone, it's me, Tim"
Her yerdeyiz mq
Do this again but for status effects, like buffs, debuffs, or other side effects caused by abilities or items. 👍
Question, what are your thoughts on unofficial Fallout games? PC gamer just had an article that featured 5 brand new Fallout games being made by fans based of the Fallout 4 engine. Have you played any of the older fan made Fallout games?
Hi Tim!
Sorry I've asked this before and perhaps you chose not to answer it, but it's somewhat related to this video so I thought I'd ask again in case it got missed. When designing the system for items so that many items can be made, it'd be interesting to know how you would/have divided up the item that appears in your inventory, versus the item that appears on the floor (in some games) that you can collect, versus the effect the item has when you use it (if you can) and as a sub-point of the last one, how equipment or ammo fit in to that picture.
I feel like it must take quite a lot of planning to make new items easy to create and implement easily.
In that inventory example: its important to have gamedesign define what the inventory must do, and what it will not do. Defining that early on. Else things like "lets make it a grid" or "we should add stacks" can add ugly hacks or require a whole redesign of the code.
omg love these videos, you are a treasure trove of knowledge!
Hei, when you said do not couple the inventory and how the menu display I could not agree more. At work I have a "high ranking" that insist on coupling everything because that's how it has always done, and this really effects the quality and the cleanliness of the code I can produce. Do you have any tips to muster through things like this without loosing all motivation for the project? Its a project I have been working on for a few years, and loosing motivation.
Tim, the OOP Guy :D
Seriously, there are so many programers today who only know how to write the stuff as is with the reason being "because I need it here now". This video demonstrates that dividing responsibility is important.
Thank you, maybe now some devs will ask themselves "does this thing even care about the other thing" more often and write less mangled spaghettios.
I'm not the OOP guy, but even I would most likely separate ui and inventory. Because those are two separate parts of the game.
I'm not sure tho, that stalker/tarkov-like UI should be unaware of its visual representation. Because it's kind of crucial for it to be able to fit an x*y sized item AND be an x*y grid with fixed dimensions.
@@zhulikkulik inventory system is aware of sizes/weights etc, but it doesnt use that info. UI on the other hand does use that info but is unaware of how the actual object is stored. UI may impose its own rules (like grid size, amount limits etc) but it does not "store" the item itself.
At least that's how I understood Tim's main idea.
Just yestarday I was writing an inventory/equipment system. This will be useful!
Hey Tim, great video as always.
I would love to hear your thoughts/opinions on Tutorials on RPGs. Are there different types of it? How does one implement a good tutorial for the genre?
I have a question about establishing a story. Obviously the initial idea will probably start with a setting, but what is the process from there? Do you come up with the beginning and ending and fill in the gaps? Does the story influence the game areas and/or vice versa?
Can you make a tutorial about this topic in particular but for the whole game and dive deeper into the technical stuff? How to make the code maintainable, readable and scalable while still being performant and all...
Hey Tim, have you been doing some shader/particles programming? What's the best place for someone to start learning about it? How do you decide about using one and do you take existing functions/shaders or write it yourself? Cheers and thanks for videos.
Hey Tim, love the videos. Constructive criticism: I think you need to have the mic closer to your mouth, we can hear that the levels have been over boosted and sound a bit clipped.
Good advice! Thanks!
Hey Tim, I currently work in the industry as a gameplay programmer generalist and I know I'm very good at my job(this is based off others telling me) but I always wanted to do game design roles and I work with designers everyday and actively suggest designs that work well in the game(and end up getting added). When interviewing for game design positions the first thing the recruiter tells me is that on paper I don't qualify as a designer on paper(from my job experience) so they really wanted to talk with me about a gameplay programming position. I have been making portfolio projects and I do get interviews for design positions but always get suggested to be a gameplay programmer instead because they need that more urgently. What do you recommend I should try to do in regards to moving into design positions?
man, maybe you should just do it? It's an unfortunate reality but programmers, specially good ones, are rare. Designers are a dime a dozen so the value a good designer has is woefully underappreciated.
Hi Tim, what ways would you personally recommend for effectively disseminating different types of information in the workplace? Love your work and the videos.
Do you think behavior trees are the way to go for NPCs?
I love your channel.
I use Unreal Engine and I hear use an Event Dispatcher when it comes to encumbrance.
do you know the dev who created jagged alliance 2? do you ever play jagged alliance 2? do you like it?
Has he commented on the disaster that is the Outer Worlds Spacers Choice edition?
Good morning Tim!
That's a strange separation of concerns - if you have a sword that requires level 12 to use, and the player's just lvl 10, then it's the inventory's job to reject adding that sword, however, if the sword is 4x1 tile sized, and you don't have a 4 tile consecutive free spot on the grid, that's a UI concern?
I'm not sure he had Tetris ui in mind. I'd say Tetris ui should be fully aware of its visual representation because that is kind of a game mechanic.
Hi, Tim. I recently watched the Interview with Alper Çağlar you did a few months ago. I really wanted to know something you've mentioned there you didn't know what were you doing the space between Fallout 1 and Fallout 2 did you find anything since then?
I did not. All of that information was on my work computer at Interplay, which was probably lost after I left.
@@CainOnGames Ahh that's sad I really wanted to know that thanks for your answer Tim! Hope you find some evidence in the future.
I think Tim needs to read the Gang of Four patterns. It feels like he's reinventing patterns that were specified in the 1980s.
So with grid based inventory there is no validation in inventory mechanics system if two items overlap (despite that data being saved). It is only validated in UI code. Why?
I can already see inventory UI bugs polluting saves with multiple items taking same space.
Or is reasoning that "grid inventory" mechanics are not considered to be part of game rules system. Which seems strange to me.
You can decide whether the grid and its restrictions are part of the UI or the mechanics, and that will determine where those checks go. You can easily have a CanAddItemUI() method too that checks to see if the item can fit into the grid.
Appreciate the episode but it's way too technical for me to comprehend. Being an artist and not a coder, I will need some visuals to help explain majority of the coding aspects.
NPCs could also listen to encumberance and comment on it.
hi tim its us everyone
there is no such thing as "code organization"! all code is spaghetti code. no exceptions.
tim you are lowkey my favorite youtuber
Secrete hidden chest is accessible in Broken hills.
I wish I could describe these systems declaratively using constraints. I want my UI APIs to be like database queries, they don't need to run every frame, just when data changes. I read an interesting paper "out of the tar pit" that talks about something like this.
Ugh. So bad.
As someone who has written more than one complex inventory system, I definitely like your design preferences. Separating the questions from the commands is a good strategy to keep the functioning code clean. Even a simple inventory system can become complicated very quickly. My system used a layer mechanic, where equipping a clothing-type item would automatically unequip anything that overlaps the same layers on the same body parts, as well as show the player which items were going to conflict with it before any action was taken. I think my inventory UI module ended up being the most bloated module in the game, with the number of compiled bytes surpassing the character AI module. Anyway, you've essentially started an online gamedev dojo, and we appreciate it very much, sensei.
yay, trying to work out how to structure code for my first project, good timing!
Hello Tim,
First and foremost, thank you for starting this channel. Im listening to you (and your guests) as a sort of podcast while doing my stuff. Given that I grew up on your games, its like re-living "the good old days".
I was wondering if there is a chance for you to have a chat with Chris Avellone - not just about the "old days", but i would love to learn more about the background of Tyranny (for example) which to this day remains one of the best modern RPGs that I played (and i loved the writing). What were the inspirations? Its rare that you get to choose not just the "good/evil" but also you can pick your own definition of what even is "good". And if all else fails, you can just say sod it a go full anarchy. its rare for games to actually take into account those choices and having fully written story for those stories (I remember that you could be evil in Baldurs Gate, but the game wasnt really set up to accommodate that playstyle)
I would love to hear your take on that
Hi Tim. Can you explain why you separate "AddItem()" and "CanAdd()"? Because it implies you can use the first function to insert an item into the inventory even if you shouldn't (for instance, it would exceed the capacity, or you're putting pants into the hand slot). It also implies that every time "AddItem()" is called somewhere else, it has to be prefixed by "CanAdd()", which sounds like a host of bugs waiting to happen, especially by other developers. I understand separating these - the Add function shouldn't be bogged down with verification code - but isn't it better to private "AddItem()" in this case and expose something like "SafeAddItem()", that runs the check before adding it?
Two reasons. First, CanAdd is frequently called without any attempt to add the item, such as when the player hovers over an item in a chest. The tooltip can say “too heavy to take”.
Second, AddItem is needed when an item must be added, such as a quest reward when a quest is completed.
You can always make a public SafeAddItem as you suggest.
@CainOnGames Thanks for the answer. I still find it weird to have exposed behavior for adding items that wouldn't pass a "CanAdd()" check. In your example, the quest rewards should pass that check anyway (for instance, having zero weight). Otherwise you could jam items into the inventory past capacity, assuming capacity has a hard limit. If the limit isn't "hard", then it would pass the check anyway, maybe throw a call to the UI. To me it doesn't feel like that check is optional. If you're adding something to an inventory that wouldn't pass that check, something is going horribly wrong.
@@yaginkuYou just made an assumption that might not be in the design, namely that quest items have zero weight. And it's a good question to ask the designer, and to say why you are asking. Because maybe quest items do have zero weight. But maybe there is a spell to summon food, and that food does not have zero weight, but the player can still cast it even if it makes them overencumbered.
A parallel set of methods would be CanEquip, CanUnequip, Equip, and Unequip. Let's say your game has cursed items that can be equipped but not unequipped - that's the curse. A special Remove Curse spell is needed to unequip them. The regular unequip code in the player's inventory UI would check CanUnequip before calling Unequip, but the Remove Curse spell would just call Unequip.
@CainOnGames To be fair, it was more of an example, rather than an assumption. I come from the world of web APIs (and the game engine I'm writing is in JS), so I was confused why a "client object" (some piece of code that tries to add an item) would be allowed to circumvent verification. I guess a valid design example would be when a rule is "generally hard" (ex. "player can never carry more than 50 items"), but a failsafe is put in place in case the player must receive an item no matter what. Still, I feel like my lead programmer would give me a very nasty look if I suggested that from a position of a designer.
I do agree with the point of removing items though, since it's much less bug-prone. I'd still probably make a separate function for items like these, but maybe it's my tendency to overengineer.
I also took issue with this. I don't have time to go in to right now, but having a public addItem() that can add an item it shouldn't is just asking for trouble, IMO.
Ok, You've handled 'How you Encumber"/Inventory Management...The Question is "Should you Encumber?"/Streamline Inventory Management. As a probably certifiable Hoarder I've often found myself Over Encumbered in games and caught up in a thing I like to call 'The Inventory Management Mini-Game'. Many games handle this differently ranging from Realistic to Fantastic. I find that there is some sweat spot in the middle where Encumbrance matters but, doesn't drag the other game play down by forcing the player to spend hours moving things between containers in game. I also like the idea of Systems that allow players to Opt. Out of Encumbrance in game as I find that if it's too annoying I'm probably going to use some kind of cheat or mod to ignore it anyway. I've also played a few games where DEVs have Monetized the Inventory system which IMO is Manipulative and 'Evil'.
He made a video called "player hoarding" about it. I personally quite like limiting the inventory as an incentive to make a player actually carry unique things rather than just a weight system hoggled by a bunch of tiny things adding to weight. What I have in mind is specific slots for equipment with no limit to miscelaneous stuff.
I prefer inventory limit over weight limit.
If you create the AddItem() or RemoveItem() as a bool return, wouldn't that allow items to be able to call animations or other things for the scenario that they are added or not? Rather than a void that won't return any data back.
My thinking is that you would call AddItem(item) then inside the function, it determines CanAdd() - say it cannot be added and has returned false. Then we return false out of CanAdd(), then the item that was added can call functions innots own script based in whatever scenario was triggered. Obviously, it depends on the setup and specific game, though.
Maybe i misunderstood anyways. Haha, either way, very interesting stuff, Tim 😁
I think the difference would be that CanAdd() fires off the events to notify UI and other systems. No matter who calls CanAdd(), this will always be the case. If you rely upon outside code reacting to 'false', it's up to the code calling CanAdd() to do this in every instance. At least this was my understanding of the thought process. Love these talks though!
Hey Tim! I am digging into VAOs, VBOs, shaders, textures etc. for the first time. Do you have any tips for code organization in this area? Or any other tips about it?
Thanks :)
I noticed the audio is a bit brighter and more echoey/reverby with this new setup with the microphone in the shot. IMO it takes away from cozy vibe the old setup used to have, but it might also just be the old "change is uncomfortable" bias so I'm not sure how useful this feedback is.
As a student who built out his first UI heavy game, I went with MVC for my system/UI separation, but in my case the UI is merely actions and UI related tasks, and would never call the inventory directly to check and see if dragging from one grid slot to another is clear, it merely passes the actions from the view. It means there's much less functionality in the UI and the inventory in this case is just waiting to listen to actions for dragging and dropping for example. Would you say this is a problem? Or just another valid approach? Feedback is welcome!
Love the discussions about clean code organization! Event systems are really good for decoupling and making the code clean
Hey Tim. Think I disagree with you on this somewhat. I'm a generalist who's been coding since the Atari 400. But I'm also a specialist in reusable code, libraries and frameworks. Maybe you're simplifying here and thus I'm getting the wrong impression.
You've specified that the Add and Remove methods should never fail and their should be matching CanAdd and CanRemove functions. What happens if CanAdd would return false but Add gets called anyway? Problem. At best undefined. Add and Remove need to either throw exceptions if they aren't valid or should return the same results as CanAdd and CanRemove. Whatever the case it should be 100% consistent and impossible to put the inventory into a bad state or have something fall through the cracks (Add is called and fails silently because CanAdd would be false).
The other aspects is the grid inventory. You say the grid layout should be known to the GUI but not known to the inventory component. But that is problematic. What happens if there is technically weight/space available for the item but due to the shapes and sizes of things the item won't fit into the inventory grid? That's a problem, in that case CanAdd should return false but it can't because it doesn't know about the grid. In OOP the inventory that doesn't know about the grid should be one class (Inventory lets say) and there should be an InventoryGrid class that inherits from it and implements a grid. The grid layout and organization ant this point should be known to the component. That way the component can be the single source of truth about the inventory and make sure the inventory is always in a valid state.
I should have specified that CanAdd (and similar methods) only return game mechanics reasons that the add can fail. That’s why a call to Add can be made without a call to CanAdd, for situations where an item is being forced into the players inventory.
As for the grid, I’d have the UI know about that. It can have its own UICanAdd, which checks for space on the grid. No reason the inventory layer should know about the UI, especially when other inventories (like merchants or chests) may use different size grids or not use grids at all.
If Add failed for other reasons, yes, it should throw an exception.
@@CainOnGames Thanks for the reply and clarification. Regarding the grid, I respectfully disagree. If the inventory uses a grid I see that as mechanics that the component should be responsible for. Keeping UI code separate is best practice, implementing mechanics in UI (the grid logic) contaminates UI code and breaks that separation IMHO. I'd potentially use inheritance to have a basic, standard inventory component and then a descendant that implemented a grid. Then the same interface could be used consistently across both, so CanAdd was always accurate and the coder didn't have to know/check if it was a different kind of inventory and then call a different UiCanAdd method for the correct answer. Neither way is "wrong", this is where coding is more an artform than a science.
Lovely! Could you also talk about which software architectures are suitable for different sub systems such as in-game store, chat, multiplayer? There are a lot of resources to learn about architectures and pattern, in the context of games it would be great to know when or how to use them. Thank you Uncle Tim! Leaned a lot from here.
My inventory array, sobbing, running away after Tim says he doesn't care :(
Great vid, your structure implies a bunch of commonly run into issues that I wouldn't have considered just thinking about it!
IMO having equip and can_equip methods is a bad design. Inevitably user will forget to call can_do and force an action which shouldn’t be allowed. It’s better to have equip method which checks for the condition and returns an error if the condition is not met. Pretty much all modern compilers have a way to warn if caller doesn’t check return value of annotated methods so with that users won’t forget to check the error.
For example, in Skyrim you can equip infinite number of items if you get arrested multiple times. The moment you leave the prison, all items you had equipped each time you were arrested will be forcibly equipped and your character can end up wearing ten different breast plates.
If necessary can_equip method can be added (e.g. to highlight all items that character can pick up) and than equip method would be implemented by first calling can_equip.
Similarly, if there are items which are forced to be equipped (e.g. cursed items) there can be a force_equip but the counter to that is that items which can be forced to equip should always be able to be equipped, e.g. weight nothing. The advantage of having equip and force_equip methods is that force_equip is more explicit about it bypassing some checks and because programmers would normally not use it (since they have equip which does the checks they want) it would be less likely to misuse force_equip.
What are your thoughts on MMORPGs, could the genre be improved to make it more like pen and paper RPGs with actually interesting and meaningful story arcs.
You might like my Storytelling in MMORPGs video.
ua-cam.com/video/MZB516hovas/v-deo.html
This is awesome, I have nothing to do with game development, but now I really want to build an inventory module. This kind of high-level info is fairly rare afaik, love it!
Makes sense, very helpful insights, thank you for sharing!
Hello Tim,
There's a bit of a "topic" I'd like your thoughts on - Not going to name names, but I feel like there's been a common "problem" in many RPGs (Usually of the large-budget variety) where the *setting* and worldbuilding communicates a life of Hardship, resource scarcity, and 'cold calculations', but the actual gameplay mechanics betray the world's premise and ultimately make the player a Tourist in a Theme-Park as *none* of these "Harsh Realities" of life in the setting apply to the player or their mechanics, which I've dubbed the "Theme Park Problem" in discussions I've had with others concerning the concerned games where this is a thing. Things like a certain scarce economic resource being constantly TELLed about to the player as being life-or-death vital to everyone, but never being SHOWed to the player as the most the player might ever interact with said resource being a Key Item MacGuffin used in a single side-quest or worse, an infinitely farmable item.
Thanks, Tim! Keep talking! We're listening!
Hey Tim: I know that it's not exactly something you probably keep up with, but have you happened to see anything about the Fallout: London project? Incredibly talented group of people have teamed up since about 2019 to create a game-sized conversion for Bethesda's FO4, except set in London in the time between FO1 and 2. Would be great to hear your thoughts on it since they've just released a pretty in-depth trailer about the game's upcoming release and features.
Thanks for this, I really like more detailed stuff like this. I personally (solo indie) use lists of struct pairs: {name, quantity} for various quality of life reasons.
Man, I wish I saw this before making inventory system for my game, my code is a total mess. I would love to see you code system like this in Unity or Godot, it would be really helpful for struggling developers like me
Hey I ma looking to writing a book fallout inspired from nv and elements of fallout 2 while having my unique spin. What are your thoughts if possible to share on this? Thank you.
Programming advice from the legend Tim Cain himself! You kids don't know how lucky you have it :)
seems more bug prone to have to have the caller check if you can add to inventory rather than require them to handle an error or pass in a witness type (eg a DidCheckCanAdd type passed into the add() fn)
I’ve never coded a game but canDoX(), doX() is race conditioned, no? Depending on how concurrency is handled in the game engine
I am digging these technical videos a lot!
Is that why I can over load myself on Bethesda games 😅
That was very helpful! :D
Hey everyone it's him, Tim
Excellent, thanks, this was a great example to cover! Very helpful. :D
I'm super stoked on this particular kind of video, very interesting
Thank you for tech video!
Would also like to know about how you code all the entities in your game. Do you use the ECS, pure hierarchy, or a mix of both?