Co-op Super Mario Bros.
This project is a recreation of level 1-1 from the original Super Mario Bros. for the NES, but with the inclusion of two player co-op.
Allowing the player to choose between Mario, Luigi, Peach, or Toad, every character is equipped with a different moveset that makes each one feel unique.
The game was created as a group of five for the CSE 3902 course at Ohio State University, where the main goal of the class was to recreate a classic game from scratch.
My role in this project was the lead gameplay designer with a majority focus on the movement of Mario.
Overall I am not content with this project due to several issues with development, but I find it to be a good reflection of the progress I have made as a developer over the years.
Release Date: 5/1/22
Lead Gameplay Designer
Development
During my Spring 2022 semester at Ohio State University, one of my required classes was CSE 3902, a course that focused on the design, development, and documentation of projects. Using Monogame and C#, we were tasked with creating a game purely from scratch, with the only things we were able to use being art assets.
Teams were selected at random, with each team consisting of five members. Every other team besides mine decided that they wanted to recreate Zelda, as it would be simple and would not require any sort of physics. I brought up the idea of doing Mario, as it was not being done by anyone else and would have been more unique. This was not my first time working with a 2D platformer with physics and I was already experienced with C#, so I was not intimidated by the idea.
As a group, we split up the tasks between the five of us. I took control over Mario and his gameplay since I already had experience, while the others were tasked with blocks/items, enemies, map generation, and the flagpole/game over sequence.
Very quickly everything began to fall apart. Within a couple weeks I was able to finish the movement for Mario and one of my teammates was able to finish up the map generation, but we were left without working blocks, items, enemies, or a game over sequence. Unfortunately three of my teammates were not able to finish their tasks within the given time slot, so the two of us that had completed our task reached out to help the others.
This slowly transitioned into the both of us being the only ones that contributed any sort of work to the project as a whole, despite communication with the others and the instructor of the class. This trend continued until around the last month of the course, where we decided that we could no longer afford to take over for the work of others and informed the others that we would help guide them but we would not complete all their work for them.
In the end, I ended up taking over the work for the items, enemies, and main menu UI, while the other teammate took over the work for blocks and the in-game UI. Despite our efforts, the others did not contribute in the end and the final product does not have a working flagpole or endgame sequence.
For a while, this project ruined my perception of working with others on a project I was passionate about. To put in all the effort I could only to end up with a final result that was not up to my expectations was disappointing and for a while I refused to look back at the project. Thankfully, I have since revitalized my passion of working with others, with the first group project I have released since then winning a game jam and with more group plans to come in the future.
I have since revisited the project just to look over my old code. I have no intention of reusing any of it or fixing up any bugs, but the idea of revisiting Monogame has intrigued me and may be something I consider in the future.