A Simple Discrete-Event Simulation: Part 37

Today I finished putting together a basic Path component. It mostly works like a queue but it has “physical” dimensions that take time for the entities to traverse. It also draws the path, its endpoints, and any entities in their proper positions.

The Path is component three in the demo. It’ll take a lot of clicks to get through it.

(Click on the “Step” button to advance through the model, refresh the page to run it again.)

Here’s the code for the Path component.

Here’s how the Path component is instantiated and initialized. In the longer run we want a very generalizable element that can connect anything to anything, including to other Paths. In practice we’ll define nodes independently and then link the paths to pairs of nodes so that completely arbitrary networks can be defined. For now the endpoints are defined directly within the Path component. The Path has an implied direction, and elements can only move along it one way. That said, the path can go in any direction on the screen and the code will handle it naturally.

If entities are moving along the path they are going at the assigned speed; there is no mechanism for accelerating and decelerating. That can be added later if we want. Entities are assumed to have a radius of five and require a clearance of two. For the time being the units of measure are in screen pixels. Later we’ll have to add in the ability to scale the elements, which will add another layer of complexity. If an element cannot move the full distance it “wants” to, because it has to wait for an element in front of it to move out of the way, it pauses for a definable interval (I think one time unit in the demo) and then tries to move again. This is akin to simulating the reaction time of people or vehicles edging forward in queues. They don’t all move in lockstep, they take a certain amount of time to react to the space that opens up in front of them.

I had to add another layer of complexity to the discrete event handling mechanism because we are treating the moving entities as being entirely passive. If an entity within a component needs to be moved according to independent logic that uses the discrete event handling mechanism, then the item that goes into the future events queue has to carry information about the component and the specific entity within the component. Looking at the relevant calls:

Here’s the updated definition of the newItem method in the FutureEventsQueue object. The only change is that it passes the newly added fourth parameter, the one pointing to the internal entity, to the new FutureEventItem call.

Here’s the updated code for the FutureEventItem object. All it does is store the extra entity reference.

Here’s the working result of all this, in the activate method of the Path component:

JavaScript is bizarre in many ways but one of the nice things about it is that if you choose not to include parameters at the end of the list for function calls, and the relevant variables or parameters are never accessed, then everything goes on working as before. That means that all the other uses of this mechanism that don’t use the extra entity parameter will continue to work without modification. We have to keep track of this kind of thing carefully. JavaScript won’t let you shoot yourself in the foot in the same way that C or C++ will, but it’ll give you a whole new set of creative ways to do it.

There are some other things that bear further description but I’ll get to those shortly.

I want to observe that I do most of my editing in Notepad++ but I occasionally use WebStorm to help me find certain classes of errors I introduce. I typically do this when the debugger in Firefox refuses to display the code, which means it had trouble parsing something, and I can’t find the error quickly. I may then go through the code to follow some of WebStorm’s suggestions about style, through not all of them. I’ve turned off flipping if-else statements and eliminating curly brackets in one-line loops and if statements, for example.

I do not use WebStorm for interactive debugging because it doesn’t have access to the DOM. That’s only accessible to the debugger built into each browser.

This entry was posted in Simulation and tagged , . Bookmark the permalink.

Leave a Reply