That weird moment when you click on a random game dev talk and you discover you already have the book

@LimitedWard

4 жыл бұрын

Had the same moment when he mentioned Crafting Interpreters.

@Xonatron

Жыл бұрын

Watching this again, now I have that feeling too (now that I own both books)!

@heagandev

7 ай бұрын

Same. I have about 100 bookmarks related to gamedev and this book is at the top of the list. Never read it, I will now though 😅

_"I worked for EA for eight years, so I have experience being trapped in dungeons for a long time."_ lol brilliant. :)

@eugeneiii2972

3 жыл бұрын

Not enough people laughed at that.

@Nukestarmaster

3 жыл бұрын

@@BenGearig *Insert 'Nam flashbacks.

@kyonas6047

2 жыл бұрын

tho i heard EA treats employees better than customer lol

@bearwynn

2 жыл бұрын

​@@kyonas6047 I work for EA as a gameplay programmer and that's generally the case, but it's still a massive game company so all the standard issues of a large international game company apply. The pay is absolute dog doodoo and the administation is garbage.

@danibiyarslanov

Жыл бұрын

@@bearwynn really? I thought the money was good at least

I dont remember seeing a better presentation slide in my life.

@pythonxz

7 ай бұрын

Fitting that a programmer would program his presentation.

Other side benefits of separating out "actions" is you can serialize them for replay systems, multiplayer, offline simulation - lots of stuff!

@storerestore

2 жыл бұрын

Not to mention testing. You can write unit tests for precise sequences of actions instead of trying to coax some unified object to act in a certain way, and you can automatically iterate over permutations of action sequences

"cpu's have been getting twice as faster, we get to be twice as lazy as developers" *jonathan blow wants to know your location*

this is the single most useful game presentation talk I have ever watched.

Robert is amazing on many levels, wish he's do more public appearances and talks.

@r1pfake521

3 жыл бұрын

Same, I want to see more talks with him. He finished his new books about creating a own programming language (which is awesome btw), I hope he makes something new in the future, because I need more of his programming content haha

@Matheus.Richard

2 жыл бұрын

@@r1pfake521 I thought I was a creepy because I absolutely love everything he writes!

Roguelikes are so amazing to program. They teach you so many things.

@pythonxz

7 ай бұрын

What topics do you think they do a great job teaching you?

@BlueKanary

6 ай бұрын

@@pythonxz Without the need to dive deep into physics, rendering, or in many cases audio, you can really dig into system architecture and other low-level topics like data structures. On the game side, it also helps in prototyping quickly with AI, game mechanics, and procedural generation.

For the undo feature in an editor, I had some luck with a different approach to actions. There is an effective state that is calculated on the fly based on a stack of sparse representations of the state. The stack items take precedence from top to bottom, so each frame works like an overlay for the frames under it, optionally overloading changes made in the frames below it. You can think of it as layers in Photoshop. I have two operations for this stack: create a new frame, and merge the bottom two frames. All user actions that make sense as discrete steps in the undo history just mutate the top stack frame. Once the action is complete, they create a new stack frame. If there are too many stack frames, the bottom two frames are merged. This is effectively the limit on the undo level. Undo and redo is done by simply changing the stack top index. It's probably slow for something complex, but in my case the state is a 40x25 text screen so there's no problem having iterating over the stack frames while you render it. It could easily work for something like a simple tile map editor. Originally I wanted to implement this as an action history, but then I'd have to repeat the entire history of actions - 1 to undo, or implement reversible actions. The benefit of the state stack approach is that I could easily graft it onto a system that already mutated the state wildly without much change to the editing actions I had already implemented.

@dandymcgee

Жыл бұрын

This is essentially how differential backups work, or transaction logs in database engines. Nice.

@Artoooooor

Жыл бұрын

So generally - some objects that can tell how to go from state A to state B. In general - actions define the behaviour themselves, while your differential state objects contain just data processed by one general piece of code, am I correct?

