Launching Nova Star: Release and Retrospective
It’s day 59 and the original prediction for the end of my challenge to become a fully employable Software Engineer through Game Development. I really can’t believe that we’re here already! It sounds impossible. At the beginning, I remember thinking that there is no way I could learn so much in such a short time, yet here we are.
Our game is published! We did it!
Nova Star on itch.io: https://gamedevhq.itch.io/nova-star
Please, please, please if you have the time and want to have some fun, go and play the game and leave the Nova Star team some feedback and comments! The potential plan going forward is to continue support on the project as interest dictates and to implement more features and bug fixes. All of this relies on the community and we sincerely appreciate any and all of you who takes the time to play our game and give us a response!
I also just want to highlight our hardworking team and leads who were all were a huge part of the success and completion of the project. Thank you for making this such a great and rewarding experience.
Nova Star Dev Team:
- Mar McRae: Mar McRae
- Dylan Murayama: Dylan Murayama
- Cristain Aspacio: Cristian Aspacio
- Christopher Na: Chrisgamedevhq
- Kurt Noe: Kurt Noe
- Ryan Yamura: (ME!)
Nova Star Team Leads:
- JP Hayashi: Apple Dragon
- Austin Mackrell: Austin Mackrell
- Al Heck
59 days ago I had never opened Unity. Never heard of C#. Never could have believed how far and how much I have learned in such a short amount of time. It’s not even been 2 months to this day, and we have created a fully release product through teamwork, cooperation, passion, innovation, and willpower.
The process wasn’t perfect, but often the idea of perfection is only achieved through the equal value of imperfection contributing to perfection.
And in retrospect that’s exactly what our process was. Perfect — because of our imperfections, challenges, and mistakes.
I believe that being able to reflect on the process as a whole and pinpoint where things went well and also where things went not so well is a valuable process in which fosters growth and forward movement. So please allow me to go over a little bit of the retrospective of Project Nova Star!
Positives:
- Teamwork
The group worked well together, the fact that we were all here under the same pretenses of a unicorn of an opportunity, to learn a skill and be paid, I think, really helped drive motivation and passion. But, it was not only that, the individuals in the projects team were all open minded and humble.
Ego did not get in the way, and were able to identify challenges and processes that worked in order to fully implement strategies that drove us forward.
- Communication, Collaboration, and Cooperation
Though similar to the above positive of teamwork, in practice these three things are quite integral and I felt like they should be listed as a separate positive. Without these three things, teamwork is not effective. Communication, collaboration, and cooperation may seem natural in a team setting, but I can tell you from personal experience in the past, these are often the largest obstacles for teamwork to succeed.
Being able to identify, and communicate challenges and even more important, things that go WELL, come first in order to streamline methods to collaborate and cooperate.
Often, the hardest part can be to compliment yourself and others, it can be easy to pick out what’s wrong, but difficult to identify and vocalize what goes right. Even more difficult then, to take that compliment and implement it’s success, especially among introverted personalities. And, let’s all face it, in the community of game development and software engineering there are A LOT of introverts — myself included. I still find it hard to this day to take compliments and often self deprecate. This behavior helps no one when you’re on a team and need to find methods that work for your specific group. Identifying situations that create a positive and efficient work flow are equally, if not more integral to saving time and preventing challenges.
- Peer Coding Sessions
During this project there were often times when things would just break. Whether it be due to assets not being included in our git repository, or merge conflicts simply creating files and prefabs that needed to be fixed. Code, assets, and scenes needed to be fixed, rebuilt and re-coded. The simple solution is sometimes is to sit together in a group (or call) and identify and fix the issues together. This makes it so everyone can see what issues arose in order to avoid or implement their own fixes to the problems. Our group excelled at this, sometimes a bit too well, in fact, which will be covered in the challenges portion of the retrospective.
However, our team was able to create not only peer coding sessions but towards the end of the project, we were able to break off into teams in order to solve multiple problems with multiple peer coding sessions happening parallel to each other, organized in such a way that the portions being re-evaluated and fixed would not conflict with other’s code or assets. This felt rewarding as it created situations where our productivity and efficiency doubled, sometimes even tripled.
- Presentation and Dedication
I touched on this a bit before I think, but I have to reiterate how dedicated this group was. We had barely a day or so to create and and present our game to the internship and company and was able to pull together and organize an professional and thorough power point presentation. I think our passion really showed during this, as we spoke about matters and the process as a whole, seamlessly and near-flawlessly in a 40+ minute slide show. I never felt so proud of the work we did and the people I was lucky enough to work with.
Challenges:
- Working with a new team, on a new project, with zero experience: Acclimation
Though expected, we faced some acclimation challenges as we encountered roadblocks and situations that required dependencies in order to move forward. We had all never built a game as a team before and didn’t really know what to expect. In a way, sometimes it’s a bit simpler when things are done by yourself because you know exactly what am implementation is, and can also switch gears to a different feature should you encounter a roadblock through it being dependent on another feature being completed first.
Moving forward we all agreed that taking a step back, especially at the beginning of the project and making the time to really plan and be critical would have saved us a lot of time. Now knowing all of the things we do about teamwork, collaboration, and dependencies we also got a great idea of all of our individual strengths and weaknesses, encouraging and fostering the growth of our skills and teaching each other methods that will help us as we continue or journey into this field.
- Merge Issues
This challenge was mentioned before, however it deserves its own section. I think I could probably write for days about how merge conflicts can completely derail and entire project day. A one hour session turns into 4–5 hours easily trying to completely resolve merge conflicts. Now — to put this in perspective on the ideal of perfection though imperfection, this was a good thing.
I don’t think I could have learned about how to resolve merge conflicts if we did not encounter the merge conflicts. They are a pain, that’s for sure, but now I am somewhat confident that I know what to do should a merge conflict show up — which it most definitely will. Being able to not only identify where the problem is, but how to open it up and fix it is invaluable, and is honestly something I’m glad, now, happened. Git was one of my biggest fears, as on my week I had some huge issues with, along with fellow interns who lost entire projects to Git. I can honestly say that now I have a somewhat good grasp of how to use Git, and that in itself makes me thankful for this challenge.
- Useful Constructs
This one is another situation where it basically was expected. Using constructs that are an industry standard for reasons was basically unknown for the most part for the team. Things like a singleton pattern design and abstract classes, we did end up using but because we didn’t really know too much about them when we started the project a lot of things had to be re-organized and reevaluated in order to account for these constructs and their implementation. Don’t get me wrong — all of these things helped immensely in cleaning things up, making things more simple and efficient, and just being plain USEFUL, however, should we have known about these things beforehand we could have planned better and saved more time. The great thing is that now we all know about them, and can utilize them moving forward, and hopefully are able to perfect the practice of putting them to use.
- Peer Coding Sessions
Here’s the challenge associated with peer coding sessions. They were often long and sometimes only involved a few of the people in the group. It’s no one’s fault that sometimes the sessions didn’t involve them directly and it really did help to have them there in case something they worked on came up in an issue, but these sometimes felt like a huge time sink.
However, as I wrote about in the positives section of this retrospective, we were able to identify and implement a form of peer coding that allowed us to maximize our team, and that was EVERYTHING. The growth and the cooperation to be able to effectively do this, I’m simply proud.
- Organization
I saved this one for last because it was our biggest challenge and a sleeper at that. You don’t realize how big a project can become until its overwhelming. The amount of scripts, prefabs, folders, assets, and files with similar names became too much. As mentioned before, taking the time before your project starts to organize a way in which would work best for your team to organize these files would save SO MUCH TIME. I think that I spent more time looking for specific scripts an files more than actually doing things with them some days. I don’ think we were able to solve this during our project, and moving scripts, prefabs, and the such seem to break things in Unity, so we just had to deal with the somewhat organized chaos.
Our team lead Apple Dragon was able to show us some organizational tools, including visualization drawing tools that may be able to help us in the future in our careers. And though she told us not to sink too much time into them, I believe that they may be very useful to me, personally, in the future.
Retrospective Takeaway:
The idea that our team was perfect because of the imperfections is that we were able to have these challenges, make these mistakes, and miss certain deadlines because of it — was perfect. We were put in this program — in this team in order to ready ourselves for the real world, in a real job. Perfection and things going just right isn’t realistic and being able to experience these challenges in a setting where we could explore how to solve them, how to tackle them, and consult people who are experienced in these scenarios is invaluable to our futures.
The biggest takeaway that we all agreed upon was that organization and planning can save you SO MUCH TIME. It IS an investment to sit down together and plan things out when you could just jump in and figure it out, however, how much time spent planning versus how much time you spend solving issues that come up due to lack of planning becomes very skewed once the ball starts rolling downhill. When it rains — it pours. And that’s exactly what happens when the challenges and problems compound.
The best part though? If you have a team that works well together, communicates and has great leadership, no matter the problem you WILL be able to overcome it and succeed.
This was such a valuable experience and something I don’t think I’ll ever forget both because of the challenges we faced, and victory we achieved. We were told how lucky we were to have such a good team who worked together so well, and was able to put ego, and whatever else aside in order to see the success of the project. And I have to wholeheartedly agree with this sentiment. Especially after looking back and reflecting on the project as a whole. Thank you, to ACI, GDHQ, Team Members, Team Leads, and you, the reader, for being there for my journey and creating a opportunity of a lifetime.
As this is day 59/59 of my challenge to become a Software Engineer, and our project is released into the wild and PUBLISHED, I just want to say thank you again for being here and staying with me through my journey. I can finally sign off and say…
— Ryan
Software Engineer
