Play S.A.M. (Software System Mechanism) now available on your Android mobile device
S.A.M. was launched May 11, 2016
A team of 10 made our Most Viable Products (MVP) list and went to work to produce our first game in six weeks!
Building S.A.M. was quite the learning experience and here are the top 3 things I
learned about working to developed a video game, dealing with a team and deadlines, and adapting to
every problem.
1. Play and Test your game ASAP
Everyone needs to be on the same page when designing a video game. Understanding how the game will look, feel, and play. Making a prototype of your game is essential; especially for my position as a programmer. My first time cramming knowledge of C# was from forums and YouTube videos. I was overwhelmed from the start, working in not classic art terms, but making art work by writing knowledge for it. This
was the absolutely best rewarding sensation I have ever felt throughout my time
learning at school. None the less it was a challenge that enthralled me to learn more and has shown that I can deliver for a deadline.
2. SCRUM and Teamwork
Making games is a business; making money to fuel our creative dreams. SCRUM is a visual way to understand what we need to do in order to make this game real. Organization and communication is key for game development and with SCRUM it is easy to see what each individual is doing.
However there will always be people who don't support their own weight. Should you fire these people? Give them second chances and risk wasting everyone else's time? There is a deadline that needs to be met and a director cannot be afraid to tell someone that they are screwing everyone else involved. The director for S.A.M. on the second half of production, was falling off the development process and someone needed to step in. I stepped up and reminded individuals that this game needed to be released, talk about assets we needed to agree on like music. Get everyone focus again and make sure S.A.M. launched on time and it did!
However there will always be people who don't support their own weight. Should you fire these people? Give them second chances and risk wasting everyone else's time? There is a deadline that needs to be met and a director cannot be afraid to tell someone that they are screwing everyone else involved. The director for S.A.M. on the second half of production, was falling off the development process and someone needed to step in. I stepped up and reminded individuals that this game needed to be released, talk about assets we needed to agree on like music. Get everyone focus again and make sure S.A.M. launched on time and it did!
3. Adapting to the Problems
Just because there is a problem and you can't understand it, doesn't mean anything. Every problem I encountered, I had little idea what the error was. You have to learn and make sure you don't repeat your mistakes, even if it costs production time. Asking my programmer buddy (Mike) first then straight to the internet; Unity forums, YouTube, Google etc. As time pressed on, errors that kept popping up became familiar and I could look back in the code quickly and identify any issues, like NullReferenceExceptions for example. This C# error at face value makes no sense to most. With researching and learning, over time this became a no brainier and I could easily fix the problem. Like <GetComponent> Collider instead of target.Collider. No problem, it might be too big to understand at first, but you have to sit down and research/learn it. Think and apply your ideas, fix your problems, document to remember and study later!
Just because there is a problem and you can't understand it, doesn't mean anything. Every problem I encountered, I had little idea what the error was. You have to learn and make sure you don't repeat your mistakes, even if it costs production time. Asking my programmer buddy (Mike) first then straight to the internet; Unity forums, YouTube, Google etc. As time pressed on, errors that kept popping up became familiar and I could look back in the code quickly and identify any issues, like NullReferenceExceptions for example. This C# error at face value makes no sense to most. With researching and learning, over time this became a no brainier and I could easily fix the problem. Like <GetComponent> Collider instead of target.Collider. No problem, it might be too big to understand at first, but you have to sit down and research/learn it. Think and apply your ideas, fix your problems, document to remember and study later!
1