I was having the same issue and I found this talk, such a great talk! AMAZING! thank you!

Can we please take a moment for that epic EA burn at the beginning.

Awesome presentation. Helped me a lot understanding the directions I need to take on my project! Thanks! Gonna try to read your book!

I was surprised to find out that this was the same person who made Game Programming Patterns! I've read from the site of that book and enjoyed it quite a bit.

I'm introverted. You're introverted. We can introvert together while avoiding eye contact. ❤️️

@CariagaXIII

4 жыл бұрын

you need to move your raycast higher

@SpecialKapson

4 жыл бұрын

@@CariagaXIII Thankfully I wasn't drinking anything when I read that

@jayocaine2946

4 жыл бұрын

thats not introverted, that's socially awkward.

Absolutely fantastic breakdown of the components and structure of commands and how you'd implement them, best part is even though you've used roguelike as the example, any game system (specially RPG in nature) can benefit from all these architectures! Thank you for sharing! :)

Read his book, absolutely worth it!!

@saidnobodyever711

4 жыл бұрын

His Crafting Interpreters book is awesome too! I read that recently, didn't know he was a game dev too, just stumbled on this video while searching for videos on dungeon generation.

I want to notice that the described pattern IS NOT ECS. It's just Entity-Component pattern, where Entity is component container and Component is game logic part which contains both data and logic. That's like classic OOP with more emphasis on composition. Bob used systems only for calling Component.Update() method as you can see at 6:50. Entity-Component-System is ANOTHER architecture pattern. Yeah, both are called very similar, but there are a lot of differences. Main point of ECS is strictly data/logic separation. Entity is still just a container of Components, BUT Components MUST contain ONLY DATA. It's very important and this restriction is ALL power of ECS. What should contain game logic then? You think right: Systems will contain all logic of your game and just read and write components, just like conveyor that process all game data. Systems should not contain data, but it's not restricted. Secondary point of ECS is Composition OVER inheritance. You MUST NOT inherit components, but you can inherit systems. ECS is more like procedural programming, not OOP.

@sh42913

3 жыл бұрын

​@@MuhammadHosny0, I think it's possible to name Bob's pattern as Entity-Component System and what I'm talking about as Entity-Component-System. But it's better to separate them and use the following naming: Entity-Component architecture pattern and Entity-Component-System architecture pattern to avoid confusion

@pedrobraz2809

19 күн бұрын

Where can I read more about this

The man, the myth, and the e-book. It's mentioned and suggested a surprising amount online.

Wow, one of the most useful presentation I've seen so far ! :) Thank you !

I appreciate this talk. It gives me more insight in how to maintain the structure of my own code more

A fantastic talk. If you are like me back here to review the patterns, that starts at 10:30

@netd777

3 жыл бұрын

Yeah man, I was expecting something shallow and relaxing, but he actually gives some serious insight about software architecture and modeling like, I had to come back. As he said, we all "reinvent" it many times and then forget about it. But doing it knowingly saves time and the result is better. Sometimes we constrain ourselves with language constructs or programming patterns, when in reality you can't always map your problem to these, then you should "eject" and "roll your own" solution.

It's a great pack of ideas for any game with simple graphics. Thank you, Bob!

This talk helped me understand how to reason about the design patterns I've been seeing around for years, but never understood the rationale behind. Great talk!

Great talk. I was almost debating switching my new roguelike to implement more nested inheritance, but this helped me reconsider that notion. Very informative, will watch again :)

@Shifticek

Жыл бұрын

you'll miss on fun stuff, like "why do dogs inherit fom car?"

Good talk, thanks Bob! And thanks for writing and sharing your great book on Game Design Patterns, too. :D I really enjoyed it!

Great talk! Main take-away/reminder for me: Don't overuse architectural patterns. Employ those that actually make sense in your domain: those that help provide clear structure to the solution of your particular problem. Obvious of course, but it's worth to frequently reflect on healthy architectural methodology.

