If everything is right to this point then additional components and logic should be able to be added in any way desired. The complexity was increased by quite a lot and only turned up one minor code change. That’s a win in my book. I also compressed the 2D display components a little bit more.
What we have here is a system with three primary process points. Twenty percent of the entities processed are routed over to the secondary queue, which feeds two secondary processes. From there, twenty percent of the entities go to the secondary exit while most go to the primary exit. This might represent a manufacturing system with a primary inspection step. Items failing the inspection get sent to a secondary process to see if the issue can be fixed. If not, the item gets scrapped. If the model was of a simple land border crossing the secondary exit would represent a return to the country of origin. With just a few components we can model a wide variety of processes, but that won’t stop us from adding even more components to give us even more capabilities.
The simulation is taking longer and longer to run with increasing complexity, as we might expect. However, the framework currently redraws the scene after every individual event is processed and can only update sixty times per second. This is great for single-step debugging but a little painful to watch. What we’ll do, then, is change the framework to update the display in uniform increments of modeled time. That speeds things up a lot when a bunch of things are happening in rapid succession but slows things down when not much is happening. I will ultimately give the user complete control over how this update process is handled, including the ability to run the model with no animated display at all. At some point the various animations are only there to confirm that the model is working the way we want it to. The results it generates are entirely independent of the display.
Results? We’ll talk about how to generate those going forward as well.