Howdy everyone! This week is National Engineers’ Week, or as we like to call it at USC – EWeek! It’s a fun week filled with activities to celebrate being an engineer and all that we do. We kick off the week with a carnival, and there’s always something going on throughout the week, like the Quiz Bowl and Talent Show. To finish off the week right, Friday is the Viterbi Ball, where the King and Queen of Viterbi are named by popular vote! In honor of EWeek, I’m going to focus today’s blog on my favorite project that I’ve worked on as a computer scientist: my own Sim City.
I’ve talked briefly about this before in an earlier blog, but I want to go a little bit more in depth to show you the kinds of things that go on in a large scale programming project.
First, however, I’ll give you a little background. This project was actually my final project for my CSCI 201: Principles of Software Design class, and so each member of my team already had a little piece of the project done prior to starting the project. In this class, we learned a lot about how distributed code interacts with itself and how to properly design and manage this code so that it doesn’t hang and crash because of dependencies. To do this, we implemented an agent methodology, where each entity of code was self-contained on its own thread, meaning that many of these entities could run at the same time in parallel. To prevent hang-ups, these entities could only talk to each other in the same way that normal people do, by sending a message. Once a message is received, then the receiving entity would add that message to a list or queue of received messages and decide when to act on it, if the entity even decided to act on it, at a later time. Because of this, no entity could wait for a response from another entity, as there was no guarantee that a response would even come; instead, these entities would choose something else to do while they waited. While the idea sounds pretty simple, the implementation became increasingly complex as we each created our own restaurant with waiters, customers, cooks, hosts, cashiers, and markets all talking to each other at once and needing to prioritize and process the messages they were receiving.
Once we had all completed our individual restaurants, each with our own method of implementation, we were assigned into groups of 6 or 7 to combine these restaurants into a full city along with banks, houses, apartments, and markets. To populate the city, we had to create an overarching person that could act as any of the roles needed in the structures, like a resident, a customer, a host, a teller, etc. To accomplish this, we built off of the agent methodology to create people, which each ran on their own thread, and roles for every job, which behaved much like the threads with their own independent “brain” to process messages, but without a thread to actually run the roles. People, upon entering a structure, would take on a role and use that instead of their normal behavior, essentially allowing the role to run on that person’s thread instead of the person. This allowed us to keep all relevant data to the individual jobs inside of the roles and keep the people simple, since they only need to know what behavior is appropriate inside of their job or role while they are actually performing those actions. Another bonus to this method was that it allowed us to fire a person or have them leave work at any time, as long as a new person was there to take over the role. Since all data was stored in the role, when a new person takes on the role, all the required data to finish any tasks that the role may have in its list would already be there and the role could resume where it left off (meaning that customers wouldn’t have to wait indefinitely for their food because their waiter disappeared).
Sim City in Action!
The project was rather difficult, but, despite some late nights, it was very fun and rewarding. There are a lot of challenges involved with working on a large team for programming, especially with source control since we all are modifying the same files and no program is intelligent enough to avoid every conflict with our changes. However, the challenges of source control were very minor in comparison to how much fun it is to work in a group of intelligent computer scientists. Right from the very beginning of our design stage, it was incredible how we all fed off of each other’s ideas and built in less than a month a program that could have taken two weeks alone simply to design on our own.