@pythonxz

7 ай бұрын

I like how Casey Muratori describes programming. In his mind "architecture" is the wrong term. He sees it more like city planning. You have to shape your structure as you build it.

I love Bob so much!

Though this is an old talk, i quite like it and was 1. very informative 2. very entertaining 3. Funny. Thanks for the great video!

Crafting Interpreters is AMAZING thank you Bob!!!!!

I wish I could find this great talk before. This is the best and easy to follow talk I ever listen about game architecture. Blessings to Bob Nystrom. One thing that I'd like to mention is strategy pattern would fit perfect into "command object" instead of command pattern. Nevertheless, both pattern would yield the same result in this case.

@grimgrothse

2 жыл бұрын

Actually command pattern is the best solution in the example he used. Strategy would make sense if, for example, you have 2 or more playable characters, where say the AttackAction, implements a different algorithm depending on the character. Command is about the what (move, jump, attack), strategy is about the how. In any case, command pattern or strategy it all depends on your GDD, you could even combine both of them, but I wouldn´t say use strategy instead.

the presentation slides were dope

Very interesting talk, thanks

Clear and insightful. Just like his book. Legend.

The third one just gave me an idea to solve the current problem in my personal project

Useful set of things to do to resolve unobvious issues.

This is really cool! Im making a game that works like a roguelike and I wound up doing pretty much all of this. Actions as the command pattern, and actors that implement interfaces, etc. I guess if two people wind up independently designing the same solution, it's probably at least good for something!

Hey, I know this guy, I read his book. Highly recommended. Humorous and smooth read while dense with enlightening info

i think this is the best programming presentation i've ever saw lol

great talk, the action objects are a neat idea

This talk has the best graphics of all the talks. Fight me.

@nachfullbarertrank5230

4 жыл бұрын

Toady was better, obviously!

17:50 one can imagine just how long this kind of chain of events can get in a properly programmed roguelike

Wow, that level gen looks awesome! Anyone know which mysterious game is referenced in this talk?

I didn't understand most of what he was talking about but I enjoyed the presentation.

Great talk! Performance characteristics are cool but the real reason I'm drawn to learning ECS architecture is that sometimes I _really_ want to be able to treat my game like it's a database. I was doing a tutorial (Hands on Rust by Herbert Wolverson) where putting an item in your inventory was as simple as adding a CarriedBy (player) component to the item. I can really see a lot of possibility to think of the _relationships_ between components when designing new systems.

Great! Interesting talk!

Great video

14:13 "Reinventing object orientation at the application level"

I admit that I'm somewhat confused by "Idea #1". That's exactly how components are used in ECS (or at least most interpretations of ECS that I am familiar with). Components do not represent domains but capabilities. Having an "AI" component is similar to having a giant "update()" call on your entity class so that doesn't make any sense. Also, the command pattern later doesn't quite seem right. A proper command would more likely be a data structure / class that describes the action. That action can then be run in an interpreter, which performs the side effects of that action.

@hasparus

4 жыл бұрын

Same thing. You can serialize commands (or actions), and they're usually separated from implementation details, right? I can't bring myself to dislike the talk, though

@diadetediotedio6918

Жыл бұрын

You could treat the AI component as an ability to perform actions on a set of components automatically. This fits well with the ECS standard.

Idea #3 is awesome. turn verbs into nouns. Well not necessarily but thinking about verbs like abstractable things is cool!

Thanks for this video.

Action classes are classy, I like it.

Yes, we should always think - very carefully - about how best to organise our data, for that's one house you really don't want to be untidy...!!

Love anything regarding architecture, especially in rpgs.

12:08 .... omg makes sense now.

20:40 "... take some verb ... and turn it into a noun ..."

