I would begin by asking the following clarifying questions:

• -Are there any special use cases such as VIP Penthouse access, restricted floors etc?
• -Do we need to consider safety requirements or other technical constraints such as maximum load/capacity?
• -If the lobby for the building located on the ground floor? Can we assume that the majority of the guest amenities are located near the lobby and lower floors?
• -Can we assume that the passenger controls on the floors are purely directional(up and down)?

Let’s assume a simple scenario with no special use cases, no safety or technical considerations and a standard building layout with the lobby and public amenities located on the ground floor.

With these inputs, our goals should be to optimize the elevator algorithm for efficiency and good user experience as follows:

• -The elevator should move sequentially through requested floors in the same direction, moving from the lowest requested floor to the highest requested floor in the up direction, and from high to low in the down direction -> This will ensure that users do not get confused or frustrated about their desired direction and will also ensure that the elevators more energy-efficient.
• -The elevator should continually process passenger requests and update their route/stop plan dynamically -> This will lower wait times for waiting passengers and ensure the elevators are handling requests in a timely manner.
• -When there are no requests, the elevators should idle on different floors respectively (the lobby or the 100th floor)

Zooming into a more detailed view of the whole experience affords us the opportunity to establish further constraints and rules:

• -A single elevator proceeds in the same direction until the last request in that direction. It will then remain idle until the next request comes in, then it will proceed in the direction of that request.
• -Requests or signals from passengers are received and logged in memory, the elevator prioritizes passenger pickups/dropoffs from floors that it is closest to at the (time of request) and where passenger moving in the same direction
• -When a passenger gets on, they select the floor they would like to be dropped off at, the elevator queues drop-offs sequentially all the while optimizing and updating the route plan with incoming pickup requests
• -The elevator cannot pick up passengers if their request comes in when the elevator has already traveled past the floor that the elevator is currently passing or stopped at i.e. it cannot switch directions and pick up a passenger.

To translate these requirements into an algorithm for a single elevator I would split the mechanics and design a modular system as follows:

• -Implement a Listen/Queue controller that is constantly listening for new requests and dynamically updating the queue with passenger pickup and destination requests.
• -Implement a Move controller that is constantly checking the elevator’s current floor and issuing commands for the elevator’s three main actions -> STOP and GOTO (floor) and IDLE

Then I would establish the following constants and variables for use in the algorithm logic:

Variables

Let Request Floor**(RF)** = the floor that elevator must stop at to pickup or drop-off a passenger

Let CurrentFloor**(CF)** = the floor that elevator is currently stopped at or is just traveling past.

Let PassengerDirection(PDir) = the direction in which the passenger wishes to travel

Let ElevatorDirection(EDir) = the direction in which the elevator is going

Let RequestQueue = a dynamically changing array of floors that the elevator uses to store it’s requests

Listen & Queue Module Logic

1. Receive incoming RF. Receive PDIR(in the case of pickup only).
2. If (PDIR == EDIR) && (RF > CF) *this is specific to a lift moving in the up direction, (RF < CF) for down
3. Add RF to RequestQueue
4. Sort RequestQueue (by ascending or descending depending on EDir)
5. Start Move Module

Move Module Logic

6. Process RequestQueue if RequestQueue is not empty
   1. RequestQueue.first === CF? -> Comparing first item of RequestQueue with the elevator’s current floor (this should be happening continuously on every floor).
      1. If Yes, then
         1. STOP at CF ((passenger exits or gets on at CF)
         2. Remove this RF from the RequestQueue
         3. Go back to Step 1
      2. If No, then
         1. GOTO CF + 1 (next floor)
7. Else if RequestQueue is empty 2. IDLE at Ground Floor (IF CF< 50) OR IDLE at Floor 100 IF CF > 51 && <=100

The Listen Module logic is run any time a request is received, ensuring that the queue is always sorted sequentially, it is also responsible for initially kicking off the Move Module logic. However, the control flow in the Move Module should handle the routing and subsequent actions for the elevator.

Further Considerations

To understand whether this algorithm is working efficiently and delivering a good user experience, I would want to track the following metrics at a minimum:

• -wait times per elevator(passenger)
• -average time spent in the elevator per cycle (passenger)
• -cycle times (the time it takes the elevator to go from first to the last point)
• -average number of stops per cycle

Naturally, it would be prudent to drill down onto time of day (peak vs. off-peak), day of the week and season(hotel holiday periods). If any patterns or trends are established from this analysis, we could then tweak or develop the algorithm further.