| 00:02:54 | * | kulelu88 left #nim ("Leaving") |
| 00:11:59 | * | irrequietus quit () |
| 00:14:41 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 00:18:11 | * | gokr quit (Ping timeout: 264 seconds) |
| 00:19:20 | * | gokr joined #nim |
| 00:23:15 | * | jaco60 quit (Ping timeout: 240 seconds) |
| 00:23:26 | * | gokr quit (Ping timeout: 240 seconds) |
| 00:24:39 | * | gokr joined #nim |
| 00:37:26 | * | ephja quit (Ping timeout: 240 seconds) |
| 00:55:19 | Araq | cryzed: in a nutshell: yes. |
| 00:56:15 | strcmp1 | what about a crab shell |
| 00:56:18 | strcmp1 | any different in that case |
| 00:57:14 | Araq | all shells are crappy |
| 00:59:54 | strcmp1 | yeah try telling a turtle that |
| 01:02:45 | Araq | I only need to put it on its back |
| 01:03:27 | strcmp1 | lol |
| 01:05:56 | * | gokr quit (Quit: Leaving.) |
| 01:18:12 | cryzed | Araq, oh -- so I'll have to rely on generics? |
| 01:18:31 | Araq | methods + generics don't work. |
| 01:18:34 | cryzed | basically if I want to use the component stuff as some library, I'll probably have to instantiate it as newGameObject[MyComponentType](...) |
| 01:18:45 | cryzed | well... |
| 01:18:58 | cryzed | then I have no idea what I'm doing |
| 01:19:18 | Araq | in retrospect it was a big mistake that the compiler even tries to "support" this construct |
| 01:19:43 | Araq | but then IMHO the whole language would be better without the 'method' keyword |
| 01:19:57 | cryzed | without dynamic dispatching? |
| 01:20:01 | Araq | yeah |
| 01:20:22 | Araq | when I need dyndisp, I use a closure. works much better anyway. |
| 01:20:53 | cryzed | Well then I'll have to reconsider how implementing such a component architecture would work better in Nim |
| 01:21:29 | Araq | a component architecture ... well nobody knows how to design these afaict |
| 01:21:48 | Araq | I did some research and took some notes |
| 01:22:22 | cryzed | http://gameprogrammingpatterns.com/component.html I wanted to design code close to this |
| 01:23:01 | * | Trustable quit (Quit: Leaving) |
| 01:23:28 | cryzed | basically pass in multiple component classes managed by a container object (gameobject). When you call update on the container, it calls update on all components which are able to modify its state or broadcast messages through the container to other components |
| 01:23:50 | cryzed | Which, in theory, should allow you good seperation of concerns and reusability |
| 01:26:48 | * | pregressive joined #nim |
| 01:31:52 | cryzed | Araq, so do you have any pointers for me where I could start? I suppose by removing all method calls, and using procs with generics? |
| 01:32:21 | Araq | well I would say this is always a good idea :P |
| 01:34:37 | Araq | well I don't know your background etc. but I suggest you write the game and then later see how it can be refactored into components |
| 01:34:51 | cryzed | I am trying to write the game, using components |
| 01:35:04 | cryzed | so I don't have to put code from every part of the system into the entity's update method |
| 01:35:17 | * | liori joined #nim |
| 01:36:12 | Araq | I wouldn't care until the game's code becomes big enough to be barely managable |
| 01:36:31 | cryzed | hm |
| 01:36:53 | Araq | usually it's much easier to see better designs at this stage rather than anticipating of what could go wrong |
| 01:37:09 | cryzed | Alright, I might do that then. |
| 01:37:42 | cryzed | for now it's just snake anyways |
| 01:37:51 | cryzed | and then I wanted to progress to something like a dungeon crawler/roguelike |
| 01:38:19 | Araq | also you should always clearly distinguish between *ugly* code and *error prone* code. |
| 01:38:42 | Araq | programmers usually act like these are the same. They are not. |
| 01:39:26 | Araq | in other words study where the bugs come from. |
| 01:40:02 | cryzed | You are trying to say that having the update method of entities access most parts of the system isn't really error-prone, just maybe not that nice? |
| 01:40:34 | * | sqwishy quit (Read error: Connection reset by peer) |
| 01:41:08 | Araq | no, I don't have enough experience with games to say that. |
| 01:41:15 | * | sqwishy joined #nim |
| 01:41:33 | cryzed | Ah ok, you are indicating that might be the case and to not overengineer from the beginning |
| 01:41:41 | Araq | exactly. |
| 01:41:43 | cryzed | I wanted to start out with good practices, that's all |
| 01:41:49 | cryzed | but maybe getting my hands dirty will help me more |
| 01:41:56 | cryzed | and well.. let me make any kind of progress |
| 01:44:08 | cryzed | I have never used closures in nim, I didn't even know that was possible |
| 01:53:58 | * | [CBR]Unspoken quit (Ping timeout: 272 seconds) |
| 01:55:02 | liori | are strings mutable? |
| 01:55:12 | cryzed | yes |
| 01:55:37 | * | [CBR]Unspoken joined #nim |
| 02:23:26 | * | jakesyl quit (Ping timeout: 250 seconds) |
| 02:35:52 | * | Demon_Fox joined #nim |
| 02:36:20 | * | jakesyl joined #nim |
| 03:06:11 | * | vendethiel joined #nim |
| 03:27:37 | * | Demon_Fox quit (Remote host closed the connection) |
| 03:30:10 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 03:39:04 | * | Demon_Fox joined #nim |
| 03:49:59 | * | kniteli joined #nim |
| 04:00:42 | * | pregressive quit (Remote host closed the connection) |
| 04:00:55 | * | pregressive joined #nim |
| 04:01:03 | * | pregressive quit (Remote host closed the connection) |
| 04:01:19 | * | pregressive joined #nim |
| 04:34:28 | * | Demos quit (Read error: Connection reset by peer) |
| 04:48:46 | * | sqwishy quit (Read error: Connection reset by peer) |
| 04:49:25 | * | sqwishy joined #nim |
| 04:57:00 | * | kniteli quit (Ping timeout: 272 seconds) |
| 05:08:47 | * | pregressive quit (Remote host closed the connection) |
| 05:09:23 | * | pregressive joined #nim |
| 05:10:33 | * | pregressive quit (Read error: Connection reset by peer) |
| 05:10:47 | * | pregressive joined #nim |
| 05:22:35 | * | darkf joined #nim |
| 05:54:17 | * | xet7 joined #nim |
| 05:57:11 | * | Demon_Fox quit (Quit: Leaving) |
| 06:03:26 | * | pregressive quit (Remote host closed the connection) |
| 06:06:13 | * | lokulin quit (Quit: bye!) |
| 06:39:42 | strcmp1 | did twitter only exist since 2013 or did another republican presidential candidate talk a bunch of shit yet again |
| 06:40:00 | strcmp1 | sry |
| 06:40:03 | strcmp1 | wrng buffer |
| 07:42:02 | * | Sembei joined #nim |
| 08:23:30 | * | gokr joined #nim |
| 08:26:28 | * | gokr quit (Client Quit) |
| 08:26:31 | * | gokr1 joined #nim |
| 08:31:20 | * | BitPuffin|osx quit (Ping timeout: 255 seconds) |
| 08:36:57 | * | lyro quit (Quit: WeeChat 1.1.1) |
| 09:13:38 | * | lyro joined #nim |
| 09:42:56 | * | jaco60 joined #nim |
| 09:44:10 | * | jck_ joined #nim |
| 09:46:44 | * | sepisoad joined #nim |
| 09:47:46 | * | _stowa_ joined #nim |
| 09:48:14 | * | Araq_ joined #nim |
| 09:48:28 | * | cryzed_ joined #nim |
| 09:48:41 | * | Yaiyan_ joined #nim |
| 09:48:47 | * | someplac- joined #nim |
| 09:49:01 | * | r-ku- joined #nim |
| 09:49:14 | * | Amrykid2 joined #nim |
| 09:49:44 | * | dom96_ joined #nim |
| 09:49:51 | * | gsingh93- joined #nim |
| 09:49:55 | * | gsingh93 quit (*.net *.split) |
| 09:49:56 | * | someplace quit (*.net *.split) |
| 09:49:56 | * | r-ku quit (*.net *.split) |
| 09:49:57 | * | jck quit (*.net *.split) |
| 09:49:58 | * | cryzed quit (*.net *.split) |
| 09:49:58 | * | bbl_ quit (*.net *.split) |
| 09:49:59 | * | _stowa quit (*.net *.split) |
| 09:49:59 | * | Araq quit (*.net *.split) |
| 09:50:00 | * | dom96 quit (*.net *.split) |
| 09:50:00 | * | Amrykid quit (*.net *.split) |
| 09:50:00 | * | nim-buildbot quit (*.net *.split) |
| 09:50:00 | * | Xe quit (*.net *.split) |
| 09:50:00 | * | Yaiyan quit (*.net *.split) |
| 09:50:02 | * | wh1t3r0s3 quit (*.net *.split) |
| 09:50:06 | * | dom96_ is now known as dom96 |
| 09:50:46 | * | gsingh93- is now known as gsingh93 |
| 09:50:56 | * | Xe joined #nim |
| 09:51:09 | * | sepisoad quit (Read error: Connection reset by peer) |
| 09:56:23 | * | bbl_ joined #nim |
| 09:59:38 | * | buMPnet joined #nim |
| 10:00:54 | * | OmlkRoNiXz joined #nim |
| 10:03:38 | * | xet7_ joined #nim |
| 10:07:24 | * | _stowa_ is now known as _stowa |
| 10:12:08 | * | xet7 quit (*.net *.split) |
| 10:12:09 | * | Jesin quit (*.net *.split) |
| 10:12:12 | * | M-max quit (*.net *.split) |
| 10:12:13 | * | Amun_Ra quit (*.net *.split) |
| 10:12:15 | * | buMPnet_ quit (*.net *.split) |
| 10:12:16 | * | OmIkRoNiXz quit (*.net *.split) |
| 10:13:26 | * | M-max joined #nim |
| 10:17:52 | * | Jesin joined #nim |
| 10:22:51 | * | Amun_Ra joined #nim |
| 10:41:38 | * | lokulin joined #nim |
| 11:11:22 | * | thotypous quit (Quit: WeeChat 1.3) |
| 11:11:42 | * | thotypous joined #nim |
| 11:13:16 | * | ephja joined #nim |
| 11:28:42 | * | Trustable joined #nim |
| 11:42:17 | * | filcuc joined #nim |
| 11:54:34 | * | jakesyl quit (Ping timeout: 250 seconds) |
| 12:48:26 | * | wh1t3r0s3 joined #nim |
| 12:56:54 | * | gokr1 quit (Read error: Connection reset by peer) |
| 12:59:08 | * | gokr joined #nim |
| 13:15:52 | * | wh1t3r0s3 quit (Read error: Connection reset by peer) |
| 13:17:23 | * | pregressive joined #nim |
| 13:23:58 | * | Demon_Fox joined #nim |
| 13:36:51 | * | wh1t3r0s3 joined #nim |
| 13:40:59 | Araq_ | cryzed_: https://en.wikipedia.org/wiki/Entity_component_system is a pretty good description of an entity component system that seems easy enough to implement in Nim |
| 13:46:57 | * | n1ftyn8_ quit (Quit: Connection closed for inactivity) |
| 13:56:43 | * | gokr quit (Ping timeout: 260 seconds) |
| 14:02:48 | * | razaaa joined #nim |
| 14:02:49 | * | razaaa quit (Read error: Connection reset by peer) |
| 14:03:09 | * | razaaa joined #nim |
| 14:03:10 | * | razaaa quit (Read error: Connection reset by peer) |
| 14:06:16 | * | Demon_Fox quit (Quit: Leaving) |
| 14:07:48 | * | pregressive quit (Remote host closed the connection) |
| 14:22:24 | * | Demon_Fox joined #nim |
| 14:40:02 | cryzed_ | Araq_, that's what I attempted to do but quickly ran into issues with |
| 14:40:20 | cryzed_ | well since theres no real usable dynamic dispatching, at least from what I can see |
| 14:40:36 | cryzed_ | I'm not even sure how to store a bunch of entities in an array and later differentiate them without having to rely on variant objects |
| 14:41:02 | * | cryzed_ is now known as cryzed |
| 14:43:19 | cryzed | I planned for my components to "contain" or expose the functions that would in the end modify the entity |
| 14:44:14 | cryzed | But since I can't store component subclasses in a seq within the entity, without them being handled like superclass components (i.e. I lose? dynamic dispatching for my subclassed types?) |
| 14:44:17 | cryzed | I'm not sure what to do |
| 14:45:26 | Araq_ | cryzed: well you don't need anything like that if an entity is simply an ID anyway |
| 14:46:04 | Araq_ | the physics component can operate on a seq of physics data |
| 14:46:49 | Araq_ | every component needs a register(id)/unregister(id) |
| 14:47:22 | Araq_ | iterating over every component is trivial to refactor into a template/macro |
| 14:48:58 | Araq_ | with IDs you also don't need to store which components are active for the entity since physicsManager.unregister(id) can simply be a nop for non-existing IDs |
| 14:50:08 | Araq_ | or you can store the active components as another component |
| 14:51:33 | cryzed | Araq_, thanks I'll see if I can implement this in a nice way |
| 15:06:34 | * | pregressive joined #nim |
| 15:09:03 | * | Sornaensis quit (Excess Flood) |
| 15:09:31 | * | Sornaensis joined #nim |
| 15:30:19 | * | pregressive quit (Remote host closed the connection) |
| 15:32:58 | cryzed | Araq_, so basically if I had a physicscontroller which would allow an entity to have a position/velocity for example, it would go like this: If I have list of controllers, implementing functionality in their "update" procs for example. Internally I manage an array of unique IDs associated with the given behaviour. So when I call game.update() in the mainloop, I iterate over every controller, which in turn iterates over every entity ID managed |
| 15:32:58 | cryzed | by them and updates them. If there's interdependency between controllers, I could simply givem the references to each other and do something like physicsController.get(id) in the graphicsController to draw the graphics for the entity at the correct position |
| 15:34:06 | Araq_ | that is correct |
| 15:35:12 | cryzed | Alright, I'll try this. I just wanted to do it the other way around initially, i.e. call update on every entity so that the components associated with it can modify the entity -- but I suppose the other way around works just as well |
| 15:37:02 | * | pregressive joined #nim |
| 15:37:04 | Araq_ | usually you also have descriptors |
| 15:37:27 | Araq_ | that are like type information |
| 15:37:59 | Araq_ | and describe if the object is a unit, a weapon, a doodad |
| 15:38:24 | cryzed | so I can implement customized behavior in the controllers? |
| 15:38:41 | cryzed | no, hm, I think that would defeat the purpose |
| 15:39:20 | cryzed | I agree, I just dont know where I would use that information currently |
| 15:39:52 | Araq_ | another interesting question is how many components exist |
| 15:41:37 | Araq_ | if I understand it correctly, components are hard coded and there are only few |
| 15:42:31 | Araq_ | which means seq[Component] is misguided and instead you can have 'fieldA: ComponentA; fieldB: ComponentB; ...' directly in the entity |
| 15:43:25 | Araq_ | but then you don't get the memory layout optimizations that Entity-component-frameworks also strive for |
| 15:43:33 | Araq_ | bbl |
| 16:05:06 | * | pregressive quit (Remote host closed the connection) |
| 16:05:36 | * | pregressive joined #nim |
| 16:13:00 | * | zaquest quit (Remote host closed the connection) |
| 16:13:11 | * | kulelu88 joined #nim |
| 16:13:11 | * | kulelu88 quit (Changing host) |
| 16:13:11 | * | kulelu88 joined #nim |
| 17:08:52 | * | Demon_Fox quit (Quit: Leaving) |
| 17:09:02 | * | gokr joined #nim |
| 17:12:25 | * | gokr quit (Client Quit) |
| 17:28:50 | * | filcuc quit (Ping timeout: 260 seconds) |
| 17:29:11 | * | cyraxjoe joined #nim |
| 17:33:53 | * | xet7_ is now known as xet7 |
| 17:38:01 | * | BitPuffin|osx joined #nim |
| 17:39:30 | * | zaquest joined #nim |
| 18:06:53 | * | Jesin quit (Ping timeout: 255 seconds) |
| 18:09:59 | * | gokr joined #nim |
| 18:16:44 | * | darkf quit (Quit: Leaving) |
| 18:20:36 | * | vendethiel joined #nim |
| 18:32:07 | * | Jesin joined #nim |
| 18:56:31 | * | sepisoad joined #nim |
| 18:59:33 | * | sepisoad quit (Read error: Connection reset by peer) |
| 19:15:33 | flyx | is it possible to get the nth element of an OrderedTable? |
| 19:16:33 | Araq_ | good question. |
| 19:17:38 | flyx | yeah, I worked hard on it. |
| 19:19:16 | Araq_ | I don't think that's exposed, but |
| 19:19:28 | flyx | I guess I can use pairs n times |
| 19:19:32 | Araq_ | the implementation uses a linked list under the hood |
| 19:19:47 | Araq_ | so access would be O(n) anyway |
| 19:19:54 | flyx | thought so |
| 19:19:59 | Araq_ | and you might indeed just use the iterator then |
| 19:21:51 | flyx | yeah, I guess I'll do that |
| 19:22:01 | flyx | I don't expect the table to grow large anyway |
| 19:27:20 | * | Matthias247 joined #nim |
| 19:28:27 | flyx | hmm, what's the difference between []= and add() for tables? documentation says add() inserts the pair *even if t[key] already exists*. so it replaces the old value? |
| 19:32:25 | Araq_ | yes |
| 19:32:52 | flyx | but []= also replaces it…? |
| 19:47:51 | * | Demos joined #nim |
| 19:54:39 | juanfra | Can anyone help me with this? http://forum.nim-lang.org/t/1877 . I would like generate the tarball to test devel on openbsd. |
| 20:06:25 | Araq_ | no, []= replaces, add adds |
| 20:06:51 | Araq_ | juanfra: 'koch csources && koch xz' |
| 20:08:43 | Araq_ | or something like that |
| 20:09:11 | Araq_ | there is a wiki page about it |
| 20:17:39 | * | boopisaway is now known as boop |
| 20:19:00 | flyx | so, I can have multiple entries with the same key in a Table? |
| 20:20:17 | cryzed | []= maybe only works of the key already exists? |
| 20:20:22 | cryzed | *if |
| 20:36:48 | * | pregressive quit (Remote host closed the connection) |
| 20:41:54 | * | nande joined #nim |
| 20:43:26 | * | kulelu88 quit (Ping timeout: 240 seconds) |
| 21:02:12 | * | kulelu88 joined #nim |
| 21:04:56 | cryzed | Araq_, after some thinking: I'll think I'll do it something like this: Have an entity type, which is just a synonym for an int. Have a component type, that holds raw data: For example a sprite or coordinates. Have systems that connect entities to component instances (XSystem creates XComponent for the entity) with as Table internally. Then all the code lives in the System instance which has a proc update defined. This update proc is called in |
| 21:04:57 | cryzed | the mainloop, for example for the transform/physics system it would simply be update(timeDelta: int), whereas the graphics system update-proc might also get a SDL surface. Because you can have multiple system instances, it's possible to easily suspend a whole subsystem by simply not calling update for a whole -- making it possible to have separate windows/interfaces etc. at runtime easily (i.e. create a graphicssystem instance for some |
| 21:04:57 | cryzed | window, which the mainloop updates but stops updating the normal game graphics-system or some such). Communication between systems is handled by accepting dependencies to other system instances during initialization -- that way it's possible to have pools of entities/systems that only talk to each other, because they either only need to know about each other or they represent a subset of all entities within the game. I haven't really |
| 21:05:02 | cryzed | considered this much yet, but if I add an EventSystem and simply associate each Entity with an EventComponent that can hold a sequence of events, I could also emit events that would be consumed by other systems. This should in theory allow threading: i.e. instead of modifying Component instances returned by the System when talking to each other, events are simply emitted which should be threadsafe insofar that I use a simple locking mechanism |
| 21:05:07 | cryzed | for the EventSystem. But yeah, this is just an inaccurate approximation and I'll probably run into troubles |
| 21:08:35 | Araq_ | flyx: that is correct |
| 21:08:38 | cryzed | well that seems like rambling |
| 21:11:27 | ldlework | are you talking about an entity component system? |
| 21:11:41 | cryzed | ldlework, yes |
| 21:11:47 | ldlework | fowl built one already |
| 21:11:50 | cryzed | trying to implement one in Nim |
| 21:12:06 | ldlework | Why would you need communication between systems? |
| 21:12:13 | cryzed | Not sure, I've never used one |
| 21:12:26 | ldlework | I use ECS in javascript. Never needed communication between systems. |
| 21:12:27 | cryzed | where is their system? |
| 21:13:07 | ldlework | The whole point of ECS is to create a system wherein application logic is physically divided based on data dependencies |
| 21:13:15 | ldlework | So a system should be completely self-contained |
| 21:13:50 | ldlework | cryzed: on their github somewhere I imagine |
| 21:13:59 | ldlework | be warned, fowl is too smart for his own good |
| 21:14:06 | ldlework | his code is strange and alien |
| 21:14:33 | cryzed | ldlework, what if I have some system that suddenly tells some entity "yeah this guy needs to fly really high into the air now" imagine he took some item or something |
| 21:14:39 | cryzed | how would I tell that to the physics-system |
| 21:14:59 | ldlework | That's not how it works |
| 21:15:10 | cryzed | how would I implement that behavior elsewise |
| 21:15:19 | ldlework | You have a system, whatever system you're taking about, and it consumes entities that have a physics component. |
| 21:15:49 | ldlework | The system we're talking about doesn't talk to some other system in order to get the data in the physics component to reflect a change in velocity, this system is the one that does it. |
| 21:15:59 | cryzed | yes, and through that physics component I want to implement a jump into the air when the entity takes a potion or some such |
| 21:16:03 | ldlework | no |
| 21:16:13 | ldlework | components are _just data_ |
| 21:16:14 | ldlework | nothing else |
| 21:16:17 | ldlework | no code whatsoever |
| 21:16:24 | cryzed | Yep. The code lives in the system, I know |
| 21:16:38 | cryzed | how do I signal a sudden change in velocity of an entity from another system |
| 21:16:43 | ldlework | "and through that physics component I want to implement a jump into the air when the entity |
| 21:16:50 | ldlework | by changing the data in the physics component |
| 21:17:09 | cryzed | So the physics component has ties to the item system? |
| 21:17:17 | cryzed | eh |
| 21:17:18 | cryzed | system |
| 21:17:19 | ldlework | There are no ties - anywhere |
| 21:17:34 | ldlework | Think of it like this |
| 21:17:38 | ldlework | There *ARE NO SYSTEMS* |
| 21:17:51 | ldlework | A system, is just a function you call, passing in a set of entities. |
| 21:17:57 | ldlework | The function, is an entry point to a code path |
| 21:18:07 | ldlework | Based on the details of the data inside the entities |
| 21:18:12 | ldlework | when you call the function |
| 21:18:12 | cryzed | yes. |
| 21:18:14 | ldlework | and pass the data |
| 21:18:19 | ldlework | a certain code path will be followed |
| 21:18:27 | ldlework | that code path, will call other library functions |
| 21:18:37 | ldlework | like, say, to update stuff inside of physics components |
| 21:18:50 | ldlework | if this top-level function, ever, anywhere, calls code that works on physics components |
| 21:19:02 | ldlework | thne this top-level function must be passed entities that have physics components |
| 21:19:08 | ldlework | there is no "physics system" |
| 21:19:11 | ldlework | or "item system" |
| 21:19:17 | ldlework | there are only components that contain data |
| 21:19:26 | ldlework | and API for querying entities that have specific components |
| 21:19:34 | cryzed | So how would you implement what I asked? |
| 21:19:43 | ldlework | and top-level routines that take entities, and may or may not call some library code that works on specific components |
| 21:20:19 | ldlework | If you understand what I just said, that should be clear. |
| 21:20:23 | ldlework | You have a function |
| 21:20:25 | ldlework | that does what you want |
| 21:20:30 | ldlework | based on what that function does |
| 21:20:43 | ldlework | that function has a list of implicit component depndencencies |
| 21:20:56 | ldlework | make sure when you call that function, to make it do what it does, that you pass the right entities to it. |
| 21:21:11 | cryzed | The only logical way I can see is getting the PhysicsComponent associated with that entity, changing the velocity attribute and the next time the Physics "system" is called it will change the coordinates based on that new velocity |
| 21:21:20 | ldlework | Yes. |
| 21:21:55 | ldlework | process_status_effects(entities) |
| 21:22:16 | ldlework | in some ECS Systems are raised up to first-class objects |
| 21:22:22 | ldlework | and their dependnecies are made explicit |
| 21:22:25 | ldlework | by listing them |
| 21:22:41 | ldlework | and then you can audit the entities passed in for the requried components |
| 21:23:06 | ldlework | but in the end, the actual list of dependencies is resolved based on what the function does and what component-using library code is called from that code path |
| 21:23:23 | ldlework | If you want to get fancy |
| 21:23:39 | ldlework | you can even make it so that systems go ahead and query the entity API themselves for the enetities relevant to them |
| 21:25:21 | cryzed | I don't for now, this is my first game with Nim and a custom ECS -- at least I hope it will be. But thank you, I'll try to implement this for now and see where it leads me |
| 21:26:05 | ldlework | The hardest part of ECS is making entity querying efficient |
| 21:51:45 | * | tmm1 joined #nim |
| 22:25:34 | * | mat4 joined #nim |
| 22:29:46 | * | tmm1 quit (Ping timeout: 276 seconds) |
| 22:38:21 | * | Jesin quit (Quit: Leaving) |
| 22:38:57 | juanfra | Araq_: thanks for the help. "nim c koch && ./koch csource && ./koch xz" worked fine. |
| 22:41:06 | * | Jesin joined #nim |
| 22:49:05 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 22:50:21 | * | mat4 quit (Quit: Verlassend) |
| 22:58:30 | * | tmm1 joined #nim |
| 23:02:20 | * | lazypenguin quit (Ping timeout: 250 seconds) |
| 23:07:51 | * | tmm1 quit (Ping timeout: 260 seconds) |
| 23:10:02 | * | Trustable quit (Remote host closed the connection) |
| 23:15:27 | * | lazypenguin joined #nim |
| 23:17:59 | * | kulelu88 quit (Ping timeout: 265 seconds) |
| 23:19:53 | * | brson joined #nim |
| 23:31:02 | * | kulelu88 joined #nim |
| 23:32:04 | * | tmm1 joined #nim |
| 23:36:53 | * | boop is now known as boopisaway |
| 23:48:06 | * | tmm1 quit (Ping timeout: 240 seconds) |
| 23:57:39 | * | tmm1 joined #nim |