How about splitting up video game code according to function? For example separating your logic layer from your visual layer and from your audio layer, etc. So that if you want to do something like for example make different art styles for your game, such as one that is your default art style and another that uses ascii art style, you can easily add the code for those different art styles, without having to rewrite the logic portion of the game.

@keldencowan

3 жыл бұрын

You've just described the primary motivation for ECS. Orienting a game around functions rather than objects you get functional programming rather than OOP. Rather than having orienting architecture around big player classes and inheritance, you divide the game into data components and systems of functions (the C and the S). Entities are just are just the keys to the component hash tables. Every pattern the video describes as good for rogue likes is just a naive reimplementation of true ECS.

@keldencowan

3 жыл бұрын

Patterns Bob Nystrom ♥s: Components: Literally just data components. If your entity can move, add the Movement component. If it can break add the Breakable component. Type Objects: ECS uses composition rather than inheritance. You just have two components rather than parent child classes. Command Objects: When in doubt, try turning a verb into a system(s) and a component. E.g. a FireSpreadSystem, FuelSystem and FlammableComponent. The only difference is his memory layout and that he sticks to OOP things like inheritance, which just ends up coupling actions to specific objects like actors. I would prefer to have those capabilities more composable and reusable myself.

@skaruts

2 жыл бұрын

@@keldencowan the separation of concerns is also a thing in OOP. It's a thing in any paradigm. The advantage of ECS depends on the specifics of a given goal. Also, *_"Every pattern the video describes as good for rogue likes is just a naive reimplementation of true ECS."_* No it's not. It's actually a smart implementation of OOP through composition, instead of inheritance.

the voice cracks really make this

so, how do you query the Actor in an Action.Perform method? 18:05 I tried something like that: - set static fields in Action class, such as currentActor/gameScene/mapSet - when an actor finish it's turn, the GameLogicClass switch the 'currentActor' and other static fields It looks strange, but it works well. I hope this is the right way : )

@frechjo

3 жыл бұрын

Well, I assume you know what the actor is when you create the action object. Why not just use a member variable? If it's a property of the action, it should go with it. Using a static or class side variable will break in a lot of circumstances, it's basically just using a global. Anything that takes an action outside of the context in which it was created, basically is prone to fail.

@whitebai6367

3 жыл бұрын

@@frechjo oh，there are so many params in the action instance, game manager, main scene, word map, current actor, attack target...I am just trying to keep the code simple while create an certain action with those params

@whitebai6367

3 жыл бұрын

Well, in my opinion, carry all those params to a single instance for example 'gameInstance' , and then pass it to the action constructor. They are doing the same thing. I mean using the global variable...

@frechjo

3 жыл бұрын

@@whitebai6367 Maybe you could break your actions into subclasses? I doubt all actions need all those fields. And are you sure an action should have to know things like "game manager", or "main scene", or "world map"? By it being as using globals, I mean you can only hold a single value for all the actions if you use a class variable. If you have actions to process, all with different actors, targets, or whatever, your global/class variable will point only to the last one, and the rest will have the wrong information. So you can never produce actions to evaluate them at a different stage, or store them (for undo, replay, whatever), and maybe a bunch of other things you might want to do. If you are just going to call the action at the moment you create it, you could have simply called a function.

@whitebai6367

3 жыл бұрын

@@frechjo thanks for your examples, I get you point now. It's kind of you.

Idea #3 is basically a defunctionalization, right?

Nice that you use Dart!

this is one of those talks that you might dismiss at first glance, but you'll come back a month/year/project later and realize how smart it is.

What I think woudl click for most people when trying to explain ECS.. it is a database like relationship table model and the flow of information is not much different. It is simply data oriented architecture.

what font is that in the presentation? i want to use it in my ide

When you turn actino into an object, what do you generally pass to it as properties?

