Surviving Paradise is a prototype horde shooter made over the course of my second year in the Honours Bachelor of Game Design Program at Sheridan college. This was the first year-long project I had worked on.
This was made for the course design practice over two semesters, the goal of the project what to get some experience working in a longer development pipeline with a team. We were tasked with creating a vertical slice of a game from scratch, and go through the entire development process from pre-production to a playable build.
For this project I mostly worked on documentation as a project management role, feature implementation, and level design.
______________________________________
- Project Information -
Playable in itch.io with link down below or executable.
Production & Project. Game Design. Level Design
Group of 6 Design Practice Project.
Approximate 7 Month development time.
2023.
Short gameplay demo of the project as it was in 2022.
Note: The video has no sound, your audio is probably working.
______________________________________________
- Initial Concept -
We started off creating multiple prototypes of different games and then deciding on which one we wanted to move forward with. We ended up deciding on creating a top-down horde shooter, with it being a blend of Call of Duty Zombies, Into the Gungeon and Nuclear Throne in terms of how we wanted our gameplay to flow.
Overall, the documentation I worked on was putting together clear milestone descriptions, a schedule, and backlog. I also created a detailed layout of our level, put together a simulation tool of our progression system in Excel, and edited our team’s video presentations for our course.
The first piece of documentation I created was a simple paper concept of what our gameplay features might look like for the player in terms of visual feedback. This was just to get an idea of what the team wanted to create and act as a starting off point for our concept.
Initial concept of some features and feedback for the player.
Next, we decided to map out our basic gameplay loop and what we would want the player to experience. Shown in the image below, the gameplay loop is very similar to Call of Duty zombies from the start and our goal.
Shortly after this, we created a 2D prototype to allow our programmers to get some basic physics required working. This was our pre-production demo. Shown below is a short video from that version.
Just afterwards was the point where we decided to switch to 3D, but still top down. We had decided to do a 3D project to allow everyone on our team to work at their full potential, as a member of our team was an excellent 3D modeller.
- Implementation in engine -
For implementation and level design, I created the testing, and main level layouts that I made in pre-production in the engine. I also acted on feedback from our playtests, using that to iterate on relevant features.
Layout of our simple dev testing level.
Layout with metrics and important locations of our main level space.
In game greybox shortly after a first round of feature implementation.
In an implementation pass, I did some tweaking to our enemy spawn door and added effects in the engine, as well as adding some basic colour textures into the scene’s props.
Early version of the effects for our spawn enemy spawn door.
I performed a lot of tweaking for the player controller and enemy spawns. We had an issue where the camera was not on the same update cycle as the player and this was causing a jitter. This was a major roadblock that was only solved closer to the end of the project, just due to how strange the issue was. It ended up being an issue with our player controller code overriding the fixed frame update cycle and cause desynchronization between the camera and player object.
Another issue was our aiming cursor for the player would get on top of objects and cause inaccuracies. This was solved by simply locking its height value
These issues are both displayed below.
- Lesson learned, cut content, and development issues -
Our second semester of that year was very, very busy. This caused a lot of issues for development, and right near the end we had to cut a major parts of our game. We couldn't anticipate the course load we would have for the winter semester, so we ended up very behind our original vision. We had majorly over-scoped and due to the circumstances of our other courses requiring a lot of time to put towards their projects.
We had to cut a lot because of all of this. Many of our art assets like character models and final props never ended up even being put in because they never made it to the stage of being finalized and implemented. Even our level had some unfinished areas where props were randomly dotted throughout some rooms as a placeholder. We were also never able to implement any sound and that was a weakness of our team was experience with sound, so the game is eerily quiet.
We ended up cutting two major features that we had documentation for and had designed, but were simply not given the opportunity or time to put towards implementing and developing further.
The first feature was our element system. We wanted to have emergent gameplay in the form of level interaction and the use of various elements to create different effects.
Diagram of our element system and its different abilities and combinations.
The player would be able to use the elements above, and dealing damage with weapons of different elements, this would charge a bar where they can be combined, and the player can perform a special one time ability. Promoting players to fight enemies, and progress.
The second piece of cut content, was our progression system. This was what the team felt would make our game really stand out and allow it to feel great. Disappointingly, it had to be cut due to time, as mentioned previously.
The top of our progression system model in Excel.
The team and I had designed the system, and I created an Excel document to simulate it. The simulation was made to allow us to balance the system before implementation, as well as make it easier to code with the major math and calculations already done. So if it didn't match in practice to the spreadsheet, we knew something wasn't right, and would be able to solve the issue quicker.
The simulation went to 100 waves and would calculate the amount of currency the player would have after a specific round, as well as the time it might take to play to a specific round.
It was very unfortunate that we had to cut these features, and despite the development issues, working on this project was the highlight of every week for me. I would continue working on the project with a team if given the opportunity. A major resource we weren't using was premade assets and the unity asset store, it's definitely an oversight now, but we wanted to challenge ourselves and create everything ourselves, in a time when that just wasn't possible.
Overall, I learned a lot from this project, and since then, about how to better create documentation, use available resources and implementing ideas in stages. This project is absolutely something I keep in mind as a lesson learned and has allowed me to spot issues in more recent projects and assignments much earlier.