4 ms·

I certainly am unused to it! maybe I’ll ask some advice: I’m trying to build a circuit simulator. It’s got two main problems to solve: placing and connecting

I certainly am unused to it! maybe I’ll ask some advice: I’m trying to build a circuit simulator. It’s got two main problems to solve: placing and connecting drag and drop electrical components, and the simulation itself. How would you go about this? The existence of the sim means there’s already guaranteed to be some global manager that understands the current layout and can compute from it. What I don’t know is if that means most things should be handled that way. Should components be heavy, and make their own changes to the tree, and then let manager read the tree in and build up its schema that way? Or should components be just emit everything to the manager, who then can both build the tree and a state representation. The second feels cleaner for this use case, but it feels not standard for Godot. Maybe it’s a bad project to start with. I did build a basic platformer too, and found the distributed logic much easier to deal with there.

keerthiko 3y ago
> placing and connecting drag and drop electrical components This is where game engines are annoying. You have to do "collision checks" between your cursor and any points of interest, like a slot or a grid or a connection. Usually in a 2D use-case like yours, you can just do a geometry condition (if component.x > slot1.x && component.x < slot1.x + threshold...), especially while your UI elements are regular shapes. Engines are fast at doing lots of native collision checks in 3D and with irregular shapes too with an engine-specific "collider" for each element, as it's expected to do collision checks for almost every visible actor in every frame in a game. > and the simulation itself Depending on the eventual complexity of your circuit simulator, there are pros and cons to different approaches. My undergraduate electronics degree is fading from memory so I might not have the best advice here. A purely node/actor-based computational simulator is one approach, which reduces dependency on the global manager with knowledge of the layout or handling of the computation. You have to define how each component responds to charge at its input nodes, and manipulates charge at its output nodes, ie, define its response curve in terms of charge. You just have to work with the differential time-equations for computational analysis of electric circuits, not the closed-form analytical ones. ie, substitute I with dQ/dt (charge over time) everywhere, and in every "update" iteration (or "tick" or "frame" or whatever your engine calls them) multiply the differential equation by timeDelta (every engine provides timeDelta as the time elapsed since the last frame). I would give this method a try scoping the project for very simple components (maybe just DC power source, LED, resistors, connector junctions) that can be sized to a grid of discrete sizes. This can however feel like rediscovering electricity from first principles because traditional circuit equations usually don't work with charge or with time, since they're defining the steady state behaviour. If you would rather work with traditional steady state electronics formula for each component type, I think your second solution is a decent approach, "passing the result on" from one node into the next (which is the same as making changes to the tree iinm?). Technically using the steady state equations renders ticks irrelevant, other than updating to reflect any changes in the circuit, or if you have time-dependent component behaviour (like an AC signal or an inductor), but that's still a nice feature to have. I think you should try avoiding reliance on a global manager for anything that goes on in the simulation as much as possible, because I sense you will tend towards "centralized application logic" if you allow yourself that luxury. The whole point of game engines is to break down your logic into different actors that interact with each other, and a simulation is exactly that.

keerthiko 3y ago

> placing and connecting drag and drop electrical components This is where game engines are annoying. You have to do "collision checks" between your cursor and any points of interest, like a slot or a grid or a connection. Usually in a 2D use-case like yours, you can just do a geometry condition (if component.x > slot1.x && component.x < slot1.x + threshold...), especially while your UI elements are regular shapes. Engines are fast at doing lots of native collision checks in 3D and with irregular shapes too with an engine-specific "collider" for each element, as it's expected to do collision checks for almost every visible actor in every frame in a game. > and the simulation itself Depending on the eventual complexity of your circuit simulator, there are pros and cons to different approaches. My undergraduate electronics degree is fading from memory so I might not have the best advice here. A purely node/actor-based computational simulator is one approach, which reduces dependency on the global manager with knowledge of the layout or handling of the computation. You have to define how each component responds to charge at its input nodes, and manipulates charge at its output nodes, ie, define its response curve in terms of charge. You just have to work with the differential time-equations for computational analysis of electric circuits, not the closed-form analytical ones. ie, substitute I with dQ/dt (charge over time) everywhere, and in every "update" iteration (or "tick" or "frame" or whatever your engine calls them) multiply the differential equation by timeDelta (every engine provides timeDelta as the time elapsed since the last frame). I would give this method a try scoping the project for very simple components (maybe just DC power source, LED, resistors, connector junctions) that can be sized to a grid of discrete sizes. This can however feel like rediscovering electricity from first principles because traditional circuit equations usually don't work with charge or with time, since they're defining the steady state behaviour. If you would rather work with traditional steady state electronics formula for each component type, I think your second solution is a decent approach, "passing the result on" from one node into the next (which is the same as making changes to the tree iinm?). Technically using the steady state equations renders ticks irrelevant, other than updating to reflect any changes in the circuit, or if you have time-dependent component behaviour (like an AC signal or an inductor), but that's still a nice feature to have. I think you should try avoiding reliance on a global manager for anything that goes on in the simulation as much as possible, because I sense you will tend towards "centralized application logic" if you allow yourself that luxury. The whole point of game engines is to break down your logic into different actors that interact with each other, and a simulation is exactly that.