I think the speaker may have been confused between Entities, Components and Systems (ECS) and Entity/Component Systems. The later is the one where you create an entity class that has a list of components where each component is a class that is some behaviour. This is the pattern used by older versions of the Unity game engine. The former is where an entity is just an id, a component is a POD type and a system is a function which filters the entities by which components are required for a given piece of game logic. This is the pattern used by newer versions of the Unity game engine with their Burst compiler. These patterns are very different, they just have an unfortunately similar name.

12:08 "This is the case where I think actually inheritance works very well, where you have the hierarchy that is not very deep, but it's really wide."

Anyone know what font he uses on his slides?

@msmeraglia

5 жыл бұрын

was just looking this up lol its different than the NES/Gameboy font and Commodor64 font, wondering if he drew it himself?

@msmeraglia

5 жыл бұрын

it is the most similar to the Commodor64 font (see lower case a, b, d) but its slightly different on many letters (lower case p, u, m) etc.

@msmeraglia

5 жыл бұрын

actually this one is pretty close : fontsme.com/pixel-sans-serif-condensed.font

@gage2560

4 жыл бұрын

Press start 2P font

Bob your book is the dogs bollocks!

This is not the correct representation of ECS that is used in the industry today, which is understandable because the name is confusing. ECS today is Entities are treated as identifiers, Systems exists to contain a list of entities which have the component that System manages, and Components have just data, no functions. Entities should not have anything in them other than maybe an ID and a transform if 3D location is a first class data member, and your entity manager can hold all the components and give them to each SYstem, or maybe encapsulate that in your scene graph. This particular representation is also a very old form of Actor-Model system from the 90s, just using the terms Entity and Component, but it achieves nothing more than the old Actor-Model system and has the same problems. A correct ECS truly seperates the burden of work on the Systems, but at the same time gives the SceneGraph/Entity manager the control of which system gets what component, and Entitys have 0 data tied to them so you can pass them around like nothing.

@ihusker2827

4 жыл бұрын

Yeah I was very confused. Thought this was outdated. Entities (Hold ID's), Components (Hold Data), Systems (Do Functionality)

@GladerDev

3 жыл бұрын

I agree, this is how I implemented my ECS for my project.

@nutritionalyeast7978

3 жыл бұрын

I think maybe they forgot to mention something important? Cuz at 6:50 the code they present looks more like ECS system looping thru the components separately from the entities

@JohnSmith-rl3qg

3 жыл бұрын

@Darkwing Dumpling That's because this talk is about an ALTERNATIVE to ECS for roguelikes. At 1:51 he explains that the talk is about why he DOESN'T use classical ECS. At 4:51 he begins to summarize how classical ECS works, as you explained it, though he does gloss over it since it is not the subject of this talk. At 8:14 he points out that for a game as simple as a roguelike, ECS is often overkill, and spends the rest of the talk discussing organization. But thanks for clarifying how classical ECS works

@Terszel

3 жыл бұрын

@@slBrelaz It is most certainly the de facto standard in terms of ECS, you can consult with Ubisoft or Overwatch developers and I believe there are GDC talks in which Assassins Creed, Overwatch, and even Halo are shown and described the ECS which they use and you can see the description matches with what I wrote about true ECS. As for Unity and Unreal, these are also common misconceptions but again you can verify these by taking a look into the UE4 source code, and Unity itself does much to distance itself from the term ECS as they know the implementation is not an actual ECS. 1) Unity until very recently did not use ECS, it even referred to it specifically as the Unity Component System in all documentation. Only recently does it use *some* actual ECS concepts, yet you can watch their video shows and they still try and steer clear from comparing their ECS to an industry ECS. 2) Unreal does not use ECS. It uses Entity-Components, which is the system I described is the same as Actor Model in the comment. You can take a look for yourself through UE4 and see that they do not have any concept of Systems or managers for their components. They even still use the term Actor instead of Entity, most likely as a relic of the original Actor-Model system they had in UE2 & UE3, and it has gone (architecturally) unchanged. As stated in the comment the only similarity is in the name. As for your industry contacts, I can't really speak on whether or not they are using ECS as I don't know them, but as long as the description matches up it is ECS, and you're free to view GDC talks or dev shows or even online references I'm sure from industry names will also describe the same system I describe.

