¶ M.W.A. - Möwen With Attitude
¶ Concept
¶ Summary
M.W.A. is a casual, chaotic, single-button multiplayer game, in which players control rowdy seaguls hungrily competing for expensive snacks of the nouveau-riche. The game can be played with up to eight people on a single device. Can you safely steal more food than your friends before the timer runs out? Go rowdy! Unleash your inner seagull!
¶ Mechanics
Seagulls horizontally traveserse the screen at a safe altitude, while humans holding snacks walk below them. By holding their personally assigned button, a players corresponding seagull swoops down, automatically appropriating delicate loot from humans or other seaguls in their path. Once the button is released, the seagul rises up again. Any food brought up to the safe altitude grants a point. But be carefull! If the swoop button is held onto for too long, the seagull will crash into the floor, dropping currently held food.
¶ Game Loop
- Player holds button
- Seagull Swoops
- Seagull either steals food or misses
- Player releases button
- Seagull rises and gets a point, if it brings food to the top
¶ Goal
Quickly steal as much food as possible. The first player to gain five points wins.
¶ Screenshots
¶ Play Now
¶ Developing Team
¶ Projectmanagement:
¶ Goal
Create a casual party game with virtually no barrier to entry that invokes (non-hostile) tension between players, to make them mew like seagulls.
¶ Tools:
- GitLab for scrum practices and shared repositories
- Miro for sharing conceptualization like moodboards or concept art
- Discord for communication, announcements and a central hub
- Google Calendar for scheduled team meetings
¶ Practices
Scrum
- 15 min stand-Up meetings twice per week at set time slots
- two week long sprints with set goals, working towards product increments
- sprint discussion and sprint retrospectives
- product owner and scrum master
- product backlog with dynamically prioritized issues and sprint backlog
- ownership of work -> everyone is responsible for their work
Kanban
- Kanban pipeline with Gitlab issue boards
- allows for instantaneous overview of progress on the project
¶ Instead of Moscow
Instead of Moscow, we used dynamic prioritization of issues with our Kanban board. As the scope crystalized dynamically, won't haves were added to blocked, could haves were given low priority, should haves medium priority and must haves high priority. This achieves essentially the same result, but more fine-grained.
¶ Course of Events
At first, our team strictly adhered to Scrum practices for both the large project and this one. Initial roles were discussed and agreed upon during the first two team meetings. Two sprints followed, resulting in a basic prototype. However, during those sprints, it became apparent that there was no unanimous understanding of the division of responsibilities, which destabilized ongoing practices. Furthermore, fundamental creative disagreements about the larger project, combined with the resulting drawn-out discussions, brought progress to a screeching halt. To alleviate this, sprints were abandoned in favor of valuable development time and the sprint backlog was replaced with a classic Kanban pipeline. But alas, the strain placed on the team was enough to cause a member to quit in silence, delivering the coup de grâce to team's morale. To give everyone the space they needed to process the event, work continued as usual, but participation became optional.
¶ Feedback
This is the feedback that we gathered on our playtest (04.06.2025)
Playtester #1
- liked the setting and theme of seagulls
- would liek to have powerups in the game
- wants to be able to swoop more than once before having to come up
Playertester #2
- had problems with the controls / swoop mechanic
- wishes there was a more clear way of seeing which seagull you are playing
- wants to see the button he has to use before the game starts
Playtester #3
- the boat is too static and should be moving
- misses a skybox with clouds
- not enough deisgn put into the UI
- we should show the title in the main menu
- NPCs should have more variations in their movementpath
- would like to have playericons for each seagull that displays the score and color
- more playerfeedback aka. juice like screaming and panicking NPCs
- more NPC variety in height and speed
- make the NPC spawntime more ranodm
- thinks the PVP is nice but hard to achieve
Playtester #4
- Thought the respawn mechanic was a bug
- thinks its confusing that you change sides while hitting the screenborder in a swoop
- Likes the controls and the feel of the swoop
Playtester #5
- wants to have more time before a round start in order to find their own seagull
- associates the color red with Player 1 and the color blue with Player 2 (we have it the other way around)
- thinks the multiplayer aspect and the colors remind of smash bros
Playtester #6
- Would like to annoy other players more
- thinks the time the swoop needs to get back up is too long
- would like to play with more than four people
- would like to have a tracking shot of the boat before a round starts
Playtester #7
- Would like to be able to change direction whenever he wants
¶ Results
Me made sure to consider every piece of feedback we got and sorted them by how achievable the tasks are and how much sense they would make.
Thats why we implemented the following:
- Display of the chosen swoop-button in the start menu
- Buoyancy and movement for the ship
- designed buttons and UI
- more variety in NPC behaviour
- more NPC-feedback and juice after stealing food
- other juices like a chance for the seagulls to poop
- adjusted the swoop-mechanic and feel
- added a tracking shot before a round starts
- up to eight players on PC
What we didn't implement, because it didn't match our vision:
- the ability to swoop more than once before coming back up
- being able to switch direction on the fly
- powerups
¶ Lessons Learned
Blaze
- kleinerer Scope von Anfang an planen
- wie ich 3D Assets schneller producen kann
- wie man ein Boot moddelt, habe vorher noch nie ein Boot gemoddelt
- klarere Aufgabenteilung definieren und früher über Goals reden
Sören
I learned...
- that trying to incorporate the interests and wishes of every team member into a single project will only dilute the results, and hence hurt any potential product.
- that a group needs to work towards a common interest in order to function properly. What is and what isn't encompassed by that interest needs to be clearly defined as a set of goals.
- that jargon can be poisonous to inderdisciplinary conversation, as the understandings of termini are unlikely to be mutual, especially in the game scene. When jargon is used, special care should be taken to assure that the intended meaning has been made clear.
- that project management means walking a fine line between control and trust. Trust in the competence of team members, but regularly check, that they don't get "lost in the sauce". I did not check in with progress frequently enough.
- that a functioning communication framework is the foundation of any group effort. Exhausting conversations are but a symptom of deeply rooted problems. If the root cause cannot be expunged without causing further scarring, more problems will arise.
Domenik
- even simple mechanics can be quite complex
- best practices for the observer pattern in C#
- You need clear communication between developers and artists to ensure that everyone works towards the same goal and so that assets don't have to be reworked
- Juice is very important but needs a lot of work and time
- there needs to be a clear production pipeline
- Writing shaders by hand is useful to shape clear artstyles, if used correctly
Felipe Versick
Pros:
- Writing small scoped game desgin concepts, that can be extended, proved (unsuprisingly) to be better then game design that needs to be scoped down
- Its never to late to learn a new decipline (3D Character Art), it is jsut important to estimate the time needed for the new skill
- Designing games, where setting and gameplay are molded into one part, makes for a good concept
- Taking the time to take the concept and apply multiple game design theories to it helps shaping a clear picture
- Writing your own shaders, and doing allot of research helps to create cohesive art styles
- Juice adds allot
Cons:
- Not having the same idea of productions steps and their needs
- Not having department leads proved to be hard at times
- Quickly changing responsibilities
- Dicussing too long for too little change
- In practice, the artstyle was not consistent
Lesson learned:
- clear lead role should be applied for more efficient discussions and secured responsibilities
- communicating expectations (productions steps, disscusions and so on) should happen more often
- PreProduction should resolve in a clear GDD and Art Bible to achieve better and more consistent designs