Introduction:

 "Doomsday Long Road" is a post-apocalyptic endless, survival with resource management elements. The story involves the remaining survivor of a nuclear fallout shelter. He started by sheltering with his friends and family. Everyone got sick and died, he was losing hope and resources when he heard the voice promising a safe place full of life. 

We started by using Unity and due to the shrinking team size and lack of experience we decided to switch to C++ using Visual Studio and SDL2 libraries. For our source control on our coding, we used GitHub. We used Aseprite to make all of the sprites. We used several free sounds sites to get our game sounds. Regarding timeline, we always put this game/course on the back burner for another course or schoolwork. It became a daunting task to do after our team was cut in half and we were struggling individually. We had a hard time becoming comfortable enough, to be honest with our opinions to each other about what we were currently accomplishing. 

What went wrong:

Not many things went according to plan because we did not have a plan that we were updating and working towards, just this sort of idea of a finished game and we were just stumbling directionless because the task was too ambiguous. That’s why we had to bring in the scoop of the game and try to bring a main idea together. This involved meeting as a group and deciding what we needed to do to make this a game and what would be nice to have.  From the beginning, we struggled with our time management which led to us having constant crunches to meet deadlines and unnecessary stress. It took us a lot of time to understand that time management is a crucial part of game development. As we got closer to the final release, the need for a plan was apparent to all of us if we wanted to get this done. 

What went right:

Although we encountered many difficulties, they created many learning opportunities for us as individuals and as a team. We created a “virus” in one of our milestones and then successfully exterminated that bug in the next. We made some good decisions such as changing the engine, this worked better for us because we all had a base understanding of the framework. This helped a lot when it came to the development of the game. We didn’t run from our mistakes, but we embraced them to deliver better quality work with each milestone. At the end of it all, we are proud of what we were able to accomplish.

Timeline:

After we changed the engine, the due date of the "First Playable" was too close to be able to finish it on time as no code was done at that point. That was our first crunch time. Even though we all knew that we didn't have anything, we didn’t take time to plan. A couple of days before the due date, we started to pull everything together, we distributed the work between us, while some oversaw the visuals, some were doing the code, but due to poor communication, lack of confidence and focus, we couldn’t implement the first look of the main game loop. The "First Playable" was more like a really cool moving screen saver rather than a game. Also, the presentation didn’t go well because we weren’t confident in the project as a whole at the time.

The second crunch time came with "Alpha." We had another late start due to other assignments and a lack of confidence. We experienced poor communication as not everybody was on the same page. We had times of just blindly assuming our teammates were going to get their portion completed on time without doing any type of status check on how far they have gotten or what help they might need. Once again, a cool screen saver with some buttons this time.

“Beta” was the trilogy of the crunch. It was more expected since from the first playable and the alpha we learned that we needed to prepare for it ahead of time. We were more confident in the project now and we knew better about what the ending goal would look like, so it became easier to manage and distribute the work amongst the team members. Even though the work was distributed, and the goal was set, the communication problems were still holding us back as a team. As again nobody asked questions about what they were supposed to do, if some vague tasks were given, which led to incomplete work.  The game started to look like a game at last, the main game loop was implemented, and the buttons do what they were intended for, but either way, It was still a great screen saver. The presentation went wrong since we weren’t properly prepared for it, but as we took the initiative, we ended up getting great feedback from our publisher.

Anyway, the “final release.”  This was the real CRUNCH now. As the semester was ending all our courses had final assignments, so our project became the last priority again... We had a plan this time, to finish this project after finishing everything else, but we didn’t leave it till the last minute. We had to adjust for our other courses, so it wasn’t about what to do but about when to do it. With each successfully completed assignment, we felt more confident that we would finish this project successfully and on time. Our plan was to get rid of features that would take a long time to implement and focus on the things that were already there.

Expectations:

In the beginning, we believed in the people who originally thought of the idea, and we supported them so when our teammates started leaving our expectations began fading. Looking at it now, it turned out much better than we could have expected, because in the beginning, we weren’t sure how much we were going to get finished as a small team with a large idea. 

To Induce our positives, we have learned:  

-To be open-minded about making mistakes and taking the opportunity to reflect on them. 

-To take initiative at the start of a project to get the team rounded up and involved in planning and working towards a mutual goal.  

-To be understanding with each other and not to be judgmental. Life happens! 

To reduce our negatives, we have learned:

-To adapt to our new environment by taking a step back and reevaluating our situation to face new challenges. 

-To fail hard and fail fast! The faster you get your failures out of the way the faster you can move on to success. 

-A better understanding of the importance of communication and feedback among us, as it helps to identify issues earlier in development. 

-GitHub RULEZ! This has been the one and only vital tool that we learned during this project. Once you know how to use it, it helps a lot. 

-There was some time when we were stressed but the biggest lesson that we learned was that it's important to be serious but also have fun!  

- It's super important to set realistic goals from the beginning, start from a solid base, and improve from there, working from the bottom up. This prevents disappointment in having to remove “the cool mechanics” that you didn’t have time or knowledge to implement. 

Conclusion:

Looking back, we never thought that we would learn that much. We never expected to be as immersed as we were in the production hustle. We are really proud of the final product we were able to deliver despite all the challenges we faced. In fact, we are grateful for those challenges because they forged us into what we are now.