"Saddest hype statement ever" Man, don't do that. Respect your craft

what font is that?

can someone explain what should be in Attack class? is it correct? class Attack { int minDamage; int maxDamage; Hero hero; hit(Actor target) { ... } }

@fergal9808

4 жыл бұрын

@Jeremy Russell Couldn't you just make a function out of it though? Wouldn't that be easier rather than having to think of instances etc. ?

@Nezarus0

4 жыл бұрын

@@fergal9808 Well sure you could. You could wrap all behaviours into a static class or a normal function. But then you would have to feed in all the details you need as parameters--which adds complexity because you can now mess up calling the action correctly. You might solve that by passing in the Actor & Target as parameters and have the function sort it all out from there, but now the action functions just became a lot more bloated: do you have nested functions to extract the relevant info from the objects? Do you always have a target? How do you deal with multiple optional targets? How easy is it to add a second type of attack that for whatever reason needs to be handled differently--ranged or touch attacks for example. I'm sure you can think of solutions to these 'problems' I mention, but that is the whole point of this talk: solve problems we run into while developing games. You'll notice Bob uses very soft language when talking about patterns. There really isn't "wrong" and "right" so much as "this is useful" and "this leads to migraines".

I didnt understand anything but still interesting.

dude literally described ecs without performance bonus =)

1:26 did he say: "I beat egg band"?

@Xonatron

2 жыл бұрын

I want to know what he said here too.

@defaultservices3483

Жыл бұрын

@@Xonatron "I beat Angband". It's some roguelike that I don't know anything about except that it's quite respected

@Xonatron

Жыл бұрын

@@defaultservices3483 Thank you!

gpu.doitall(defer), cpu only manages household

@Jkauppa

2 жыл бұрын

gigabyte caches

@Jkauppa

2 жыл бұрын

why did you go into latency main ram? sdram in gigabytes, sdr

@Jkauppa

2 жыл бұрын

you can always raid the sdram sdr blocks to get quad data rates over bandwidth

@Jkauppa

2 жыл бұрын

external l3 cache, same speed

This is not ECS. Components should not have any behavior.

@johnjackson9767

2 жыл бұрын

That's the problem with paradigms - ECS means 20 different things at this point.

@skaruts

2 жыл бұрын

He mentioned this is OOP through composition (12:47). Components aren't exclusive to ECS (and there's many variations of ECS as well).

Hmm I think your implementation of ECS at the beginning is not correct... in ECS entities have no behaviour, they are just a bag of components

@crbrocket

4 жыл бұрын

He was describing the evolution towards ECS the first few examples aren't meant as examples of ECS they were to illustrate the problem ECS was meant to solve. He probably wouldn't want to have an update sure on the component class itself sure albeit depends how it's implemented.

@johnjackson9767

2 жыл бұрын

Even the "bag of components" is a specific design decision that isn't in all ECS implementations.

But this is literally an ECS.

@manawa3832

4 жыл бұрын

which is literally just oop

@yoiang

4 жыл бұрын

My takeaway is that his point wasn't to throw ECS out the window but to organize your components around their gameplay mechanisms rather than technical domains.

@skaruts

4 жыл бұрын

Nah, it's very much OOP, and very little ECS. There's a whole spectrum of ECSs, but ECS is actually a data driven paradigm, where components contain exclusively data -- no functions, that's what the systems are for -- and the entity is either just an ethereal ID that components are bound to, or an object with just an id and a component list, or something of that sort. What he's doing there is very much OOP, but, like he mentioned, it favors composition rather than inheritance, which is usually said to be a good practice. _Entity Component System_ doesn't mean _"a system of components and entities",_ it means _"a paradigm involving entities, components and systems"._ I would argue systems would've been better named as _"processes",_ but...

