Code The Rules, Script The Exceptions 

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 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-coPkWyJIl-M.html

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 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.

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'"

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

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

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'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.

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.

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

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.

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.

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.

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

Cantor enters the chat…

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? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-coPkWyJIl-M.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.

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. ❤️

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.

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.

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.

Uncle Tim, has a video on speedrunning.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-l-Vuw-qWCgY.html

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.

If you use Unreal, the engine is code and the blueprints are scripts

It does feel like a less meaningful division nowadays...

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!

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

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.

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.

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.

Yes, exactly.

I pinned a comment to explain the difference.

nevermind, just read some other comments and it seems like my understanding is on par with what you were speaking about. :)

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.

Unfortunately Unity only has scripts, and you can’t change the engine code.