To clarify code vs scripts: Code - a set of instructions, usually compiled and often part of the game engine, that is used by all objects of a particular type, e.g. doors, guards, etc. Code is usually written by programmers. Script - a set of instructions, usually interpreted and often in a different programming language from code, that is used by a specific object and often attached to it. Scripts are written by anyone on the development team. Some commercial game engines separate code and scripts (such as Unreal, which has blueprints for scripting but allows programmers to rewrite the C++ engine code) and others do not (such as Unity which only allows scripting). In the latter case, it is still a good practice to keep general and specialized scripts separate, with one set of scripts that all objects of a type use and separate scripts that individual objects use.
Just to make sure I understand, coding is basically creating the content of the classes, defining how a door for example would behave, but scripting is putting another piece of code on top of the class code for a specific object/instace of said class, because the door in building A needs to behave slightly differently?
I don’t have game dev experience, but I’ve worked as a software developer for the past 6 years, and I’m just getting into game dev, so I’m not sure if I understood correctly.
@norberthresko8154 What i understand is he mixed few points. He talked about the efficency of compiled code vs external instructions that are way slower and heavier, but also easy to customize without the need of a recompilation or touching a code in a messy way. That mean u dont really want to implement behaviours etc in the script, You just want to do the "basics", make a character aproach the player, or run away from him, maybe in a very weird case run a cinematic... but if it involves gameplay logic, shouldnt be there. (like branching selecting cases of storylines). That should be somthing desirabe to be done intro the game engine and not the scripts. Dead guards shouldnt even have a behaviour anymore (atleast, if hes truly dead and not a zombie..) its a waste of resources... you may want the corpse still there by changing/switching the object, or just dissable his IA, ticks etc and may just leaving a ragdoll or even not that... but for the one whos alive, all the checks to do before execute the script should be coded in the game instead of useing external scripting. Enhaced Princess example: you resque her and bring her to safe place. mission succesfully acomplished, but If you let a scripter do all those checks out the game logic when you talk with the one whos going to continue the story, or reward you for it but somehow the princess dies before you talk with him, and his scripts do those fancy checks you will get a mission failed, and in worst scenario a bricked gamesave. External scripts should be called on last resource. And most if not all pre checks to decide if the script should be called or not, should be in the object functions, OnTryPickup, OnPickup, add variables/properties like CanBeDropped, CanBeSold, or if u want it easy isQuestObject to ensure you cant drop/transfer/sell it, or in case of sneaking in a room, add a collisionbox that starts the "watchdog" function running in a behaviour like "if hes noisy enougth, or if a guard see the player and hasnt enougth stealth to be undetected, or he isnt in a shadow... then trigger X event. This X event could have a interface that after check whatever is suposed to check, THEN run the script or override the game logics. Also in case of sneaking intro houses, may be better to use a onActorBeginOverlap instead of implementing on each door/window/whatever... player could bypass those more specific things with somthing unpredicted like glitching a wall or digging a hole. its about good practices and organized/ well planified events and flow. Atleast, thats how i understand the thing... maybe im wrong as i never been a pro programmer, just a autodidact 100% as i didnt even finished the basic school, also english is not my native language. So i hope my point is accurate and understandable enougth.
@@DoubleMotherLess Thanks for the explanation but I still don't get it 😅 It might just be because of my lack of gamedev knowledge/experience, but I don't understand Code vs External Script. In my mind why wouldn't you just do everything in code? (still not quite 100% of the meaning of in code vs in script). What is External Script? You code your logic, and someone else comes and puts a script on a specific NPC object to override the basic functionalities? Why is that a thing people do? I guess this "External Script" is very game engine specific, because I just can't comprehend it 😅Also, if someone can just overwrite the basic logic, why not then just create an extension point, where the scripts can be run by overwriting that extension point in the script, but still is controlled by code? I would be very interested to have a discussion about this, but I feel like I lack some crucial information that would help me put all of this into context.
The reason you have scripting in RPGs is because many of the rules have exceptions, and those exceptions have exceptions, and those exceptions have exceptions, and so forth. While a programmer could write all of those rule exceptions, they are frequently on just one or two objects, so placing an override script on those objects is cleaner than having code cluttered with additional checks that fail 99% of the time. Also, explaining to a programmer those special cases takes time away from other features they could be coding. Hence, scripts. And you are right about extensions. I talk about such attachment points in my video on Arcanum Scripting ua-cam.com/video/coPkWyJIl-M/v-deo.html
Im a chef. Im not a programmer and ive never worked even remotely adjacent to video games, yet for some reason i find these videos endlessly fascinating.
I'm in property management and think the same thing. A lot of the lessons are things that could be applied across industries, experiences that are more universal than just the games industry. It's also fascinating as a gamer to get a glimpse behind the curtain as to how the games we love are made.
I appreciate this comment, but don;t think that just because you're one profession it means that you're not allowed to learn a variety of other things. Your knowledge can include a wealth of other things not related to your current profession.
As someone who’s been learning GameDev as a side hobby, these videos are immensely useful. Tim is so good at presenting an abstract concept and breaking into component parts.
I've have good example of "not coding the rules" that I'm surprised you didn't mention - the car in Fallout 2. Either Chris or Josh told me years ago that they when they went to add it, they didn't have a programmer to do it available, so it was all done in script as an additional party member. The result was a LOT of bugs - disappearing car from some locations, incorrect player counts in other scripts on a map with the car, etc. etc.
@@ZiggyMeister Which is one of the reasons I mentioned it - another being that it's an example much of this video's audience will be familiar with. Had Tim still been there on F2, I am very sure he would have immediately said "this needs code support" the moment adding a car was brought up.
I like your version - very neat and easy to remember... But "systems" and "content" can be misused fast. I can see myself saying "that's not what we mean by 'content'"
And his logic can be applied outside games as well. Just replace "script" with "workflow engine" or similar and boom. Business version covering the same topics and issues...
@@ecosta And even if you don't have a scripting language for your game, you can separate code meant for core mechanics and code that extends core mechanics. For instance in a game I was working in, you had status effects, I had lots of code to handle how they worked, but it wouldn't be wise to implement core systems as status effects and should instead be the "exceptions" as he mentioned
In Fallout 3 and New Vegas a "dead" NPC placed in the world with zero health is still considered alive and will still blink. To fix it you have to attach a script that kills the NPC, because there's no check in code to do it automatically if they spawn with zero health.
Yo, this is a nightmare to make "right" via scripting. Even harder if you have an engine that favours scripting over code (like most do nowadays). Imagine if you need to remember all those little details whenever you make a game, a DLC, etc?
I have several items in my inventory that I can't put into a drawer because this is a quest item. Well that quest has been completed already, let me drop it off
I am not sure but that could be due to Bethesda is prioritizing modding. Modding is running with scripts in general for more modebility without accessing source code
This talk interacts a lot with the DRY (Don't repeat yourself) idea. I can see creating a lot of scripts being a nightmare to maintain, while coding in one or two places can help the developers later on. Cheers!
Thank you for the continued education, insight, & inspiration. At the beginning of this year I started my Game Development/Programming journey due to being inspired & encouraged your videos & your games. In a video you mentioned a “selfish” reason for starting the channel was that you wanted more games to play. Thank you for inspiring me start this lifelong journey & hopefully one day I can give back by making a game or two for you to play. That was inspired by your insights. TLDR; Thank you for the videos & the games. One day I will email you a game for you to play, as my little way of saying thanks.
I have been hounding my students about this just about every year. Hopefully they listen to you when I play this video in class this year. (Constantly scripting logic on individual objects for core-feature events, “Do you realize how much of the CPU your bullets are using??”)
If I'm understanding right, "code" in this context is systemic logic which affects all parts of the game while a "script" is an instanced logic attached to objects? It was a bit confusing for me at first since I think of scripts as files containing code, so technically all things are scripts with code.
System vs Instance would probably be better terms here His use of code vs script is indicative of the studios and tooling he's used to not a general rule or concept, these would've been extremely confusing in the studio i worked at since A all of the code was technically scripts but B also pre compiled and as fast as you the programmer could make the logical steps of.
Not a game dev here... This is my guess. Typically 'code' will refer to what goes into the game engine and is written in the game engine language - c++, c#, etc. Changes to this code base requires recompiling the engine. How long that takes may vary but it could range from seconds to dozens of minutes. Scripts are usually written in a higher level interpreted language - Lua is a common one. These tend to have relaxed rules and the language will handle a lot of things that lower level languages don't, but also setting things properly isolates what you do in the script from what the engine handles. Depending on how things are set up, you could literally edit a script while the game is running, then reload the save file and the changes you've made to the script will immediately kick in. But maybe you don't have that set up so you still need to compile the scripts separately and restart the game, but you shouldn't need to recompile the rest. The main difference between script and code is that scripts are a lot more flexible and (with enough backend support) are more human readable. You might even get some of your more adventurous game designers to get their hands dirty and write their own scripts. The main reason you don't want to do everything in script is because it's slow. The second reason is that you don't want to implement highly complicated things in the script for all the reasons mentioned in the video.
So, its not particularly useful since you managing a high level approach with unity, godot or blueprints(only). But. As a system design method it still will help your indie game perform better, be scaleable and easier to bugfix
Question/Video Idea: What was the origin story for the Mysterious Stranger? Who thought up the concept? What was the inspiration? Etc. I love that perk and the Stranger always puts a smile on my face when he shows up! Also, is there a better place to post general questions? I can't find anything in the Community Forum (but i'm a UA-cam subscriber newb). Love ya, Tim!
I'm pretty sure Mysterious Stranger was Chris Taylor's idea, but I don't have anything about it in my notes, so I am just making a memory stab here. And just ask. I read all comments.
@@CainOnGames "No. 44, The Mysterious Stranger" is a book and character by Mark Twain with various depictions throughout several unfinished versions of the story. In Fallout, the MS uses a .44 Magnum. In the book, the Mysterious Stranger is a cousin of the Devil and helps the main character in sinister, round-about ways that the main character is unsure if he wants or not. One of my favorite books. It's like Fight Club set in the 1600s written in 1900. If you could ask Christ Taylor for more info on what inspired him that would be awesome, because No. 44 has always been one of my favorite characters/books, but hardly any media ever references it.
This remind me of the GOAP arciteture for AI whereby you have coded Actions like "Go here", "Turn to the Right", "Do animation" but then you have Plans which are essentially a scripted list of these Actions that the AI iterates through until a failure condition or until the Plan list is completed. The benefits are esentiaaly the same as building scripts out of rules because it becomes very easy to build new scripts and also debug as well since you just need to check the script logic if you know the rules are sound.
@@christophernoneya4635That can be addressed by having an arciticture which is a hybrid blend of a state machine and GOAP. You use something akin to a Director AI which assigns a GOAP intended for a very specific group of behaviours. I call them Role Orientated Action Planners because they don't do everything the Actor AI is capable of but do everything needed to fullfil a specific role the Actor has (healer, bystander, attacker, ect..) so for debugging purposes if you see an Actor not behaving as intended you just find what Role it is in and check the scripts associated with that ROAP. This approach also permits complex group behaviours as you can have the Director only permit so many Roles to be assigned to a known group of Actors, very much like the AI token systems you're starting to see used in more recent games for dynamic difficulty.
@@christophernoneya4635 At the same complexity, it's easier than the alternatives. It's just that there is the symptom of "Lifestyle Inflation, but for behaviour complexity": If you see the GOAP trees for some AAA games, they're MASSIVE. Yes it's for sure difficult to debug - but it would be worse if it was a behaviour tree or a bunch of if-statements distributed over several places.
This is a design architecture separate from scripts as the video was talking about them? I thought this was just "scripting", because that's what I'm used to in the terminal (I use Linux and I've come to love the terminal/Bash). In Bash, all your scripts are just programs that exist somewhere and are run one after the other, themselves running in and acting on the operating system. If they have any external state at all, that's on the OS to handle. It's actually caused performance issues because, before Bash 4(ish?), there was no true expression interpretation built in to the shell scripting language. You ran a program that tested the expression and returned a result, but that came with all the overhead of running a separate program.
@@mage3690 GOAP is just a mental framework we use in scripts to design NPC behaviour around in which we organize NPC behaviours into a number of Actions, we set a goal then sort possible actions to achieve said goal into a treelike structure and use AStar pathfinding to find the most efficient one given our parameters, for example we might give walking a higher priority than crouching so an NPC is more likely to walk. The complexity comes from edge cases where for example NPCs may prefer to crawl under a gap in a fence then walk around it making everyone look insane, it takes a lot of tweaking and checks/special conditions to make it seem reasonable and makes tracking down issues quite complicated despite it looking more modular at face value. Also state management gives me anger management issues. I'm not all too experienced so probably read an article about it, but it's uncommon to find any purely GOAP NPCs anymore
A great talk! I felt a sense of familiarity, as these are exact things I've had to figure out in my own journey as a both programmer and a game designer. I recently replayed Fallout 2 and noticed how some towns (Vault City and New Reno especially) had NPCs react to player going through containers, berating the player (and attacking if messing with them too much) while other towns did not. I immediately thought that was most likely a case of an ambitious area designer, scripting in stuff that should've probably been handled in the game systems code instead.
I could see how many people would've thought about making this video and went "These examples are too vague, nobody's gonna get them anyways", but this is exactly what many explanations are missing: great examples and clear opinions. I didn't even need any context to understand your examples, and I'm not even a game developer. I wish more teachers would say "This is the best way I've found, but you're free to look for better ones" instead of either saying "This is the way it's done" or "Do whatever you want". There's too much dogmatism and too much ideology in a supposedly technical industry.
This reminds me that in NWN NPCs were not aware when you already had a quest item / completed the quest. So you talked to them, accepted the quest and then immediately talked to them again to finish the quest.
In short: prioritize data and data transformations over event-driven design. Colloquially, push IO to the edges of your applications. Increased predictability is directly correlated with increased stability.
There is a lot for me to digest: 1. Why YT took me this long to suggest this channel? I deserve the right to binge this faster than I can binge-eat a pack of figrolls 2. Both my game-dev and game-player sides are crying with joy - he hits some good spots about game architecture that are definitely lacking in any modern-ish game (I blame newer engines - they all favour scripts over code). 3. The fact he is not making obscene quantity of money coding games is a proof of how games nowadays are subpar 4. His office RULES - this will be my inspiration if I ever find a suitable place to call "mine"... 5. Also, his patience talking about those topics. Instant role model for me. I spent decades trying to calmly discuss "questionable" coding decisions through out my career.
I believe I'm correct when I clarify that in "code" vs. "script" it's systems/engine vs. per-item/area scripts; many game engines use scripting languages to build the global, system-level mechanics.
I was also confused about this. First relevant google result says that a script is a program/sequence that is interpreted by your code, instead of the CPU directly like a programming laguage. So e.g. if you have a dialog tree in a JSON file. In that case, I guess game engines are technically wrong, when e.g. Unity calls a MonoBehaviour - a "normal" C# class - a script. And this video also makes a lot more sense with this interpretation.
@@raphaelschmitz4416 What exactly constitutes "code" vs "script" in a technical aspect (compiled vs interpreted) is a lot fuzzier these days than it once was. I'm pretty sure he was just using those terms as shorthand.
@@MuffinMan_Ken Could be the most relevant google result, could be how you chose to interpret it. I personally wouldn't use the word "scripts" to describe per-item/area code.
I love principles like this. It's interesting how often the concept transfers. You can apply it (assuming I grasp it correctly) even to CSS in web: general styles until you really need to be more specific, but keep specifics low when possible and not costly (i.e. performance).
Great video that a noob like me could follow along with and understand, and that deals with something I feel is a big problem in many games. Thanks for sharing!
My school has been really tough to find the right degree for 3D animation and game design but I finally got a degree that accounts for coding, 3D modeling, texture work, nodes, rigging etc I had to work for hours upon weeks of phone tag to get the constantly updating site n what not planned. Finally think I got it though tried to get ahead of the game by reading some books on coding looking at some online training too I couldn’t have found the interest or part of the degree without you! I see how much extra work I’m adding but I’m glad I was not feeling like I was challenged at all with my degree it fizzled out quick so it’s good to feel like I’m getting all I need to make whatever indie game project I want cuz that’s where the money lies and I think I’d like working in the game industry just as much maybe even more then animation nowadays in some even though I’m a cartoon animator front and foremost making a game is looking like the best option to make income after school honestly your really lucky 3D bleeds so heavily into game design so I can now get the best of both worlds I really appreciate these vids though just know you had a big influence on the degree path I chose to go on!
I think there's definitely a balance to this. I see many people on game dev subreddits making "systems" for everything. I think you should ask yourself each time if you really need a system for every feature of the game. Some of the "systems" people are making are just things the game uses just once in some way. For example, you may not need a general elaborate procedural animation system for your first person model, you may just need a procedural recoil and weapon sway script. As I was watching the video I was thinking to myself "it seems by code he means systems and by scripts he means code for specific situation, but the video would make a lot more sense if he defined his use of those terms first" but then i saw the pinned comment and see you've already clarified heh.
Scripting issues are why I can only enjoy Larian’s games to maybe 80%. I have the “programmer’s eye” like the designer’s eye you often talk about (not sure if you call it exactly this). Their games just have so many scripting issues while bg3 is less so but still gives similar vibes. This is somehow not an issue in other story heavy games / CRPGs, even they also are filled with bugs. I don’t really know why tbh.
How would you say that this manifests? I have no real frame of reference for it since I have no programming experience, but I'm still curious about what you mean.
@@jonah8168 well, when you do things a certain way and something breaks because the game wasn't expecting it. It doesn't do anything actually disastrous but it does break immersion if you notice.
Nice video as always! I have a question: How common is the use of automated testing in the gaming industry, and when did it first become prevalent? How challenging is it to implement end-to-end (E2E) tests in game development, and what are the specific obstacles developers face in this process?
Hey not OP, but as someone who has done a lot with automated testing, it's a much worse cost/benefit ratio. Most testing knowledge, standards, best practices etc come from the world of corporate application development. These UI apps 99% work the same way: Get user input, process it, update the screen with output. It's not so much about games vs "serious" applications, but more simulated worlds vs UI-centric applications. For example, a chess game has the same workflow, and you can test it the same way: Set up all the "facts" you need for a certain outcome, make the test suite click a button, confirm the result. In a simulated (game) world, the whole idea is that all the actors do stuff at the same time and can influence each other. And the complexity usually comes from these interactions, not from the logic inside a method. If you look at the simplest E2E tests, like "Confirm that the player can jump 8 units high"; they are already quite complex to set up. Add to that the fact that iteration is the name of the game (no pun intended) in gamedev, so you're adjusting stuff all the time... and now you just have a second place where you need to do that. Now, unit tests, OTOH... are also much less useful than in UI-centric applications 😋 but at least there are _some_ wins here. A game probably has some parts that are non-trivial pieces of pure logic, and those can be tested like just any other unit tests. In a simple health system, a test like _"I have received 8 damage, make sure health is reduced by 8"_ is probably more effort than it's worth. In a more complex version, a test _"I have been hit with a weapon that has 8 fire damage and 5 poison, I have 50% resistance against fire, make sure my health is reduced by 9"_ has a _great_ cost/benefit ratio.
Hey Tim I’m an aspiring game designer looking to get more code in my games thank you for explaining the boundary of both code and scripting, also huge fan of your games
I love how serious this got once wasteful scripts came into play, for a second I could imagine what it would be like to work for Tim and having presented a terribly made questline!
As a person starting to learn game dev and doing a few projects in UE5 I always find your videos to be very informative and give me motivation to keep moving forward, so thank you for that. I would like to ask about your opinion on the initiative "stop killing games" .It tries to start lawmaking process about preservation of online games .But the more I read about it and what it tries to achieve the more confused I get as to what it's actual goals and reasons are. There is plenty of black and white discourse on social media and it is always extremely one sided without much consideration of what the other side is saying. I think it would be interesting to hear from a perspective of game developer/director.
UE5... you've picked an interesting engine to start learning with. Great for larger teams, but hard to make anything meaningful with it solo - unless you're making videos, anyway.
That's pretty much boardgame design in a nutshell. Rulebook has all the rules, then all the cards and player powers break those rules with exceptions of their own.
I think a great example of this in action is Dishonored- there's so much that they *could* have done as scripting, but they went with code for a lot of it which enables a lot of emergeny gameplay.
Hi Tim, you've mentioned game AI in many videos. Bad AI is a common thing people complain about when it comes to games. What are some of the strategies to make it believable?
I think modularity is key in software / video games. You can reuse a lot of code but sometimes your NPC or whatever can just store the offset of the regular NPC object. From a robustness, performance and memory stand point I'd always try to create a simple interface / base object and only modify a special instance of it, but idk about quest setup
This is at its core fundamentally about, what to standardize into a reusable abstraction/template and what not. Warning totally different domain incoming... One good example from me personally in a system administration bash script: I could have decided to copy and paste my specific type of ssh command to every position i need to use it in and it would have worked at that initial point of time maybe, but instead i created an abstracted function for running this specific type of ssh command, because I knew, that this core function would have to be easily modifiable in one place to enable future maintenance. Choosing the no abstraction route in this case probably would have locked me into some kind of position, where i would probably try to minimize touching these parts of the code ever again.
As someone who has no background on programming/development but still enjoys watching these videos, can someone ELI5 what coding and scripting are, and how they're different from each other?
In traditional programming, code is a compiled program executable. Usually it's programmed in C, C++, or C#. Script is an interpreted program file. It's programmed in .BAT or .PS (PowerShell). (Windows examples given for simplicity. UNIX style platforms have different file types. And cross platform languages like Java and Python are the same everywhere.) In the game dev world, the difference is a little muddied. A compiled C# file might be referred to as a script, because it's a single file attached to a game object. A script might also be interpreted and written in a language like Lua, which can also be attached to a game object. The word "script" is used from a game designer's perspective rather than a programmer's perspective. I think what Cain is calling "code" is the general platform and he's calling "script" the business logic. The platform code creates the world, defines the physics, defines how all doors, all vehicles, all weapons, and all NPCs work. Without scripts, all NPCs would behave the same way and say the same things. All doors behave the same. Etc. By attaching a one-off script to a particular NPC, it would change their behavior to say and do specific things related to the context of the scene. Attaching a one-off script to a special door, might make that door behave differently such as produce an effect tailored to the level and game story. Cain is saying don't try to build the platform from one-off scripts, because it turns the game into a non-deterministic mess. It's impossible to plan for or predict game behavior without a consistent baseline platform to build on top of. This can largely be avoided by using a game engine such as Unity, Unreal, Godot, GameMaker, etc, because they have provided built-in code that runs the physics of the world you are creating. However, Cain's advice may still be applicable if the game is large and expands greatly upon the built-in code. For example, one might develop a currency and market system into the game, which the game engine does not provide. You could say the currency and market system is fundamental to the game so it should be implemented as "platform" code that defines how currency and market works everywhere in the game. A script in this case would be an exception such as the player purchasing in-game currency with real world credit card.
Totally, with one addition that it's a good idea to do some code in a scripting language rather than hard-coding it. That's easier, makes the game more moddable etc.
6:47 I'm not a game developer, nor any kind of SWE... but I've played around enough with some game engines to understand that running scripts every single frame is to be avoided if at all possible. Heck, I've only ever taken Intro to Programming and Data Structures courses, never anything more advanced (and those were 20 years ago) - and even that knowledge is more than enough to understand how brutally inefficient this would be! Holy smokes, I thought the people who coded gameplay were all hired after passing through the blessed gates of DSA and Optimization. Maybe they were just burned out due to crunch :D
Yeah, some of those are classic. I remember one game where if you didn't destroy a light you got detected and lost the mission when trying to enter the building. OTOH if you went around, killed everyone, and came back to that light still intact - you still lost, even though there is no one to see you in the building.
I have always wanted to write a sophisticated script engine for interacting with a program. I'd love to see a full video that is entirely about the process of writing script parsers! How do you handle parsing? How do you decide on syntax? How do you make it interact with your built in classes? (I believe the scripts in fallout are even compiled into bytecode, how do you handle compiling and executing that?)
Hmm, explaining the entire process of making a scripting system is probably beyond the scope of this channel. It’s the equivalent of asking “how do I make my game multiplayer” or “please teach me linear algebra”. It’s a short question with a BIG answer with lots of “it depends on your game and your needs”. Have you watched Arcanum Scripting? ua-cam.com/video/coPkWyJIl-M/v-deo.html
At this point, you probably just want to use Lua for scripting rather than building the whole thing from scratch and expose a set of hooks/events that the scripters can attach scripts onto. It's not really worth building your own language.
Many modern language support "scripting" by default, so you don't even has to use a different language at all and can use the same language for the game "core" and "scripts" which has many benefits.
This sounds like a solution in search of a problem. Usually, a script system is there to speed up an often-repeated task, or to allow a non-programmer (story writer/level designer/etc) to work on the game. Basically, when you have specific problems, they will point to specific answers. E.g. for simple dialog trees, YAML or JSON syntax is probably sufficient, saving a ton of work.
What would you say is the different between scripting and code? I ask as I've always seen them as basically the same thing when in the context of working within a game engine like Unity.
There isn't a clear distinction in Unity, but if you want to apply this mindset, try to avoid creating c# files that handle specific cases (hard-coding). Like, if you want the player to lose health in a toxic cloud, and this isn't the only one in the game, don't make a script called "toxicCloud", which subtracts 5 health every second from the player if the player is in its collision volume. This would be a "script". if you want to code it properly, in the code for living things, run a function upon entering a collision volume. If the volume is flagged as toxic, emit an event and pass this living object's reference, the status effect enum for toxic, and "true". In the status effect handler, upon receiving that event, add that living object's reference to an array of things with the toxic status. If the player enters two toxic clouds, their reference is added twice. Every second, for everything in the toxic status array, change its hp += (toxic dmg * its resistance). When a living object leaves the volume, a "false" event is sent, which removes this living object from the toxic status array. If the living object dies, send an event that removes all its references from the status effect handler. This is more complicated than the first "script" option, but it is so much more reusable and will save time and prevent bugs in the long run.
@@jextra1313 I try and follow a modular approach like this as much as I can anyway. I appreciate the explanation though as is does help clear things up for me alot I think I understand the difference now.
@@jextra1313 In your example, if the object disappears (the cloud ceases to exist), with the first solution of the toxiccloud script, it works immediately. With your system of collision sending an event, you have to also think about objects vanishing and thus add some code. You also have to think about what happens i the player IS in the cloud without entering it (the cloud gets created, the player is teleported). So... I think you have it completely wrong here. If a player can teleport inside the object, or the object can be teleported, you have to take these into consideration. Your proposal is about hard-coding some solutions ("entering the cloud"). That's exactly what Tim says not to do in his example of a guard seeing the player vs. checking if the player is an area and then adding rules to it.
@@LDiCesare In Unity, collision volumes check every frame to see if there's a new intersecting collision (OnCollisionEnter) or a collision stopped intersecting (OnCollisionExit), so it would work even if the player was teleported or started the game within the cloud. What Tim warns about is having a checkpoint being the door, when you could just hop the fence. A volume would be the solution here. I was trying to frame my explanation as 'create a unique script for every interactable game object' vs 'create reuseable flag + handler code' but it became more complex that I wanted
In that case you'd probably have some methods on a script that goes on every character/item/etc. That's code. And unique objects maybe inherit and override that. That's a script. It's not literally code vs script, more like systemic vs individual in that case.
@@Sauvva_ they used compiled scripts. And for fallout 2 there's an official compiler, source code for original scripts and several modern fan-made editors specifically to write and compile SSL ( which i believe stands for Star Track scripting language (: ) and they support sfall scripting extensions.
It's funny, my only 'development' experience is running a server on Conan Exiles. Some mods allow us to create quests and scripts and NPCs, if I want to add anything more complex I have to create a script. And it is all in-game. I haven't tried actual modding yet. Even without the ability to change code, there was still good advice here. Maybe in a case like mine, the concept of master scripts and subscripts becomes more prevalent. Core scripts which act like code, being referenced by subscripts whenever needed. This way, while I am still scripting everything, I can enforce rules that can account for these other situations without every one of them having its own script. So, the guard can have a unique script for his quest or w/e if needed, but otherwise obeys the master crime script that only triggers as needed, and jumps to the relevant part of the script depending on how it's called. Even though the game is in UE4, in my environment inside it I have to do everything with hand placed triggers or interactables. Interesting live-game development scenario!
I have recently started game development but I have been studying computer science for 2 years at this point. What's the difference between coding and scripting in game development context? I suppose it depends on game engine you are using but in godot for example there is this tree node system with scenes and you have to attach scripts to specific nodes for basic functionality for example for movement of a player and so on. Is there some sort of distinction between these 2 terms? I have always considered them the same.
Great video. I was wondering if there's also an audience component eg coding being more of a programmer's tool and scripting a non-programmer's tool? Could the difference between coding and scripting get fuzzy in certain environments eg unity?
Hey Tim! Most of this video reminds me of putting together a "finite state machine" for player and non-player controllers. I have played around with simple state machines to handle animation transitions and very rudimentary NPC AI, would this be a good way to conceptualize the central point when using a pre-existing engine? Having a de-centralized state machine for the player character in order to handle the plethora of potential exceptions to the "idle" state of the character and a centralized state machine for different NPCs' behavior? While listening and typing this question, you started bringing up the "conditions" in NPCs that also sound very similar to how I understand finite state machines! Thanks as always for your insight!
I have a couple questions: The only scripting experience I have is with Unreal Blueprints. Where I'd create an API with code, and then the designer uses blueprints to script up some behaviors. How closely does that scenario relate to the content of this video? For example.. You mentioned the "NPC death but still talking" issue. Do traditional scripts not have access to game state? In Unreal blueprints, you would just early out I'd guess if the NPC was dead? Another thing is the "on tick" check. In Unreal you'd use events to trigger stuff like this. Would you actually check every tick in a hand-rolled engine? Seems like you'd just fire an event and cache state somewhere if the event wasn't relevant at the time. Totally valid though to add fundamental mechanics to the game itself in code. "Don't repeat yourself" should resolve that issue. And then the other thing I got from this video is.. We should think about the implications inherent in where we put the script. If you put a script that triggers a quest when someone enters a door, what you're inherently saying is, "This quest is impossible to trigger without walking through this door". Put in another way, you're saying, "In deeply care about HOW the player enters this room, to the point where I will block the player from progression should they enter in another way." I think that's a good headspace designers should be in when implementing things like that.
I really enjoy watching these technical explanations and seeing the common sense behind the decisions. I do wonder, what is your opinion on test driven development when making games? I see many games that have clear technical issues, regressions or have issues with patch cadence due to what I suspect is unmaintainable code that is not properly covered by tests, effectively a frozen codebase that everyone is too afraid to touch as if they shake the tree too much it explodes, crashes and burns horribly. I don't get why all interactions are not written with tests first, where game mechanics are tested with one function calling another, decoupled from rendering. It could run without a UI, testing the interactions, such as triggering different states and testing if that quest is still completable in specific scenarios. And when a bug is discovered, a test case should be written first, followed by a bugfix to avoid regressions in the future. I get that people have deadlines and crunch may be needed at times, but if it is not done properly the developers are just digging their own graves filling it with more technical debt until it is simply too much to bear and the thing becomes unmaintainable, innovation no longer being possible. A long post, but if you ever read this and get to cover it, I am really lookin forward to watching what you think in a few months once your queue of other questions is processed.
How does this division between code and script work if you're using an existing game engine? On the one hand, everything you're writing is technically a script. On the other hand, I guess there's still a difference between code/scripts for general cases and scripts for small specific changes (like, general enemy AI, and then one enemy that behaves differently during a quest?)
Unreal is a good example. Your programmers can change the engine using C++. And anyone can write a script using Blueprint. I would recommend keeping that distinction, where rules are coded and exceptions are scripted.
Thanks for the insightful video, but it leaves me wondering: Why script at all? Is it a budget thing where you want folks other than the programmers to be able to implement logic? Would you recommend staying away from scripting completely if that wasn't a concern? Like on a small indie team where everyone happens to know how to code?
I'd argue there is barely any reason to "script" anyway nowadays, aside from visual or node-style systems. The additional API boundary creates a lot of unnecessary complexity that you gotta maintain, instead of just fixing the problem directly in a high-quality programming language with proper performance and tooling support. No need to reinvent the wheel. You can do hot reloading in any language you want, even with compiled ones. Just hot-reload a DLL with gameplay logic when it changes. I've done it that way for a while now and I'll never go back to a separate "scripting" language. The core concepts of this video still apply, though. Don't structure everything based on the exceptions and make sure the core rules are solid first.
the only and main reason for scripting is to move some of the load from senior coders out to scripters on scripts, things can change on the fly without the need of too much planning, while code need to be documented properly also they can mess and experiment with scripting and, if something goes wrong, only a small portion of the game will break while they can not be trusted to handle the code, where a small error can brick the whole engine, where an introduced bug can take weeks to show up, be discovered and get fixed
@@giampaolomannucci8281 I see the appeal of having less technically versed people write some gameplay logic, but in my experience it always tends to balloon out, to the point that it ends up being ported to the core eventually anyway. I'd rather put the work into making working with the real programming language better, so it doesn't end up having to be rewritten down the line. It also avoids a lot of performance issues that scripting often entails.
The reason to use scripting isn't that you can have less technically adept people working on it, but that you can iterate more quickly. Scripts are for parts of the game that aren't performance sensitive but have to be changed on a whim. Forcing people to work on that kind of thing in C++, C#, or some other compiled language is painful. Also, it means now you have a tonne of extra stuff that needs to get built as part of the main binary's build pipeline. No, unless you're writing something with very fixed behaviour that doesn't have weird interactions between different entities, you're best off using scripting.
ooo this is a good topic, as a programmer I often struggle to draw the line between core system mechanics, and mechanics that should EXTEND the system mechanics. Like, should stun be a debuff? or should their be a specific stun field on the players struct? and sure that might be an easy question but you have to make these decisions constantly
Whether scripted or coded directly into the engine, your first focus should be systems and their respective rules. Having guards react and do guard logic will almost certainly be a script, but it'll be a single script used by every guard that overrides portions of a more generic AI Script, which deal with most of the top-level logic of their actions, and hooking into engine code to do things like Line of Sight and pathfinding. Ad-hoc scripts - which Tim is REALLY talking about here - are for rare or one-off cases, e.g. for specific guards you might add a trigger so they notice a specific item they are supposed to guard went missing to hook into the generic AI script to make them go searching for the player.
First relevant result in google says a script is instructions interpreted by your code, opposed to by the CPU directly like your programming language. Like having a dialog tree in JSON. And bigger games have script systems for far more than that, because a lot of non-coders need to work on the game. Anyway, video make much more sense in that context.
I have a fear of talking to NPCs with my inventory full: what if they will want to give me a quest item, it will not be able to fit into inventory, nobody accounted for it and quest item will disappear forever? 🙂 I don't remember what game induced this fear but its my faithful companion in all games with inventory and NPCs
I wonder if Tim is looking for bugs in his consumed games only fellow developers are keen to. And whether he reports them. Does Tim sometimes decompile parts of foreign games (in secret) and looks into them? Does he in general wonders how some games features function and tries to learn how they work?
How do you manage the difference between code and script ? OR maybe more importantly, who decides if something is a special case that would require script vs a general action that would require code (changes) ? I have follow up questions, but they are getting more into project / bug fixes management
Practice writing rulebooks. Put together the rules of the game before you start making the game. This will give you an idea of what should be done in code and when you encounter something that could change the rules you can ask if you need something unique for the moment (script) or if you need to add a new rule. Can the player run, jump, sprint? Are you going to have status effects that change their values? Then you get to a scene where they're in mud and you now have to make a decision. Do you want to make the mud apply a status effect (if you added this to the game rules) or will you script in logic to reduce player speed or will you add a new rule based on the terrain the player is on because you want to use it more than once.
Hi Tim. Could you clarify something on a technical level? What do you mean by 'script' vs code? I'm currently working in Unreal, though relatively inexperienced, so in that context. Is it more of a 'one-off' piece of code on a specific BP? Or is there some actual, built-in (non-asset) way to implement some sort of additional layer of logic via a scripting language? You can also explain it in terms of Unity, but tbh I don't know how much I remember.
It's all scripting in Unreal. That's one of big downsides of general puprose engines. Granted, the scripts can do *a lot*, but it's still all scripting. In a specific-purpose-made engine (or at least, the one you're modifying the source code of), you will put your rules in "engine code", and have your engine maintain them as they would any other system, but then also invoke scripts if there is one attached. So, your regular enemy behaviour would be all part of the rules, but then your boss with it's modification to that behaviour would be a script. In engines where all you do is script (Unity, for example), you have to make scripts that track other scripts, as a hacky workaround to building rules and exceptions. Depending on what game you're building, it may be worth to explore engines beyond the "Holy Trinity" of Unreal, Unity and Godot, and find something that's more specialised, and play around with them for a bit. Like idTech4 for fps, GemRB for RPG, etc.
An actor is always an actor. It's loaded, accessed, managed by following the rules of the engine. What you add to the actor is their script. If you make a library separate from any distinct entity to handle items, (drop tables, affix rolling, how it can be equiped) then in that case you're writing the rules. Then you can write exceptions to those rules into the individual items (actors) themselves. Maybe you don't need to go as deep as writing a full blueprint and instead simply set certain flags or values on the actor itself. Essentially, the gun itself should not declare how it should fire, it should tell the rulebook what stats it has and then the engine will know what to do when your character says it's firing the weapon. Unless it's a very special weapon that needs an exception because it's used to blow up the entrance to a specific dungeon. After reading a few other examples think of it this way. D&D handbook is a set of rules. Those rules determine how things happen, but the players and DM run their own scripts and the outcomes are based on those rules. Each player has their player sheet which holds all the modifiers that can be applied to their actions, but they don't each of them hold the rules for the action, those are in the handbook.
I’m just guessing here, but could it be that some games rely overly on scripts because it’s easier/quicker to iterate and work on, on the fly, than code? And then nearing launch when perhaps you should be moving some scripted functions/solutions into the code, you are busy fighting fires and squashing bugs, so it never gets done. I’ve never shipped a game but that seems like a likely trap I could fall in
Very nice! I would like to know more about the differences between code and scripting. I am not sure I understood entirely. Does anyone have a video explaining these concepts?
Code: "The door must be locked before leaving the house" (establishes a general rule). Script: "Ensure the lock is turned clockwise three times" (provides the specific steps to fulfill that rule).
@@FractalPrism. got you! That makes sense. Another thing, I noticed someone talking about programmers that only code VS programmers that only do scripting. Is that a thing? Are these different roles of programmers?
Hey, Tim. I have a question for you about the development of the Outer Worlds (and games with sequels that you took part in): How much time of the actual development was spent on engine / tooling / mechanics / etc while making OW1 and what do you think it will take to make OW2? To clarify my question: I understand that when you made New Vegas, you had a complete game of Fallout 3 to build your game above it. So you have reused parts of the Creation Kit, dungeon builder, RPG system, stealth mechanics, you didn't need to code the stuff that will prevent assets from despawning if player dropped them, and so on and so forth. With Outer Worlds, however you had to build all of this stuff from scratch (and many of the things just didn't make it) that I wonder: How long did it took to build your game's "framework" that allowed you to actually build a game? And how the fact that you already have all tools and game's systems in place do you think will affect the development of OW2? Thanks.
I did not work on New Vegas and in fact, I started at Obsidian after it shipped. Also, I cannot answer questions about TOW2, even ones phrased as TOW questions, e.g. "what features do you wish you had had time to add to TOW?" Because those questions directly relate to what we are doing in TOW2. I can answer how long it took the get the game framework in place. Since we had the vertical slice done in one year, we had the framework in place faster than that. I'd say somewhere between 8 and 10 months. The VS was the first "final" content we made with that framework.
@@CainOnGames I didn't want this sound like i'm extracting the information about the upcoming game, I'm just curious about how much time (in percents o r whatever) did "frameworking" "steal" from the development time of TOW and how much of it will be "given back" during the development of TOW2 literally because of the time spent on this it TW1. 8 to 10 month for a tooling like this for an RPG of this scale is very impressive. thanks for the extremely entertaining videos. vertical slice one is awesome.
Can someone help me understand. I thought scripts were effectively just like complicated functions that are called at runtime instead of precompiled. Is that it or is there more to it that can cause issues?
You've put into words something that's bothered me since before I even knew what scripting was. Nothing kills my enjoyment of a game faster than doing something that should finish a quest, but the rules not supporting it. Too many times have I found the quest item, or figured out the mystery, or found another way in, or whatever, and the game broke the quest, or worse, made me backtrack and redo it the 'right' way. This video should be shown to a certain famous developer in particular that is extremely bad about this and has made me frustrated in their games for decades.
I guess it's valid in any time of code, not just only game code. Try to minimize the corner cases and abstract away as much as you can so you don't have to re-write hundred of lines anytime you want to change a feature
Yes. And that can include engines that can't be coded and only provide script hooks, like Unity or Godot. Make one script that handles ALL doors, for example, and let a few individual doors do their own thing.
Funny, something mentioned in this vid is a question that's been chewing my brain for about a week: Mr. Cain, how do you feel about your games being speedrun and have you ever used speedrun glitches people have figured out to fix things in a patch? I've seen other creators watching speedruns of their games and I love hearing their thoughts on what they see 😊.
I'm very new to coding and making games, so forgive me if I sound stupid. I understand the idea of having big rules governing the game, and having exceptions for little things. I just don't get what you mean by code, and script. Aren't these the same, or am I missing something?
I think it would have been nice if you had formally defined "Scripting" and "Coding" in this video. At some point you mentioned interpreted vs. Compiled languages but you also alluded to "applying" a Script to a specific entity in the game, leading me to think more like a component system vs. plain code files that knew nothing about the engine.
I forget who said it but someone said "scripting is too limiting for programmers and too advanced for level designers. Scripting is the worst idea and the worse for both worlds. Make code all real code so programmers deal with it and level designers aren't writing limited bad code." As a programmer I find scripting cool, but I'm curious what you think of this quote I heard. May have been from Pirate software-that long hair guy who says he and his dad worked at Blizzard.
Yeah talking unreal, " Add event dispatcher ENEMY SPOTTED " If on enemy spotted talk " hello world " the NPC says and yeahs it is fun BOOM Feel the loom!
To clarify code vs scripts:
Code - a set of instructions, usually compiled and often part of the game engine, that is used by all objects of a particular type, e.g. doors, guards, etc. Code is usually written by programmers.
Script - a set of instructions, usually interpreted and often in a different programming language from code, that is used by a specific object and often attached to it. Scripts are written by anyone on the development team.
Some commercial game engines separate code and scripts (such as Unreal, which has blueprints for scripting but allows programmers to rewrite the C++ engine code) and others do not (such as Unity which only allows scripting). In the latter case, it is still a good practice to keep general and specialized scripts separate, with one set of scripts that all objects of a type use and separate scripts that individual objects use.
Just to make sure I understand, coding is basically creating the content of the classes, defining how a door for example would behave, but scripting is putting another piece of code on top of the class code for a specific object/instace of said class, because the door in building A needs to behave slightly differently?
I don’t have game dev experience, but I’ve worked as a software developer for the past 6 years, and I’m just getting into game dev, so I’m not sure if I understood correctly.
@norberthresko8154 What i understand is he mixed few points.
He talked about the efficency of compiled code vs external instructions that are way slower and heavier, but also easy to customize without the need of a recompilation or touching a code in a messy way. That mean u dont really want to implement behaviours etc in the script, You just want to do the "basics", make a character aproach the player, or run away from him, maybe in a very weird case run a cinematic... but if it involves gameplay logic, shouldnt be there. (like branching selecting cases of storylines). That should be somthing desirabe to be done intro the game engine and not the scripts.
Dead guards shouldnt even have a behaviour anymore (atleast, if hes truly dead and not a zombie..) its a waste of resources... you may want the corpse still there by changing/switching the object, or just dissable his IA, ticks etc and may just leaving a ragdoll or even not that... but for the one whos alive, all the checks to do before execute the script should be coded in the game instead of useing external scripting.
Enhaced Princess example: you resque her and bring her to safe place. mission succesfully acomplished, but If you let a scripter do all those checks out the game logic when you talk with the one whos going to continue the story, or reward you for it but somehow the princess dies before you talk with him, and his scripts do those fancy checks you will get a mission failed, and in worst scenario a bricked gamesave.
External scripts should be called on last resource. And most if not all pre checks to decide if the script should be called or not, should be in the object functions, OnTryPickup, OnPickup, add variables/properties like CanBeDropped, CanBeSold, or if u want it easy isQuestObject to ensure you cant drop/transfer/sell it, or in case of sneaking in a room, add a collisionbox that starts the "watchdog" function running in a behaviour like "if hes noisy enougth, or if a guard see the player and hasnt enougth stealth to be undetected, or he isnt in a shadow... then trigger X event. This X event could have a interface that after check whatever is suposed to check, THEN run the script or override the game logics.
Also in case of sneaking intro houses, may be better to use a onActorBeginOverlap instead of implementing on each door/window/whatever... player could bypass those more specific things with somthing unpredicted like glitching a wall or digging a hole.
its about good practices and organized/ well planified events and flow. Atleast, thats how i understand the thing... maybe im wrong as i never been a pro programmer, just a autodidact 100% as i didnt even finished the basic school, also english is not my native language. So i hope my point is accurate and understandable enougth.
@@DoubleMotherLess Thanks for the explanation but I still don't get it 😅 It might just be because of my lack of gamedev knowledge/experience, but I don't understand Code vs External Script. In my mind why wouldn't you just do everything in code? (still not quite 100% of the meaning of in code vs in script). What is External Script? You code your logic, and someone else comes and puts a script on a specific NPC object to override the basic functionalities? Why is that a thing people do? I guess this "External Script" is very game engine specific, because I just can't comprehend it 😅Also, if someone can just overwrite the basic logic, why not then just create an extension point, where the scripts can be run by overwriting that extension point in the script, but still is controlled by code?
I would be very interested to have a discussion about this, but I feel like I lack some crucial information that would help me put all of this into context.
The reason you have scripting in RPGs is because many of the rules have exceptions, and those exceptions have exceptions, and those exceptions have exceptions, and so forth. While a programmer could write all of those rule exceptions, they are frequently on just one or two objects, so placing an override script on those objects is cleaner than having code cluttered with additional checks that fail 99% of the time. Also, explaining to a programmer those special cases takes time away from other features they could be coding. Hence, scripts.
And you are right about extensions. I talk about such attachment points in my video on Arcanum Scripting
ua-cam.com/video/coPkWyJIl-M/v-deo.html
Im a chef. Im not a programmer and ive never worked even remotely adjacent to video games, yet for some reason i find these videos endlessly fascinating.
I'm in property management and think the same thing. A lot of the lessons are things that could be applied across industries, experiences that are more universal than just the games industry. It's also fascinating as a gamer to get a glimpse behind the curtain as to how the games we love are made.
I appreciate this comment, but don;t think that just because you're one profession it means that you're not allowed to learn a variety of other things. Your knowledge can include a wealth of other things not related to your current profession.
I always use the videos to think about my non programming job. Its just good philosophy.
As someone who’s been learning GameDev as a side hobby, these videos are immensely useful. Tim is so good at presenting an abstract concept and breaking into component parts.
Tim's really good at giving talks.
I've have good example of "not coding the rules" that I'm surprised you didn't mention - the car in Fallout 2. Either Chris or Josh told me years ago that they when they went to add it, they didn't have a programmer to do it available, so it was all done in script as an additional party member. The result was a LOT of bugs - disappearing car from some locations, incorrect player counts in other scripts on a map with the car, etc. etc.
I did remember losing that car in Fallout 2 😂 Somehow it’s just a fun memory now
You do know Tim left in the beginning of Fallout 2? So he probably had nothing to do with the car
@@ZiggyMeister he didn't say Tim did
@@ZiggyMeister Which is one of the reasons I mentioned it - another being that it's an example much of this video's audience will be familiar with. Had Tim still been there on F2, I am very sure he would have immediately said "this needs code support" the moment adding a car was brought up.
look at Tim's little head next to your name, it's so cute :D
thank you for supporting the channel
I usually explain this same principle as "Engine should handle systems, scripts should handle content", but your phrasing is a bit more concise. 🖤
I like your version - very neat and easy to remember... But "systems" and "content" can be misused fast. I can see myself saying "that's not what we mean by 'content'"
This is certainly one of the videos every programmer has to watch, extremely insightful I must say
And his logic can be applied outside games as well. Just replace "script" with "workflow engine" or similar and boom. Business version covering the same topics and issues...
@@ecosta And even if you don't have a scripting language for your game, you can separate code meant for core mechanics and code that extends core mechanics.
For instance in a game I was working in, you had status effects, I had lots of code to handle how they worked, but it wouldn't be wise to implement core systems as status effects and should instead be the "exceptions" as he mentioned
In Fallout 3 and New Vegas a "dead" NPC placed in the world with zero health is still considered alive and will still blink. To fix it you have to attach a script that kills the NPC, because there's no check in code to do it automatically if they spawn with zero health.
Yo, this is a nightmare to make "right" via scripting. Even harder if you have an engine that favours scripting over code (like most do nowadays). Imagine if you need to remember all those little details whenever you make a game, a DLC, etc?
Remembered running into a dead NPC at Old Olney with blinking eyes... as if that place wasn't scary enough.
I think every mistake he talked about was done in Skyrim.
I have several items in my inventory that I can't put into a drawer because this is a quest item.
Well that quest has been completed already, let me drop it off
I am not sure but that could be due to Bethesda is prioritizing modding. Modding is running with scripts in general for more modebility without accessing source code
@@halilsavas4808 Good point.
I bet Tim thought about Skyrim.
This talk interacts a lot with the DRY (Don't repeat yourself) idea. I can see creating a lot of scripts being a nightmare to maintain, while coding in one or two places can help the developers later on.
Cheers!
Thank you for the continued education, insight, & inspiration.
At the beginning of this year I started my Game Development/Programming journey due to being inspired & encouraged your videos & your games.
In a video you mentioned a “selfish” reason for starting the channel was that you wanted more games to play.
Thank you for inspiring me start this lifelong journey & hopefully one day I can give back by making a game or two for you to play. That was inspired by your insights.
TLDR; Thank you for the videos & the games. One day I will email you a game for you to play, as my little way of saying thanks.
I have been hounding my students about this just about every year. Hopefully they listen to you when I play this video in class this year.
(Constantly scripting logic on individual objects for core-feature events, “Do you realize how much of the CPU your bullets are using??”)
If I'm understanding right, "code" in this context is systemic logic which affects all parts of the game while a "script" is an instanced logic attached to objects? It was a bit confusing for me at first since I think of scripts as files containing code, so technically all things are scripts with code.
Yeah I'm a bit confused here too
System vs Instance would probably be better terms here
His use of code vs script is indicative of the studios and tooling he's used to not a general rule or concept, these would've been extremely confusing in the studio i worked at since A all of the code was technically scripts but B also pre compiled and as fast as you the programmer could make the logical steps of.
Not a game dev here... This is my guess. Typically 'code' will refer to what goes into the game engine and is written in the game engine language - c++, c#, etc. Changes to this code base requires recompiling the engine. How long that takes may vary but it could range from seconds to dozens of minutes.
Scripts are usually written in a higher level interpreted language - Lua is a common one. These tend to have relaxed rules and the language will handle a lot of things that lower level languages don't, but also setting things properly isolates what you do in the script from what the engine handles.
Depending on how things are set up, you could literally edit a script while the game is running, then reload the save file and the changes you've made to the script will immediately kick in. But maybe you don't have that set up so you still need to compile the scripts separately and restart the game, but you shouldn't need to recompile the rest.
The main difference between script and code is that scripts are a lot more flexible and (with enough backend support) are more human readable. You might even get some of your more adventurous game designers to get their hands dirty and write their own scripts.
The main reason you don't want to do everything in script is because it's slow. The second reason is that you don't want to implement highly complicated things in the script for all the reasons mentioned in the video.
So, its not particularly useful since you managing a high level approach with unity, godot or blueprints(only). But. As a system design method it still will help your indie game perform better, be scaleable and easier to bugfix
Infinite warrior can be countably bigger than any finite warrior. Depending on which type of infinity counts the warrior.
Cantor enters the chat…
Question/Video Idea: What was the origin story for the Mysterious Stranger? Who thought up the concept? What was the inspiration? Etc. I love that perk and the Stranger always puts a smile on my face when he shows up!
Also, is there a better place to post general questions? I can't find anything in the Community Forum (but i'm a UA-cam subscriber newb).
Love ya, Tim!
I'm pretty sure Mysterious Stranger was Chris Taylor's idea, but I don't have anything about it in my notes, so I am just making a memory stab here.
And just ask. I read all comments.
@@CainOnGames "No. 44, The Mysterious Stranger" is a book and character by Mark Twain with various depictions throughout several unfinished versions of the story. In Fallout, the MS uses a .44 Magnum. In the book, the Mysterious Stranger is a cousin of the Devil and helps the main character in sinister, round-about ways that the main character is unsure if he wants or not. One of my favorite books. It's like Fight Club set in the 1600s written in 1900. If you could ask Christ Taylor for more info on what inspired him that would be awesome, because No. 44 has always been one of my favorite characters/books, but hardly any media ever references it.
This remind me of the GOAP arciteture for AI whereby you have coded Actions like "Go here", "Turn to the Right", "Do animation" but then you have Plans which are essentially a scripted list of these Actions that the AI iterates through until a failure condition or until the Plan list is completed. The benefits are esentiaaly the same as building scripts out of rules because it becomes very easy to build new scripts and also debug as well since you just need to check the script logic if you know the rules are sound.
I've heard it's actually incredibly difficult to debug since you have little input in the actual runtime decisionmaking process
@@christophernoneya4635That can be addressed by having an arciticture which is a hybrid blend of a state machine and GOAP. You use something akin to a Director AI which assigns a GOAP intended for a very specific group of behaviours. I call them Role Orientated Action Planners because they don't do everything the Actor AI is capable of but do everything needed to fullfil a specific role the Actor has (healer, bystander, attacker, ect..) so for debugging purposes if you see an Actor not behaving as intended you just find what Role it is in and check the scripts associated with that ROAP.
This approach also permits complex group behaviours as you can have the Director only permit so many Roles to be assigned to a known group of Actors, very much like the AI token systems you're starting to see used in more recent games for dynamic difficulty.
@@christophernoneya4635 At the same complexity, it's easier than the alternatives. It's just that there is the symptom of "Lifestyle Inflation, but for behaviour complexity": If you see the GOAP trees for some AAA games, they're MASSIVE. Yes it's for sure difficult to debug - but it would be worse if it was a behaviour tree or a bunch of if-statements distributed over several places.
This is a design architecture separate from scripts as the video was talking about them? I thought this was just "scripting", because that's what I'm used to in the terminal (I use Linux and I've come to love the terminal/Bash). In Bash, all your scripts are just programs that exist somewhere and are run one after the other, themselves running in and acting on the operating system. If they have any external state at all, that's on the OS to handle. It's actually caused performance issues because, before Bash 4(ish?), there was no true expression interpretation built in to the shell scripting language. You ran a program that tested the expression and returned a result, but that came with all the overhead of running a separate program.
@@mage3690 GOAP is just a mental framework we use in scripts to design NPC behaviour around in which we organize NPC behaviours into a number of Actions, we set a goal then sort possible actions to achieve said goal into a treelike structure and use AStar pathfinding to find the most efficient one given our parameters, for example we might give walking a higher priority than crouching so an NPC is more likely to walk. The complexity comes from edge cases where for example NPCs may prefer to crawl under a gap in a fence then walk around it making everyone look insane, it takes a lot of tweaking and checks/special conditions to make it seem reasonable and makes tracking down issues quite complicated despite it looking more modular at face value. Also state management gives me anger management issues. I'm not all too experienced so probably read an article about it, but it's uncommon to find any purely GOAP NPCs anymore
A great talk! I felt a sense of familiarity, as these are exact things I've had to figure out in my own journey as a both programmer and a game designer.
I recently replayed Fallout 2 and noticed how some towns (Vault City and New Reno especially) had NPCs react to player going through containers, berating the player (and attacking if messing with them too much) while other towns did not. I immediately thought that was most likely a case of an ambitious area designer, scripting in stuff that should've probably been handled in the game systems code instead.
I could see how many people would've thought about making this video and went "These examples are too vague, nobody's gonna get them anyways", but this is exactly what many explanations are missing: great examples and clear opinions. I didn't even need any context to understand your examples, and I'm not even a game developer. I wish more teachers would say "This is the best way I've found, but you're free to look for better ones" instead of either saying "This is the way it's done" or "Do whatever you want". There's too much dogmatism and too much ideology in a supposedly technical industry.
This reminds me that in NWN NPCs were not aware when you already had a quest item / completed the quest. So you talked to them, accepted the quest and then immediately talked to them again to finish the quest.
In short: prioritize data and data transformations over event-driven design. Colloquially, push IO to the edges of your applications. Increased predictability is directly correlated with increased stability.
Dipping my toes into coding and I feel like this is going to save me a lot of headaches lol
Despite being a huge technical dummy my love of logic and debate helped make this video completely comprehensible to me!
There is a lot for me to digest:
1. Why YT took me this long to suggest this channel? I deserve the right to binge this faster than I can binge-eat a pack of figrolls
2. Both my game-dev and game-player sides are crying with joy - he hits some good spots about game architecture that are definitely lacking in any modern-ish game (I blame newer engines - they all favour scripts over code).
3. The fact he is not making obscene quantity of money coding games is a proof of how games nowadays are subpar
4. His office RULES - this will be my inspiration if I ever find a suitable place to call "mine"...
5. Also, his patience talking about those topics. Instant role model for me. I spent decades trying to calmly discuss "questionable" coding decisions through out my career.
I believe I'm correct when I clarify that in "code" vs. "script" it's systems/engine vs. per-item/area scripts; many game engines use scripting languages to build the global, system-level mechanics.
I was also confused about this. First relevant google result says that a script is a program/sequence that is interpreted by your code, instead of the CPU directly like a programming laguage. So e.g. if you have a dialog tree in a JSON file. In that case, I guess game engines are technically wrong, when e.g. Unity calls a MonoBehaviour - a "normal" C# class - a script. And this video also makes a lot more sense with this interpretation.
@@raphaelschmitz4416 What exactly constitutes "code" vs "script" in a technical aspect (compiled vs interpreted) is a lot fuzzier these days than it once was. I'm pretty sure he was just using those terms as shorthand.
@@MuffinMan_Ken Could be the most relevant google result, could be how you chose to interpret it. I personally wouldn't use the word "scripts" to describe per-item/area code.
I love principles like this. It's interesting how often the concept transfers. You can apply it (assuming I grasp it correctly) even to CSS in web: general styles until you really need to be more specific, but keep specifics low when possible and not costly (i.e. performance).
More like this Tim! Really like it when you get into how to structure things.
I love how dynamic and believable this approach makes the world fell. I think Dwarf Fortress is built this way.
I can tell by your exasperation at points in the video that you're speaking from very real experience :D
Great video that a noob like me could follow along with and understand, and that deals with something I feel is a big problem in many games. Thanks for sharing!
My school has been really tough to find the right degree for 3D animation and game design but I finally got a degree that accounts for coding, 3D modeling, texture work, nodes, rigging etc I had to work for hours upon weeks of phone tag to get the constantly updating site n what not planned. Finally think I got it though tried to get ahead of the game by reading some books on coding looking at some online training too I couldn’t have found the interest or part of the degree without you! I see how much extra work I’m adding but I’m glad I was not feeling like I was challenged at all with my degree it fizzled out quick so it’s good to feel like I’m getting all I need to make whatever indie game project I want cuz that’s where the money lies and I think I’d like working in the game industry just as much maybe even more then animation nowadays in some even though I’m a cartoon animator front and foremost making a game is looking like the best option to make income after school honestly your really lucky 3D bleeds so heavily into game design so I can now get the best of both worlds I really appreciate these vids though just know you had a big influence on the degree path I chose to go on!
Great timing for video. I am just now working with organizing blackboard and states for story and dialogs :)
I think there's definitely a balance to this. I see many people on game dev subreddits making "systems" for everything. I think you should ask yourself each time if you really need a system for every feature of the game. Some of the "systems" people are making are just things the game uses just once in some way. For example, you may not need a general elaborate procedural animation system for your first person model, you may just need a procedural recoil and weapon sway script.
As I was watching the video I was thinking to myself "it seems by code he means systems and by scripts he means code for specific situation, but the video would make a lot more sense if he defined his use of those terms first" but then i saw the pinned comment and see you've already clarified heh.
Scripting issues are why I can only enjoy Larian’s games to maybe 80%. I have the “programmer’s eye” like the designer’s eye you often talk about (not sure if you call it exactly this). Their games just have so many scripting issues while bg3 is less so but still gives similar vibes. This is somehow not an issue in other story heavy games / CRPGs, even they also are filled with bugs. I don’t really know why tbh.
How would you say that this manifests? I have no real frame of reference for it since I have no programming experience, but I'm still curious about what you mean.
@@jonah8168 well, when you do things a certain way and something breaks because the game wasn't expecting it. It doesn't do anything actually disastrous but it does break immersion if you notice.
Examples? I have multiple examples of "code executed in a weird way" in BG3, but I don't think it's related to this video, more just lack of polish.
@@helgenlane The storytelling of their games requires complex scripting because there are many exceptions and very little rules.
Good stuff, thanks for sharing your insights, experience, and wisdom Tim!
Nice video as always! I have a question: How common is the use of automated testing in the gaming industry, and when did it first become prevalent? How challenging is it to implement end-to-end (E2E) tests in game development, and what are the specific obstacles developers face in this process?
Hey not OP, but as someone who has done a lot with automated testing, it's a much worse cost/benefit ratio. Most testing knowledge, standards, best practices etc come from the world of corporate application development. These UI apps 99% work the same way: Get user input, process it, update the screen with output.
It's not so much about games vs "serious" applications, but more simulated worlds vs UI-centric applications. For example, a chess game has the same workflow, and you can test it the same way: Set up all the "facts" you need for a certain outcome, make the test suite click a button, confirm the result.
In a simulated (game) world, the whole idea is that all the actors do stuff at the same time and can influence each other. And the complexity usually comes from these interactions, not from the logic inside a method. If you look at the simplest E2E tests, like "Confirm that the player can jump 8 units high"; they are already quite complex to set up. Add to that the fact that iteration is the name of the game (no pun intended) in gamedev, so you're adjusting stuff all the time... and now you just have a second place where you need to do that.
Now, unit tests, OTOH... are also much less useful than in UI-centric applications 😋 but at least there are _some_ wins here. A game probably has some parts that are non-trivial pieces of pure logic, and those can be tested like just any other unit tests. In a simple health system, a test like _"I have received 8 damage, make sure health is reduced by 8"_ is probably more effort than it's worth. In a more complex version, a test _"I have been hit with a weapon that has 8 fire damage and 5 poison, I have 50% resistance against fire, make sure my health is reduced by 9"_ has a _great_ cost/benefit ratio.
@@raphaelschmitz4416 Nice! Thank you for the answer. Great insights
Hey Tim I’m an aspiring game designer looking to get more code in my games thank you for explaining the boundary of both code and scripting, also huge fan of your games
I love how serious this got once wasteful scripts came into play, for a second I could imagine what it would be like to work for Tim and having presented a terribly made questline!
As a person starting to learn game dev and doing a few projects in UE5 I always find your videos to be very informative and give me motivation to keep moving forward, so thank you for that. I would like to ask about your opinion on the initiative "stop killing games" .It tries to start lawmaking process about preservation of online games .But the more I read about it and what it tries to achieve the more confused I get as to what it's actual goals and reasons are. There is plenty of black and white discourse on social media and it is always extremely one sided without much consideration of what the other side is saying. I think it would be interesting to hear from a perspective of game developer/director.
yeah it would be cool to hear his take on the "stop killing games" initiative, good question
UE5... you've picked an interesting engine to start learning with. Great for larger teams, but hard to make anything meaningful with it solo - unless you're making videos, anyway.
That's pretty much boardgame design in a nutshell. Rulebook has all the rules, then all the cards and player powers break those rules with exceptions of their own.
I think a great example of this in action is Dishonored- there's so much that they *could* have done as scripting, but they went with code for a lot of it which enables a lot of emergeny gameplay.
Hi Tim, you've mentioned game AI in many videos. Bad AI is a common thing people complain about when it comes to games. What are some of the strategies to make it believable?
I think modularity is key in software / video games. You can reuse a lot of code but sometimes your NPC or whatever can just store the offset of the regular NPC object. From a robustness, performance and memory stand point I'd always try to create a simple interface / base object and only modify a special instance of it, but idk about quest setup
This is at its core fundamentally about, what to standardize into a reusable abstraction/template and what not.
Warning totally different domain incoming... One good example from me personally in a system administration bash script:
I could have decided to copy and paste my specific type of ssh command to every position i need to use it in and it would have worked at that initial point of time maybe, but instead i created an abstracted function for running this specific type of ssh command, because I knew, that this core function would have to be easily modifiable in one place to enable future maintenance.
Choosing the no abstraction route in this case probably would have locked me into some kind of position, where i would probably try to minimize touching these parts of the code ever again.
As someone who has no background on programming/development but still enjoys watching these videos, can someone ELI5 what coding and scripting are, and how they're different from each other?
In traditional programming, code is a compiled program executable. Usually it's programmed in C, C++, or C#. Script is an interpreted program file. It's programmed in .BAT or .PS (PowerShell).
(Windows examples given for simplicity. UNIX style platforms have different file types. And cross platform languages like Java and Python are the same everywhere.)
In the game dev world, the difference is a little muddied. A compiled C# file might be referred to as a script, because it's a single file attached to a game object. A script might also be interpreted and written in a language like Lua, which can also be attached to a game object. The word "script" is used from a game designer's perspective rather than a programmer's perspective.
I think what Cain is calling "code" is the general platform and he's calling "script" the business logic. The platform code creates the world, defines the physics, defines how all doors, all vehicles, all weapons, and all NPCs work. Without scripts, all NPCs would behave the same way and say the same things. All doors behave the same. Etc. By attaching a one-off script to a particular NPC, it would change their behavior to say and do specific things related to the context of the scene. Attaching a one-off script to a special door, might make that door behave differently such as produce an effect tailored to the level and game story.
Cain is saying don't try to build the platform from one-off scripts, because it turns the game into a non-deterministic mess. It's impossible to plan for or predict game behavior without a consistent baseline platform to build on top of.
This can largely be avoided by using a game engine such as Unity, Unreal, Godot, GameMaker, etc, because they have provided built-in code that runs the physics of the world you are creating. However, Cain's advice may still be applicable if the game is large and expands greatly upon the built-in code. For example, one might develop a currency and market system into the game, which the game engine does not provide. You could say the currency and market system is fundamental to the game so it should be implemented as "platform" code that defines how currency and market works everywhere in the game. A script in this case would be an exception such as the player purchasing in-game currency with real world credit card.
@@potato9832 hey, thanks so much for taking the time to write all that, it helped a lot. ❤️
I love your channel so much thank you thank you for every video you make!
Totally, with one addition that it's a good idea to do some code in a scripting language rather than hard-coding it. That's easier, makes the game more moddable etc.
6:47 I'm not a game developer, nor any kind of SWE... but I've played around enough with some game engines to understand that running scripts every single frame is to be avoided if at all possible. Heck, I've only ever taken Intro to Programming and Data Structures courses, never anything more advanced (and those were 20 years ago) - and even that knowledge is more than enough to understand how brutally inefficient this would be!
Holy smokes, I thought the people who coded gameplay were all hired after passing through the blessed gates of DSA and Optimization. Maybe they were just burned out due to crunch :D
Will you have a merch store up sometime in the future?
Yeah, some of those are classic. I remember one game where if you didn't destroy a light you got detected and lost the mission when trying to enter the building. OTOH if you went around, killed everyone, and came back to that light still intact - you still lost, even though there is no one to see you in the building.
I have always wanted to write a sophisticated script engine for interacting with a program. I'd love to see a full video that is entirely about the process of writing script parsers!
How do you handle parsing?
How do you decide on syntax?
How do you make it interact with your built in classes?
(I believe the scripts in fallout are even compiled into bytecode, how do you handle compiling and executing that?)
Hmm, explaining the entire process of making a scripting system is probably beyond the scope of this channel. It’s the equivalent of asking “how do I make my game multiplayer” or “please teach me linear algebra”. It’s a short question with a BIG answer with lots of “it depends on your game and your needs”.
Have you watched Arcanum Scripting?
ua-cam.com/video/coPkWyJIl-M/v-deo.html
At this point, you probably just want to use Lua for scripting rather than building the whole thing from scratch and expose a set of hooks/events that the scripters can attach scripts onto.
It's not really worth building your own language.
@@CainOnGames Think I missed this video, I'll check it out!
Many modern language support "scripting" by default, so you don't even has to use a different language at all and can use the same language for the game "core" and "scripts" which has many benefits.
This sounds like a solution in search of a problem.
Usually, a script system is there to speed up an often-repeated task, or to allow a non-programmer (story writer/level designer/etc) to work on the game. Basically, when you have specific problems, they will point to specific answers. E.g. for simple dialog trees, YAML or JSON syntax is probably sufficient, saving a ton of work.
What would you say is the different between scripting and code? I ask as I've always seen them as basically the same thing when in the context of working within a game engine like Unity.
There isn't a clear distinction in Unity, but if you want to apply this mindset, try to avoid creating c# files that handle specific cases (hard-coding).
Like, if you want the player to lose health in a toxic cloud, and this isn't the only one in the game, don't make a script called "toxicCloud", which subtracts 5 health every second from the player if the player is in its collision volume. This would be a "script".
if you want to code it properly, in the code for living things, run a function upon entering a collision volume. If the volume is flagged as toxic, emit an event and pass this living object's reference, the status effect enum for toxic, and "true".
In the status effect handler, upon receiving that event, add that living object's reference to an array of things with the toxic status. If the player enters two toxic clouds, their reference is added twice. Every second, for everything in the toxic status array, change its hp += (toxic dmg * its resistance). When a living object leaves the volume, a "false" event is sent, which removes this living object from the toxic status array. If the living object dies, send an event that removes all its references from the status effect handler.
This is more complicated than the first "script" option, but it is so much more reusable and will save time and prevent bugs in the long run.
@@jextra1313 I try and follow a modular approach like this as much as I can anyway. I appreciate the explanation though as is does help clear things up for me alot I think I understand the difference now.
@@jextra1313 In your example, if the object disappears (the cloud ceases to exist), with the first solution of the toxiccloud script, it works immediately. With your system of collision sending an event, you have to also think about objects vanishing and thus add some code.
You also have to think about what happens i the player IS in the cloud without entering it (the cloud gets created, the player is teleported).
So... I think you have it completely wrong here. If a player can teleport inside the object, or the object can be teleported, you have to take these into consideration.
Your proposal is about hard-coding some solutions ("entering the cloud"). That's exactly what Tim says not to do in his example of a guard seeing the player vs. checking if the player is an area and then adding rules to it.
@@LDiCesare In Unity, collision volumes check every frame to see if there's a new intersecting collision (OnCollisionEnter) or a collision stopped intersecting (OnCollisionExit), so it would work even if the player was teleported or started the game within the cloud. What Tim warns about is having a checkpoint being the door, when you could just hop the fence. A volume would be the solution here.
I was trying to frame my explanation as 'create a unique script for every interactable game object' vs 'create reuseable flag + handler code' but it became more complex that I wanted
Stuff like this is a good example of why principles of OOP are sooo important for game development. Inheritance, polymorphism, etc.
Comming mostly from unity where everything is c# unless you add somethings, wouldn't it all qualify as code rather than scripts?
In that case you'd probably have some methods on a script that goes on every character/item/etc. That's code.
And unique objects maybe inherit and override that. That's a script.
It's not literally code vs script, more like systemic vs individual in that case.
Exactly. Think in terms of systemic and exception, and you can use that technique anywhere
This was unclear to me at first too--I wasn't sure what he meant by scripts, unless it was some game-engine specific thing.
@@balijosu i didnt even know fallout could have used scripts, i always assumed it was all code
@@Sauvva_ they used compiled scripts. And for fallout 2 there's an official compiler, source code for original scripts and several modern fan-made editors specifically to write and compile SSL ( which i believe stands for Star Track scripting language (: ) and they support sfall scripting extensions.
I like the more technical videos
It's funny, my only 'development' experience is running a server on Conan Exiles. Some mods allow us to create quests and scripts and NPCs, if I want to add anything more complex I have to create a script. And it is all in-game. I haven't tried actual modding yet.
Even without the ability to change code, there was still good advice here.
Maybe in a case like mine, the concept of master scripts and subscripts becomes more prevalent.
Core scripts which act like code, being referenced by subscripts whenever needed.
This way, while I am still scripting everything, I can enforce rules that can account for these other situations without every one of them having its own script.
So, the guard can have a unique script for his quest or w/e if needed, but otherwise obeys the master crime script that only triggers as needed, and jumps to the relevant part of the script depending on how it's called.
Even though the game is in UE4, in my environment inside it I have to do everything with hand placed triggers or interactables. Interesting live-game development scenario!
Great video as allways! I'd love a video covering tutorials and implementing them as well if you'd like. Cause I hate implementing tutorials :)
What is the difference between scripts and code.
I thought scripts held code.
I have recently started game development but I have been studying computer science for 2 years at this point. What's the difference between coding and scripting in game development context? I suppose it depends on game engine you are using but in godot for example there is this tree node system with scenes and you have to attach scripts to specific nodes for basic functionality for example for movement of a player and so on. Is there some sort of distinction between these 2 terms? I have always considered them the same.
Great video. I was wondering if there's also an audience component eg coding being more of a programmer's tool and scripting a non-programmer's tool? Could the difference between coding and scripting get fuzzy in certain environments eg unity?
Hey Tim! Most of this video reminds me of putting together a "finite state machine" for player and non-player controllers. I have played around with simple state machines to handle animation transitions and very rudimentary NPC AI, would this be a good way to conceptualize the central point when using a pre-existing engine? Having a de-centralized state machine for the player character in order to handle the plethora of potential exceptions to the "idle" state of the character and a centralized state machine for different NPCs' behavior? While listening and typing this question, you started bringing up the "conditions" in NPCs that also sound very similar to how I understand finite state machines! Thanks as always for your insight!
I have a couple questions: The only scripting experience I have is with Unreal Blueprints. Where I'd create an API with code, and then the designer uses blueprints to script up some behaviors. How closely does that scenario relate to the content of this video?
For example.. You mentioned the "NPC death but still talking" issue. Do traditional scripts not have access to game state? In Unreal blueprints, you would just early out I'd guess if the NPC was dead?
Another thing is the "on tick" check. In Unreal you'd use events to trigger stuff like this. Would you actually check every tick in a hand-rolled engine? Seems like you'd just fire an event and cache state somewhere if the event wasn't relevant at the time.
Totally valid though to add fundamental mechanics to the game itself in code. "Don't repeat yourself" should resolve that issue. And then the other thing I got from this video is.. We should think about the implications inherent in where we put the script. If you put a script that triggers a quest when someone enters a door, what you're inherently saying is, "This quest is impossible to trigger without walking through this door". Put in another way, you're saying, "In deeply care about HOW the player enters this room, to the point where I will block the player from progression should they enter in another way."
I think that's a good headspace designers should be in when implementing things like that.
I really enjoy watching these technical explanations and seeing the common sense behind the decisions.
I do wonder, what is your opinion on test driven development when making games?
I see many games that have clear technical issues, regressions or have issues with patch cadence due to what I suspect is unmaintainable code that is not properly covered by tests, effectively a frozen codebase that everyone is too afraid to touch as if they shake the tree too much it explodes, crashes and burns horribly.
I don't get why all interactions are not written with tests first, where game mechanics are tested with one function calling another, decoupled from rendering. It could run without a UI, testing the interactions, such as triggering different states and testing if that quest is still completable in specific scenarios.
And when a bug is discovered, a test case should be written first, followed by a bugfix to avoid regressions in the future.
I get that people have deadlines and crunch may be needed at times, but if it is not done properly the developers are just digging their own graves filling it with more technical debt until it is simply too much to bear and the thing becomes unmaintainable, innovation no longer being possible.
A long post, but if you ever read this and get to cover it, I am really lookin forward to watching what you think in a few months once your queue of other questions is processed.
How does this division between code and script work if you're using an existing game engine? On the one hand, everything you're writing is technically a script. On the other hand, I guess there's still a difference between code/scripts for general cases and scripts for small specific changes (like, general enemy AI, and then one enemy that behaves differently during a quest?)
Unreal is a good example. Your programmers can change the engine using C++. And anyone can write a script using Blueprint. I would recommend keeping that distinction, where rules are coded and exceptions are scripted.
@@CainOnGames that makes sense, thanks!
Thanks for the insightful video, but it leaves me wondering: Why script at all? Is it a budget thing where you want folks other than the programmers to be able to implement logic? Would you recommend staying away from scripting completely if that wasn't a concern? Like on a small indie team where everyone happens to know how to code?
[laughs in Twine Harlowe]
I'd argue there is barely any reason to "script" anyway nowadays, aside from visual or node-style systems. The additional API boundary creates a lot of unnecessary complexity that you gotta maintain, instead of just fixing the problem directly in a high-quality programming language with proper performance and tooling support. No need to reinvent the wheel. You can do hot reloading in any language you want, even with compiled ones. Just hot-reload a DLL with gameplay logic when it changes. I've done it that way for a while now and I'll never go back to a separate "scripting" language. The core concepts of this video still apply, though. Don't structure everything based on the exceptions and make sure the core rules are solid first.
the only and main reason for scripting is to move some of the load from senior coders out to scripters
on scripts, things can change on the fly without the need of too much planning, while code need to be documented properly
also they can mess and experiment with scripting and, if something goes wrong, only a small portion of the game will break
while they can not be trusted to handle the code, where a small error can brick the whole engine, where an introduced bug can take weeks to show up, be discovered and get fixed
@@giampaolomannucci8281 I see the appeal of having less technically versed people write some gameplay logic, but in my experience it always tends to balloon out, to the point that it ends up being ported to the core eventually anyway. I'd rather put the work into making working with the real programming language better, so it doesn't end up having to be rewritten down the line. It also avoids a lot of performance issues that scripting often entails.
The reason to use scripting isn't that you can have less technically adept people working on it, but that you can iterate more quickly. Scripts are for parts of the game that aren't performance sensitive but have to be changed on a whim. Forcing people to work on that kind of thing in C++, C#, or some other compiled language is painful. Also, it means now you have a tonne of extra stuff that needs to get built as part of the main binary's build pipeline. No, unless you're writing something with very fixed behaviour that doesn't have weird interactions between different entities, you're best off using scripting.
@@talideon That's solved by hot reloading the code.
ooo this is a good topic, as a programmer I often struggle to draw the line between core system mechanics, and mechanics that should EXTEND the system mechanics. Like, should stun be a debuff? or should their be a specific stun field on the players struct? and sure that might be an easy question but you have to make these decisions constantly
can someone help me understand the difference between "in code" and "in a script"
like is a script just a compoonent added to say an NPC object?
If you use Unreal, the engine is code and the blueprints are scripts
I’m making a game and would love to see an example of this. I’m having a hard time understanding what you mean by script and code.
Top notes!
What is the difference between Code and Scripts?
It does feel like a less meaningful division nowadays...
Whether scripted or coded directly into the engine, your first focus should be systems and their respective rules.
Having guards react and do guard logic will almost certainly be a script, but it'll be a single script used by every guard that overrides portions of a more generic AI Script, which deal with most of the top-level logic of their actions, and hooking into engine code to do things like Line of Sight and pathfinding.
Ad-hoc scripts - which Tim is REALLY talking about here - are for rare or one-off cases, e.g. for specific guards you might add a trigger so they notice a specific item they are supposed to guard went missing to hook into the generic AI script to make them go searching for the player.
First relevant result in google says a script is instructions interpreted by your code, opposed to by the CPU directly like your programming language. Like having a dialog tree in JSON. And bigger games have script systems for far more than that, because a lot of non-coders need to work on the game. Anyway, video make much more sense in that context.
I'm interested, what do you consider code and what do you consider scripts? I think those two ideas get conflated a lot
Hey Tim, I'm still a programming noob. Could you explain the difference between scripts and code? Thanks!
Composition, inheritance, mere functions, or a mix of the all?
I have a fear of talking to NPCs with my inventory full: what if they will want to give me a quest item, it will not be able to fit into inventory, nobody accounted for it and quest item will disappear forever? 🙂
I don't remember what game induced this fear but its my faithful companion in all games with inventory and NPCs
I wonder if Tim is looking for bugs in his consumed games only fellow developers are keen to. And whether he reports them.
Does Tim sometimes decompile parts of foreign games (in secret) and looks into them? Does he in general wonders how some games features function and tries to learn how they work?
Great vid!
How do you manage the difference between code and script ? OR maybe more importantly, who decides if something is a special case that would require script vs a general action that would require code (changes) ?
I have follow up questions, but they are getting more into project / bug fixes management
Practice writing rulebooks. Put together the rules of the game before you start making the game. This will give you an idea of what should be done in code and when you encounter something that could change the rules you can ask if you need something unique for the moment (script) or if you need to add a new rule.
Can the player run, jump, sprint? Are you going to have status effects that change their values?
Then you get to a scene where they're in mud and you now have to make a decision. Do you want to make the mud apply a status effect (if you added this to the game rules) or will you script in logic to reduce player speed or will you add a new rule based on the terrain the player is on because you want to use it more than once.
Hi Tim. Could you clarify something on a technical level? What do you mean by 'script' vs code? I'm currently working in Unreal, though relatively inexperienced, so in that context.
Is it more of a 'one-off' piece of code on a specific BP? Or is there some actual, built-in (non-asset) way to implement some sort of additional layer of logic via a scripting language?
You can also explain it in terms of Unity, but tbh I don't know how much I remember.
I believe the video “Arcanum Scripting” gets into the code vs script distinction.
It's all scripting in Unreal. That's one of big downsides of general puprose engines.
Granted, the scripts can do *a lot*, but it's still all scripting.
In a specific-purpose-made engine (or at least, the one you're modifying the source code of), you will put your rules in "engine code", and have your engine maintain them as they would any other system, but then also invoke scripts if there is one attached. So, your regular enemy behaviour would be all part of the rules, but then your boss with it's modification to that behaviour would be a script.
In engines where all you do is script (Unity, for example), you have to make scripts that track other scripts, as a hacky workaround to building rules and exceptions.
Depending on what game you're building, it may be worth to explore engines beyond the "Holy Trinity" of Unreal, Unity and Godot, and find something that's more specialised, and play around with them for a bit. Like idTech4 for fps, GemRB for RPG, etc.
Tim clarified it in another comment. It's basically systemic vs exception.
An actor is always an actor. It's loaded, accessed, managed by following the rules of the engine. What you add to the actor is their script.
If you make a library separate from any distinct entity to handle items, (drop tables, affix rolling, how it can be equiped) then in that case you're writing the rules. Then you can write exceptions to those rules into the individual items (actors) themselves. Maybe you don't need to go as deep as writing a full blueprint and instead simply set certain flags or values on the actor itself. Essentially, the gun itself should not declare how it should fire, it should tell the rulebook what stats it has and then the engine will know what to do when your character says it's firing the weapon. Unless it's a very special weapon that needs an exception because it's used to blow up the entrance to a specific dungeon.
After reading a few other examples think of it this way. D&D handbook is a set of rules. Those rules determine how things happen, but the players and DM run their own scripts and the outcomes are based on those rules. Each player has their player sheet which holds all the modifiers that can be applied to their actions, but they don't each of them hold the rules for the action, those are in the handbook.
I’m just guessing here, but could it be that some games rely overly on scripts because it’s easier/quicker to iterate and work on, on the fly, than code?
And then nearing launch when perhaps you should be moving some scripted functions/solutions into the code, you are busy fighting fires and squashing bugs, so it never gets done.
I’ve never shipped a game but that seems like a likely trap I could fall in
Very nice! I would like to know more about the differences between code and scripting. I am not sure I understood entirely. Does anyone have a video explaining these concepts?
Code: "The door must be locked before leaving the house" (establishes a general rule).
Script: "Ensure the lock is turned clockwise three times" (provides the specific steps to fulfill that rule).
@@FractalPrism. got you! That makes sense. Another thing, I noticed someone talking about programmers that only code VS programmers that only do scripting. Is that a thing? Are these different roles of programmers?
@@aknostv a larger team you may have more specialists but generally you'd be involved with both.
Hey, Tim. I have a question for you about the development of the Outer Worlds (and games with sequels that you took part in):
How much time of the actual development was spent on engine / tooling / mechanics / etc while making OW1 and what do you think it will take to make OW2?
To clarify my question:
I understand that when you made New Vegas, you had a complete game of Fallout 3 to build your game above it. So you have reused parts of the Creation Kit, dungeon builder, RPG system, stealth mechanics, you didn't need to code the stuff that will prevent assets from despawning if player dropped them, and so on and so forth.
With Outer Worlds, however you had to build all of this stuff from scratch (and many of the things just didn't make it) that I wonder: How long did it took to build your game's "framework" that allowed you to actually build a game? And how the fact that you already have all tools and game's systems in place do you think will affect the development of OW2?
Thanks.
I did not work on New Vegas and in fact, I started at Obsidian after it shipped. Also, I cannot answer questions about TOW2, even ones phrased as TOW questions, e.g. "what features do you wish you had had time to add to TOW?" Because those questions directly relate to what we are doing in TOW2.
I can answer how long it took the get the game framework in place. Since we had the vertical slice done in one year, we had the framework in place faster than that. I'd say somewhere between 8 and 10 months. The VS was the first "final" content we made with that framework.
@@CainOnGames I didn't want this sound like i'm extracting the information about the upcoming game, I'm just curious about how much time (in percents o r whatever) did "frameworking" "steal" from the development time of TOW and how much of it will be "given back" during the development of TOW2 literally because of the time spent on this it TW1.
8 to 10 month for a tooling like this for an RPG of this scale is very impressive.
thanks for the extremely entertaining videos. vertical slice one is awesome.
Can someone help me understand. I thought scripts were effectively just like complicated functions that are called at runtime instead of precompiled. Is that it or is there more to it that can cause issues?
I pinned a comment to explain the difference.
Thank you!
You've put into words something that's bothered me since before I even knew what scripting was.
Nothing kills my enjoyment of a game faster than doing something that should finish a quest, but the rules not supporting it. Too many times have I found the quest item, or figured out the mystery, or found another way in, or whatever, and the game broke the quest, or worse, made me backtrack and redo it the 'right' way.
This video should be shown to a certain famous developer in particular that is extremely bad about this and has made me frustrated in their games for decades.
I guess it's valid in any time of code, not just only game code. Try to minimize the corner cases and abstract away as much as you can so you don't have to re-write hundred of lines anytime you want to change a feature
In summary: the guy discovered OOP 50 years after it was invented 🙂
So I'm assuming we're talking about, for example, writing the main code in C++ and having certain parts use Lua scripts?
Yes. And that can include engines that can't be coded and only provide script hooks, like Unity or Godot. Make one script that handles ALL doors, for example, and let a few individual doors do their own thing.
Funny, something mentioned in this vid is a question that's been chewing my brain for about a week: Mr. Cain, how do you feel about your games being speedrun and have you ever used speedrun glitches people have figured out to fix things in a patch? I've seen other creators watching speedruns of their games and I love hearing their thoughts on what they see 😊.
Uncle Tim, has a video on speedrunning.
ua-cam.com/video/l-Vuw-qWCgY/v-deo.html
I'm very new to coding and making games, so forgive me if I sound stupid. I understand the idea of having big rules governing the game, and having exceptions for little things. I just don't get what you mean by code, and script. Aren't these the same, or am I missing something?
Code The Bugs, Catch The Exceptions
I think it would have been nice if you had formally defined "Scripting" and "Coding" in this video. At some point you mentioned interpreted vs. Compiled languages but you also alluded to "applying" a Script to a specific entity in the game, leading me to think more like a component system vs. plain code files that knew nothing about the engine.
I forget who said it but someone said "scripting is too limiting for programmers and too advanced for level designers. Scripting is the worst idea and the worse for both worlds. Make code all real code so programmers deal with it and level designers aren't writing limited bad code."
As a programmer I find scripting cool, but I'm curious what you think of this quote I heard.
May have been from Pirate software-that long hair guy who says he and his dad worked at Blizzard.
0:27 laughed *way* too hard at that
your idea of a fallout game, is it somehow related to Chosen One's son, who is part of the Mafia and never knew who his real father was? :))
Hey nice philosophy there I guess that, We should do that to make exceptions less painful.... yehh ......
I'm a bit confused. What exactly do you mean by script and code? In my "world" (I'm working with unity btw) a script is a file that contains code.
Unfortunately Unity only has scripts, and you can’t change the engine code.
Yeah talking unreal, " Add event dispatcher ENEMY SPOTTED " If on enemy spotted talk " hello world " the NPC says and yeahs it is fun BOOM Feel the loom!
I was literally just coding a couple exceptions before I got here
I soft locked the Starfield ship piloting tutorial by doing the thing before Vasco says do the thing. I think that's been patched, but yeah.
Code should not even be on the individual objects. It should be in systems that deal with generic behaviors.