@swapode

4 жыл бұрын

It's really not an ECS, even his example in the beginning misses the point of an ECS since it's still based on entities carrying their own behaviour and updating themselves. The fundamental point of an ECS is to be data driven with systems consuming components and, crucially, specific combinations of components for crosscutting concerns - not just slightly change way you loop through composition objects. With that approach using an ECS would suddenly feel a lot more natural for a roguelike.

@igorstasenko9183

4 жыл бұрын

as in "if the only tool you have is a hammer( ..err ECS), then you see all problems as a nail"?

ecs is like minecraft in real life

You can make undo by just remembering the whole state=) Much more memory, but don't need to make each command undoable.

Here is the problem, Processors have stopped getting more powerful since 2007ish. Stacking a bunch of them together is their way of fixing this but as software developers, it really fucks up our code. Even using 20 processors at the same time means the game can be 2x as complex as what a 10 core processor computer could have. That is way to limiting, especially compared to the traditional generation jumps such as snes->n64->gamecube. In other words, until better computers arrive, such as quantum computers , we will have the same technology in 2030, 2040, and so on, as now.

@ITR

2 жыл бұрын

We have really good processors already though, we just write really slow programs

@automatic241

2 жыл бұрын

2007 is pulled out of your ass. Single-Core performance increases started to seriously diminish in the mid- to late-2010s The rest is incorrect too. Processors are not the limiting factor anymore. Only for graphics and rendering or research purposes. Normal applications wouldn't massively benefit from more powerful processors.

@NathanielMetrock

2 жыл бұрын

@@automatic241 eh, he said "-ish", when talking decades, that includes mid to late 2010s. yes, moore's law is dead. if we want to write increasingly complex AI, we can no longer fall back on the exponential growth in processing power like we used to. we have to write clean code, which is what code architecture is all about.

@diadetediotedio6918

Жыл бұрын

They actually keep getting more and more powerful, not exactly "exponentially", but significantly in fact. At the moment we are limited by lithography, stability and inevitably by silicon, but as new technologies are developed (like the one you were studying, of using photons to build processors) we will have a gain in processing power. The speed limit we have in our universe is literally how many operations we can do simultaneously close enough to the speed of light threshold.

6:45 This is also slow. Having the update in each component isn't good (components should only be data). The code that does the updating should be in the system itself. I've tested it in javascript, not c, c++, or c#. That's up to you. I can't recall the cause exactly, but I think it has to do with caching the code that's running; so it's similar to the caching issue you talked about, but for the actual code itself. (IIRC)

@cyberpiok439

4 жыл бұрын

Update() function in the Component typically means going through a vtable for being virtual, plus function invocation overhead(push/pop stack stuff). An inlined Update() would get rid of the overhead you're talking about, I believe

Moore's Law never indicated that CPUs got twice as fast every 18 months, but rather that the number of transistors per area in a chip doubled. Also, Moore's Law is basically dead.

using classes for a rogue game...

I hope the books arent written with this font

Well... duh...

LMAO he throws shade at a straw man of ECS and then literally reinvents ECS.

@shan3722

3 жыл бұрын

"I split out each capability that an item has into a separate class" "Whether or not you call it 'component' is kind of an interesting question ... this is just the old principle of preferring composition over inheritance" Wikipedia page for ECS: *_ECS follows the composition over inheritance principle_* that allows greater flexibility in defining entities where every object in a game's scene is an entity... Every entity consists of one or more components which contains data or state.

@lekretka

3 жыл бұрын

He didn't, he is talking about composition in the world of object-oritentation and OO patterns. ECS is data-oriented design, without OO patterns, without behaviour attached to data, and when things done in a completely different way than he is showing in his example.

@shan3722

3 жыл бұрын

