If game feedback surveys have good categories and gaming criteria, then it makes it easier for developers to know where there are problems, and where they can make improvements.

Problem Solving

When my team and I were working on our MTAG, we eventually came to the realization that our time system was garbage. Previously, my team had discussed the possibility of adding a calendar. Now seemed like a better time than ever to make that happen. Unfortunately, that was easier said than done. At first, I searched online to see if anyone had made anything that I could look at for reference, but I didn't find anything.

So I just sat down and thought about what is the best way to make a simple calendar that displays weekday, day, month, and year. It also has to update itself using only a number 1 - 365 so that it would be easy to increment the date, not break easily, and preferences can be made without using external assets. Long story- short, I did eventually figure something out. Unfortunately, I forgot how it works, so now my team treats it like some scary monster in the corner that we have no choice but to trust. We know it works, but no one knows how.

Teamwork

While I was working on my Mini Text Adventure Game (MTAG), I was part of the largest team in the class with a grand total of 6. Our game was called "Life The Game". Since it was our first time doing a collaboration for most of the team, we struggled to find something for everyone to do. In the end, our team settled with 2 programmers that focus on adding new features, one debugger that we call for help when the project spontaneously explodes, and 2 programmers that focus on adding content once the new features work, and one games tester that that takes notes for balancing the game.

I was one of the new feature programmers. Usually, after I would add a new feature I would go and explain it to the content programmers so they could add more content into the game. I would also add tons of comments in the code so that even if they forgot what I said they could figure it out anyways.

Since some of the other team members were less proficient at JavaScript, I would usually help them out so that they can still contribute to the project in a meaningful way. At the same time, the team was working on the MTAG, we were still receiving assignments from the teacher. Typically we would take turns doing the assignments, but if teamwork was allowed, then I would do it.

Creativity

For my Game Design and Programming class my team and I had one of the more unusual story concepts for our Mini Text Adventure Game. It was, "a person who's trying to do the things on his/her bucket list before the end of the world while in constant debt." It was a scenario I came up with, and it met all of the assignment criteria and while also remaining very open ended for more creative freedom.

At some point in the Life - The Games's development, we needed to add profile pictures into the game so the player wouldn't get confused. For some reason one of the team members decided to use a picture of sponge bob as the default player profile pic. All the other team members didn't question it and followed suite. So now everyone in the game is a sponge bob character.

We also added random events and random encounters into the game to make it more spicy. This ended up becoming one our games strong points as the player could go into massive debt or win the jackpot in a very short amount of time.

Time Management

While I was working on Super Gang Wars (SGW) I usually tried to plan some goals for the end of each week. As a result, I didn't slack off and the development of the game progressed at a steady rate. I wasn't organized enough to write the goals down but, I did keep them in mind.

Whenever there was a deadline, I would finish adding features 3 days before the deadline. That way I could spend those 3 days just polishing what is already there. As a result, apart from frame rate issues or difficulty, I did not release one build for feedback that was completely broken. So far I've gotten mostly positive feedback for Super Gang Wars.

Accountability

I've always disliked people who are all talk and no action, all bark and no bite, all shine and no substance, fake. As a result, I always try to make good on what I say. If I say I will do something, you're damn right it's going to happen, even if it's not right away.

In group projects, I always pull my own weight. Sometimes more. Usually, we start by splitting up the tasks. Typically, I take the tasks I know only I can do, or do better than my group members. Most of the time, I try to finish quickly to work on something else.

Communication

Generally, I always make and comment my code like it's for someone else. That's because it will be for someone else. There's no way I'm going to remember the purpose of a specific line of code 5 days later.

I've had my moments where I looked at my code and thought, "wait! why didn't I use that one function? It's way ways easier!" Then I'll be halfway through "fixing" it and then realize why I had it the way I did before. "Ah yes, that's right, I didn't use that one function because it doesn't work!" I'm a living example of the meme/phrase "you are your own worst enemy".

Also, it makes it easier to suddenly add another collaborator to a project. When adding a new collaborator, I would summarize what everything does, keeping it really brief. Then if they need more specific information then they can usually read the comments on each section of code.