MCS 275 Spring 2023
Emily Dumas
Reminders and announcements:
Finish our robot simulation class hierarchy
Discuss more OOP theory & practice
WanderBot
walks about randomly.
DestructBot
sits for a while and deactivates.
PatrolBot
walks back and forth.
Instead of manual .update()
experiments, there are two simulation programs:
botsimulation.py
- Active bots shown as *
botsimulation_fancy.py
- Bots have their own symbols, inactive ones
are shown as ☠.Attributes declared in the class definition, outside of any method, are class attributes.
Class attributes are shared by every instance of the class. Often used for constants.
Contrast with the instance attributes we have used thus far (e.g.
self.x = 1
in constructor) which exist separately for each instance.
Takes direction
(vector) and n
(int). Walks n
steps of size
direction
, then n
steps of size -direction
. Repeats
indefinitely.
This robot has internal state:
Keep track of which state we're in. Handle input differently depending on the state. Fixed set of possible states.
if state == "work":
handle_at_work(sms_content)
elif state == "home":
handle_at_home(sms_content)
Handlers may change state depending on the input.
def handle_at_home(sms_content):
if announces_critical_outage(sms_content):
send_reply("on my way")
state = "work"
else:
# deal with it tomorrow
return
Beyond adding more robot types, how might me improve or extend the simulation?
Might create a class Arena
that manages the list of bots and the space in which they
move. Would have a single .update()
method that updates all bots.
Arena
object would be made first, then passed to each robots constructor.
Robots would call Arena
methods to interrogate surroundings (e.g. avoid collision, seek
other
bots, ...)