In this project, I created a couple agent-based simulations. The agents are little colorful circles that live in a window. They live their lives by randomly moving around, but when they are with more than 3 friends, they become much less likely to move around. Rather than being in a grid, their positions are in continuous 2D space. This projected was implemented using linked lists. Linked lists are a group of nodes that hold two fields: their data, and a "next" pointer. As the same suggest, the next pointer points to the next node in the list. It looks something like A->B->C->D, where A is the head node aka the first node. The simulation worked just as expected; agent's bounced around until they joined a gathering, then they calmed down, but then agents split off from the gathering, and eventually a new grouping would be formed elsewhere.
I created 6 classes in this project: Agent, SocialAgent, Landscape, SocialAgentSimulation, CategorizedSocialAgent, and CategorizedSocialAgentSimulation.
The agent housed an location of x,y coordinates. For the most part, the Agent class just served to exist as a superclass to SocialAgent.
SocialAgent extended the previously created Agent class from which it got its constructor and accessors. Methods unique to this class were draw() and updateState(). The draw() function created a small blue circle of 2.5 radius. The updateState() method first checked the number of Agents in a radius of 15 from the SocialAgent's x,y. If there were more than 3 neighbors, then the agent had a 1% chance of moving. If the agent had less than 3 neighbors, then it would move every time step.
This is where the LinkedList of agents were held. The important method in this class was getNeighbors(). I looped through each agent in the list, then using the distance formula, I checked if the agents were within the radius of the coordinates passed into the method. I also checked to see if the distance was 0, this way, an agent wouldn't be considered its own neighbor. If these two conditions were true, the agent would be added to the list of neighbors. The draw() and updateAgents() functions just looped through the agents/shuffled agents lists and called the draw() and updateState() methods, respectively.
This class creates a (by default) 500x500 landscape with 200 agents. It then runs the simulation with the given number of time steps.
This class extends SocialAgent. The difference is that these social agents each belong to a category. This changes the simulation, that agents will only clump with agents of the same category (using the same decision making as the basic SocialAgent). The different categories also cause the agents to be different colors.
This is identical to SocialAgentSimulation, except it uses 2 categories of CategorizedSocialAgents – red and blue.
Generally, 15 radius didn't have much clumping, especially after I set the getNeighbors to not count agents directly on the x,y as a neighbor. The simulation with the much larger radius wasn't very lively. Most agents would end up falling under the condition where movement occurs with a 1/100 chance.
- SocialAgentSimulation – radius 15
- SocialAgentSimulation – radius 55
- CategorizedSocialAgentSimulation – radius 15
- Another category
- I added a third, red category. This made clumping even less likely, since having having 3 different categories effectively decreased the likelihood that a neighboring cell was of the same category.
- "Instead of making separate main classes for each type of simulation, write just one Simulation class and make it possible for the user to control the type of SocialAgents from the command line."
- I created a new class called Simulation that lets the choice of simulation be decided from the command line.
- General Command-line arguments
- As suggested in the instructions, I added command-line arguments that let the user control the landscape size, number of agents, number of time steps, and which simulation to run (0 for no category, 1 for categorized). If the user doesn't input any arguments, then it will use default values. I put in a check to make sure that people don't try to put in too many arguments; if they do so, then the program will print a usage statement and quit.
- "See if you can mix and match different agent types and write about what happens."
- I changed the color of the SocialAgent (non-categorized agents) to black. Then I made some modifications to my CategorizedSocialAgent class using the instanceof keyword so that it would only do the category check if the agent in the list is a CategorizedSocialAgent. If not for this, it would try to check the category of regular SocialAgents, thereby throwing an error.
- I set this as choice #2 in the command line argument. This will create half categorized, half regular social agents. I found that life was sad for a regular social agent. Their social agent peers would clump with them, but when they tried to clump with CategorizedSocialAgents, the CSAs didn't want to hang out. In other words, SAs would pause when in a clump of CSAs, but CSAs wouldn't be affected by the presence of an SA.
- Changing radius:
- I tried radii 5, 10, 15, 25, 35, 45, 55, 85 in sequential order. As one would expect, these caused the agents to go from moving around all the time, to almost always being at a standstill.
- I found that the difference between 45, 55, and 85 weren't all that much. This was because at such a big radius, agents tended to have the minimum requisite neighbors and thus almost every agent was moving solely due to the 1% chance conditional.
- Changing neighbor requirement
- I experimented with changing the number of neighbors required to use the 1% chance to move conditional. I tried: 1,2,3,4,5,6.
- As the number of required neighbors increased, there was much more movement for agents. It seems likely, therefore, that with these test values, the most movement would be with a radius of 5 and neighbor requirement of 6 and the least movement would be with radius 85 and 6 neighbors required.
- Background Music
- Adapting my extension from last time, I decided that since these Agents are looking for friends, this program plays the Friends theme song when running the Simulation class. If this annoys you while testing, please comment out line 26 in Simulation.java.
I learned a lot about the underlying data structure of this project: linked lists. This project also gave me more experience with inheritance and OOP.
A list of people you worked with, including TAs, and instructors. Include in that list anyone whose code you may have seen, such as those of friends who have taken the course in a previous semester.
I worked alone. I used the Java documentation.