This is a routing app. The functions given will allow us to calculate the l ength of time it takes to get from origin to destination.
In the future, instead of people choosing a route to their destination, this will be handed over to the automobile. The lesson is how the automobile will make this choice.
Students get randomly numbered and each get an OD (origin, destination) pair in a graph network. The students will choose in-order which route to take to get through the network to their destination that would take the least time (ideall y). Once a student chooses, the "load" on each path through the network is updated s o the next choosing student can determine whether to take a different route to get to their destination quicker. Once all students have chosen their path, this is one iteration through the "gam e". The same order is kept for the next iteration (OR ANOTHER RANDOM ORDER), wit h the first student now instead of seeing an empty network, can see the chosen p aths of everybody else (THROUGH SOME GRAPHICAL DISPLAY). The student then re-cho oses a quicker route, if one exists, through the network (with the same OD pair as before), and the network is updated. Each student does this same thing again until the last student chooses, ending the next iteration. The goal is to reach a "Nash Equilibrium" where given the opportunity to change their route, each student would not as they have their travel time optimized.
One Professor and a number of students (ie 20). The students will be able to access the website with their email address. They will be assigned an order. Pos sibly change user's screen to tell them when it is their turn. Each student are given their origin and destination and will pick which path the y would like to take. Each student will rerun their same path iteratively (multi ple times until a determined amount of times is reached). After the previous stu dent picks their path the next student in order will select theirs. This next st udent may be able to see the congestion from previous students (could use number s or colors to describe how many cars are congesting the area). Choosing paths w ill continue through all students. The instructor will be able to view all the students running through, while the students should only see their own choices (and probably the same congestion as when they started). Instructor would like to save the games. He would like to be able to replay them (and go through them step by step, each step would be addin g a car). He would also like to be able to download them. Instructor can restart the game ( maybe kill some car's paths)
No, not like a conventional "game". Game in the sense of game theory They wil l receive times based on a function given to us
Students have user view, Professor/Scientist has master view w/ controls Pote ntially lock students out of choosing/controls while another student is choosing their path
Mostly Civil Engineering Students
"Super user", any number of regular users
They will use the app concurrently but each student will run sequentially
No, just log in with their email. Store each user uniquely by .mtu email
Desktop and phone. Students will most likely be using their phone while professor controls from desktop
Available by email
Scientist/Professor stressed ability to download/replay games to recap to class how/why choices were made Network: The professor has his own network that he can provide We also discussed doing our own using google maps, leaflet, or street view. (Openstreetmap: open source maps) ***This would be a lot of extra work and we would have to make our own networks***
Check his google calendar to find a meeting time He is available at 3:30 on Thursday unless he is out of town PhD student can help if he's out of town
Provide options via email
Yes, but heavily not preferred
2 weeks from second meeting
2 weeks from second meeting The maps will have on average 3-4 times more edges than nodes
After every student's turn
Admin option for either