@@lekretka His architecture is a bit different from ECS, but his explanation of ECS was completely wrong. He got the Systems part right, but his god class representation of Entities wasn't even close. In fact, his own Entity-Component relationship is exactly the same as in ECS (though the implementation is usually--but not necessarily--data-oriented).

@keldencowan

3 жыл бұрын

@@lekretka Alright, so instead of lumping all the procedures for accessing an object's fields, he separates the functions into data objects that are referenced by the first object. That's the Tao of data oriented (functional) programming. He does this again with the Actor class, it just becomes a data class with all the code in Action objects. OOP is about hiding an object's data as private and giving it a bunch member functions. This is doing the opposite, so it's not _really_ OOP paradigm is it? It's at least Procedural, maybe even DOP. People think ECS is just about data layout and performance, it's just as much about reducing complexity. I'm not saying what he's made is precisely an ECS, more like it's an ECS-lite. All the bits are there in his code, there's just a resistance to dropping the OOP frame of mind in an instance where it is clumsy.

stop talking about Monster and Breed classes in the same sentence. Some people here have watched japanese animated movie art and know where this is going.

@Kavukamari

5 жыл бұрын

my monster comes with a BreedAction object built in which enables uhh you know ;)

@Woodythehobo

4 жыл бұрын

@@Kavukamari ( ͡° ͜ʖ ͡°)

He is a nerd 😂🤣...

this doesnt make any sense to me

The problem with shitty abstractions (high level programming languages being just one example) is that they cover up and distract you from thinking about stuff that really matters (such as algorithms, data structures, and hardware) in favor of some linguistic fantasy. It doesn't just concern game programming, but programming (manipulating data) in general. Pretending too much that things are something else than they are and sweeping critical issues under the rug leads into performance disasters. If you want to use high level abstractions and rely on optimizations through tools such as compilers, you still have to understand how these tools (don't) work. Generally speaking, optimizations are only possible when crucial information is not arbitrarily withheld from the optimizer (which also applies to other processes outside of CS). Performance engineering is similar to accounting, you have to keep in mind where the costs/overheads are and what is causing them.

Always fun to hear Americans failing to pronounce their own last names :D Great talk though!

@seditt5146

5 жыл бұрын

I think it is funnier when people from other countries think they pronounce stuff correctly when they normally swing and miss. Idk how many times I have heard people from the UK swear the US says stuff wrong when they are the incorrect ones. Take this for instance. British would say Nys-Trom with more of a Nay sound or something along those lines where as the US would lean more towards Ny-Strom as in Nii. If you feel this guy pronounced it wrong and the correct version is Naystrom sounding elaborate and explain why that should be correct. I am trying to remember the exact example but I can not remember it at the moment. There is a popular word right now British people always talk about saying USA people say it wrong when it is our word and ya'll are pronouncing it incorrectly. I know one is Al-U-Min-Eum. Aluminum. Ya'll say it straight retarded(if you are part of ya'll that is). I would love to hear a UK persons reasoning for turning the Num into Nium. The I sound was added by British people to make themselves right it seems lol. Now there are two spellings Aluminum and Aluminium. The former is the first and correct way to say and spell it. Technically they are both now the correct ways but why? If the USA took a British word and messed it up it wouldn't become accepted, ya'll pretentious assholes would harp over it 24-7 because of some undeserved superiority complex they have over there.

@UltimaN3rd

5 жыл бұрын

@@seditt5146 Aluminium was discovered by a British scientist who first named it Alumium, then Aluminum before officially settling on Aluminium to conform with the other elements suffixed -ium.

@wastebin996

5 жыл бұрын

@@seditt5146 can you please rewrite this with the ipa en.wikipedia.org/wiki/Help:IPA

@Woodythehobo

5 жыл бұрын

@@seditt5146 has got some major issues holy shit lmao

@skaruts

3 жыл бұрын

You don't mispronounce your own names. You pronounce them the way you were named. And on top of that, English has its own ambiguities with the Ys, among others.