Alerian Defense is a chaotic multiplayer party game, where Players take on the role of Crew aboard the Concordia, a ship transporting Crew, resources and terraforming equipment to the planets among the Alerian Star System. Upon their final approach to the star system, several systems aboard the Concordia fail, and the Crew must work together to restore core functionality to the ship before it makes contact with the planets below. Players are assigned random roles aboard the ship, each of which relate to specific systems aboard the ship. However, the onboard AI has also malfunctioned, and has assigned incorrect repairs to each role. Players must communicate effectively in order to determine which repairs are correct, and which are not as information may need to be passed between Players in order to correctly restore functionality to the Concordia.
Alerian Defense is designed to be played either in-person, or online via platforms such as Discord, with the game being hosted on a shared device (such as a TV, or streamed via screen share) while Players interact using their own devices.
As the sole developer on this project, I was responsible for all aspects of the game's development cycle.
Alerian Defense was to be designed and developed over an approximately 7-week period, which the initial pitch was created around. The full original pitch for Alerian Defense can be viewed at Project Aleria Pitch, with the key outputs / details of the project listed below:
Developing Alerian Defense was a challenging but rewarding experience, it being the first solo project I had produced since the first year of my degree and utilised technologies such as multiplayer which I had only worked with in limited capacities prior. Part of the challenge of developing this project was scope, the introduction of multiplayer tehchnologies, and the need for both project management and design skills, which I was more limited in experience with. I was able to further my project management skills, creating a plan for the game from start to end based on a 2-week sprint cycle. This planning included the use of a backlog (through HacknPlan) to track tasks, and a gantt chart to visualise the project timeline and key milestones. Previsouly my capacity for project management was minimal, I had acted primarily as the Lead Programmer on team projects, with overall project management being handled by other team members, where I would find project requirements and set expected times / story points around those requirements. This has allowed me to better understand the full project management cycle, and has improved my ability to plan and manage future projects.
The 2-week sprints for Alerian Defense were focussed on quick iteration based on feedback from peers and mentors. Acting as a sole developer, I feel this approach has strengthed my ability to work within sprint cycles, not having a team to rely on to make sprints feel more "full" or successful if I had fallen behind in tasks. I was able to perform feature cuts and additions more effectively, and I could accurately adjust task backlogs around these week-to-week requirement / feature changes.
Among the challenges of this project, I found working with Unity's Lobby and Relay services to be initially challenging but ultimately effective for the multiplayer connection system. I initially misunderstood how the Relay Service functioned, not realising it utilised elements of the IP-based connection system I had used previously in the BMW Project. This inital misunderstanding led me to further research both the Netcode and Lobby packages, as well as packages such as Matchmaking, which has led to a much stronger understanding of Unity's full networking solutions in Unity 6.
Over the course of development, some requirements of the project changed. Initally, the game was planned to release on
Android devices via Google Play, with release to iOS via the App Store as a stretch goal. Due to the playtesting
requirements of Google Play, and paid requirements for developers on Apple platforms, I instead opted to focus on APK builds for Android, and added
WebGL builds as a project output. This change allows for a wider audience to access
the game including PC users and iOS users as itch.io generally supports mobile devices accessing WebGL builds.
Additionally, comments over development from peers and mentors highlighted that the task interaction were initially very boring, only requiring Players to press a button to complete them.
To address this, I added the minigame system, which added more engaging interactions for the Players, and added slightly more variety to the gameplay loop. Future iterations of the game could expand on the system,
potentially adding role-specific minigames and improving the current minigame designs.
Overall, I think Alerian Defense has been a successful project, allowing me to develop my skills across a wide range of areas, including Multiplayer implementation, project management and design. While there are areas for improvement, I am proud of what has been achieved within the time constraints, especially as a solo developer who has previously focused primarily on programming roles within teams, allowing other elements of the game creation process to fall onto others.
If I was to continue development on Alerian Defense, I would focus on the implementation of a tutorial experience to onboard Players to the game's mechanics. Currently, the game lacks any formal tutorial, with a game overview being provided via the itch.io page, which provides minimal context for the game's interactions. This lack of tutorial has shown to be a barrier to entry, with task interactions being confusing for Players. This tutorial experience would be presented to Players upon launch of the game, and could be accessed at any point via the settings menu. The tutorial would cover the basic game flow, including lobby joining, task completions and minigame interactions, along side the addition of iconography to most of the task interactions to reduce the initial mental load on Players and provide better visual cues for task interactions.
As mentioned previously, I would also expand upon the minigame system, adding more variety (and polish) to the current minigames, while adding role-specific minigames to further differentiate the roles Players may take on. The minigames would also be treated to the same iconography improvements as the task interactions, to provide better visual cues for Players and again reduce the initial mental load. This would likely also help with the communication of information between Players, as the information for minigames currently can be lost among the text-based information presented to Players.
Main Menu Screen
Server Wait Screen
Player Lobby Wait Screen
Player Lobby Join Screen
Code Minigame Screen
Drag Minigame Screen
Slider Minigame Screen