This is both cool and disappointing. I&#x27;m sure this is more challenging than it looks, and it&#x27;s cool to see emergent complexity from a (seemingly) simply set of conditions to satisfy.<p>However, the reason I think about elevator programming isn&#x27;t to make an elevator behave the way they do today. It&#x27;s to make an elevator behave <i>better</i> than they do today.<p>For example:<p>* I don&#x27;t want an elevator to close and reopen its doors on the same floor. That&#x27;s horrible user experience.<p>* All the interesting problems arise when there are multiple elevators servicing the same set of floors. So let&#x27;s control more than one elevator at the same time.<p>* If the elevator is on the ground floor, and has downward calls on both the 1st and 20th floors, then it is likely more efficient to service the 1st floor first rather than bypassing them just so you can keep travelling in the same direction.<p>I&#x27;d like to see a version of this that, rather than enforcing arbitrary rules, just has a lot of series of inputs and lets people compete to service those inputs in the shortest number of steps.