MOSHPIT SIMULATOR
I noticed the crowd + moshers at a concert behave like fluids. So I simulated it.
The goal was to explore the “emergent properties” of a concert crowd based on few rules that apply to everyone individually.
The 2D demo below is the first version.
(with sound~)
![]()
INDEX:
- Discovery: how fluid mechanics cross-pollinated with metal concerts.
- Design: How might we parametrize the internal and external factors that influence behavior.
- Development: Coding, troubleshooting and evolving the design through making.
- Level Up: Remaking the simulator on Unity (game engine), enabling audio-visualization, materials, etc.
DISCOVERY
In the Fall of 2016, I took a class on Fluid mechanics. Any busy street will reveal parallels between the movement of crowds and fluids (eg in a pipe, fluid moves fastest in the center and slowest near the edges). I found this fascinating and carried this metaphorical lens to crowds at concerts. In Spring 2017, I attended many concerts in venues of varying capacities in NY and observed crowds and moshpits. I noticed that each person’s individual level of engagement with the music (temperature) contributes to whether they are standing still (solid), moving their head/body (liquid) or moshing (gas).
In Jan 2018, I worked on the 2D moshpit simualtor as a final project for the class “Explorable Stories” (NYUSH). In Fall of 2018, I re-made it on Unity.
In Jan 2018, I worked on the 2D moshpit simualtor as a final project for the class “Explorable Stories” (NYUSH). In Fall of 2018, I re-made it on Unity.
DESIGN
^Earliest sketches of this
The moshpit is an intriguing phenomenon because it forms spontaneously. Usually when the shared energy of a crowd crosses a threshold - just like liquids crossing a boiling point. The movement of moshers (gas particles) creates pressure that forms and sustains an open space to accomodate other moshers. A moshpit is like a bubble. A bubble that attracts anyone who is energetic enough to “evaporate” into the bubble, and repel anyone who is caught in the middle but isn’t interested to the edges. People naturally will move somewhere less chaotic to avoid risk.
The code can therefore count the number of people above “boiling point”. If more than 3 - 5 people (I’ve seen moshes start with as little as 2 rowdy people) are found, initiate a bubble center for the mosh circle to form. The circle’s diameter is usually proportional to how many people are in it as well as how energetic/chaotic they are.
The complexity begins (or in other words, the lmetaphor breaks down) when considering how each person’s energy is generated. This is a subjective experience and can benefit from user testing, but I used my own + observations to move forward. Those variables are a result of the harmony between the musical qualities (like the pace, or the tension/resolution in transitions) and the personal characteristic of each individual (eg a person’s stamina, familiarity with the music, or drunkness).
People’s likelihood of moshing varies with:
- how physically they express enjoyment of music,
- their fitness, level of risk tolerance/aversion,
- how intoxicated they are,
- the influence of those in close proximity to you,
- how familiar they are with the music, etc.
The rest of the design actually got refined iteratively during the development phase.
Ideas, problems and solutions came up in the making process.
DEVELOPMENT
Code wise, I used arrays to remember the characteristics of each person (eg familiarity[], drunkness[], “mosh in progress” or MIP[] which holds either 0 or 1 and gets updated frequently). The movement is done by account for x and y positions, velocity and accelerations of every person, essentially creating a physics simulator.
The custom functions apply forces to each individuals: for example “moshMagic” attracts moshers towards the mosh and pushes non-moshers out (applies force after comparing whether the distance between them and mosh center exceeds the mosh radius). Another function is “stageMagic” which attracts the crowd towards the stage. An important one is “personalSpace” which creates a boundary around each person. This boundary also shrinks the more huddled together people are: making those closer to the stage more densely packed than those behind. This is made to reflect the behavior of crowds in real life too: people are willing to sacrifice personal space to be at the very front!
Examples of problems + resolution:
Problem 1A: Sideways force moves people to the edge of the screen.
(what I assumed was a) Solution to 1A: flip the angles:
Problem 1B: They’re now lining up in the center
Solution: randomize the angle, so that people get nudged in either direction - the resulting effect would even out people’s vertical position.
Problem 1 is fixed.
but people at the very front are too close together.
Problem 2:
personal space too unrealistic at the very front.
Solution: decrease “scan radius” of the function that shrinks personal space as more people are around. The reason this function exists is to reflect how people are more willing to be lenient with personal space when the trade-off is getting closer to the stage and getting a better view. Notice how there is a gradient in personal space as people move further forward.
The fix was changing the areascanradius (see code) to 2.2 instead of 2.5 (the unit is the size of each person) as well as reduce the effect of the total number of surrounding people on the final personal space (from 1/8 or 12% reduction to 1/10 or 10% reduction).
The custom functions apply forces to each individuals: for example “moshMagic” attracts moshers towards the mosh and pushes non-moshers out (applies force after comparing whether the distance between them and mosh center exceeds the mosh radius). Another function is “stageMagic” which attracts the crowd towards the stage. An important one is “personalSpace” which creates a boundary around each person. This boundary also shrinks the more huddled together people are: making those closer to the stage more densely packed than those behind. This is made to reflect the behavior of crowds in real life too: people are willing to sacrifice personal space to be at the very front!
Examples of problems + resolution:
Problem 1A: Sideways force moves people to the edge of the screen.
(what I assumed was a) Solution to 1A: flip the angles:
Problem 1B: They’re now lining up in the center
Solution: randomize the angle, so that people get nudged in either direction - the resulting effect would even out people’s vertical position.
Problem 1 is fixed.
but people at the very front are too close together.
Problem 2:
personal space too unrealistic at the very front.Solution: decrease “scan radius” of the function that shrinks personal space as more people are around. The reason this function exists is to reflect how people are more willing to be lenient with personal space when the trade-off is getting closer to the stage and getting a better view. Notice how there is a gradient in personal space as people move further forward.
The fix was changing the areascanradius (see code) to 2.2 instead of 2.5 (the unit is the size of each person) as well as reduce the effect of the total number of surrounding people on the final personal space (from 1/8 or 12% reduction to 1/10 or 10% reduction).
LEVEL UP
The 3D demo (in Unity) presents the crowd/moshpit simulation as a feature in a game setup in a “space age” in which you are a band from earth touring the galaxy. I also used audio scripts to link the music to particle systems, lighting and movement.