Cerise Oasis

Cerise Oasis aims to capture the essence of a classic zombie game mode with a new theme. The game occurs in a post-apocalyptic cyberpunk setting, where computer-automated personal servitors – or C.A.P.S. – have risen against humanity and aim to destroy their creators alongside the Barct, the extraterrestrial race that invaded and turned the C.A.P.S. against the human race. Cerise Oasis is multiplayer, and players are encouraged to create lobbies with their friends and survive the apocalypse together. They can choose one of 4 characters, each with a unique ability. Players will look to survive across three separate maps, displaying the range of destruction that has occurred during the uprising. They will be able to collect scrap from their takedowns to purchase more powerful weapons and ammo. As the game progresses, more powerful enemies will spawn, requiring players to work together to survive the onslaught of each wave. At the end of each game, players will face a boss, and upon its defeat, they will survive the map and win the game.

Controls:

• W A S D for movement
• Mouse movement to aim
• Left click to shoot, right click to aim down sights (if applicable)
• R for reload
• G for grenade
• Shift to sprint
• F to interact
• Q for Primary Class Ability
• Tab for Stats Pop-out
• 1-2 or Mouse Wheel to Change Weapons

Cheats:

Money: P

Music: N

Fast Forward: T (enemies will not be spawned regularly, and may permanently speed up the game speed)

Post Mortem:

The making of Cerise Oasis was an enjoyable experience. Discussing concepts regarding the flow of the game, the types of enemies to be created, and the implementation of multiplayer support were excellent conversations that brought the team together and helped all members gain a greater understanding of what the final product would look like. Integration went as smoothly as it could have with the overhead of networking parts of the game that needed to be networked and weren’t beforehand, but we ended up with a serviceable product that was fun to play with friends.

The main two issues that the group faced were an unequal distribution of work between the team members and the challenge of teaching ourselves how to implement multiplayer functionality. To start off, some members of the team had more work to do than others. This problem spawned as a result of how we divided up the work from game jam three which continued into the final project since we hoped to iterate on the concepts explored previously. With one person working on character-related development, one working on level design, one working on UI, one designing AI enemies, and one working on multiplayer functionality, it was clear that some workloads were more general than others and would require more effort while others had less-than adequate contributions with the scale of the project we had taken on. These distributions in turn don’t leave much room for discussion between members on how systems will interact with one another, which meant a lot of time was spent during integration refactoring scripts so they could work with each other and over the network. To mitigate these issues, the team would constantly update each other on what they had completed, and members who had lighter workloads did more work on deliverables related to the games development. In retrospect, more work could have been taken on by members who had lighter programming workloads to allow the game to receive greater attention and quicker implementation. Secondly, there were large issues with implementing multiplayer functionality, specifically dealing with the time it took to research correct implementation strategies and testing that the development product was working as intended. It took 50 collective man hours over a single weekend to implement a working multiplayer game experience with a correctly implemented ping system, and another week to develop the lobby system we wanted in place to allow players to join each other’s games. In the end, this endeavor was probably out of scope, and it would possibly have been a higher quality game without multiplayer functionality implemented. Regardless of this fact, I’m proud of the effort the team put into making this project possible, and I believe we put together something great.

In regards to scope, the main changes that were made were to scale back some of the functionality we believed we would be able to develop in order to deliver a more polished, smaller but still fun final project. The direction of the game in general was also changed. Cerise Oasis is an iteration on a game jam that leaned more heavily on rogue-lite elements than a COD zombies aesthetic. The direction of the game shifted due to ambiguity in the design to what the game is now, which we found to be a more interesting and fun game to create anyway.

The team learned a great deal about their respective fields of development, and gained a greater respect and understanding of the work that goes into creating a multiplayer game. We in turn learned how to create a multiplayer experience with a lobby system, which is critical knowledge in today’s gaming scene, where many of the most popular games use similar systems to the ones we coded for Cerise Oasis. The group also has a better idea of how to properly scope a project so that development and integration can be completed in a timely manner.

Post Mortem Addendum: Due to source control issues, The team had a difficult time testing and iterating on networking solutions. For now, The game only works for the host player.

Credits:

Rowan Holder - Game Design, Multiplayer Development

Tucker Wood - UI, Multiplayer Networking and Development

Brady Dunning - Character and Weapon Design, Shop Design

Aden Halili - Level Design

Connor Donihi - AI Development

Music: Karl Casey @ White Bat Audio