Editing Playtest - 1.5 hours
This week was pretty standalone from any other for me. While I usually do many other extraneous things, this week was focused simply on getting all of the playtests we needed since we had to have 44, and we didn't get much testing on the motionbase this term. A secondary objective I had was to get more footage for the video so I could edit it this week; while I did get the footage, the labs were full when I was available so I couldn't make the necessary edits.
Getting the playtest data was mostly done on the Wednesday group playtest where I spent 4 hours, and on the following monday where we reserved an hour to get even more. I recorded testimonials of some people before and after their ride experience if they didn't mind being on camera. I also had to edit the playtest for each of these sessions before they happened to make sure they were good (and in some cases, to streamline it).
That was all I really did this week.
Total Time Spent: 6.5 Hours
This is a personal post mortem, and as such I will be measuring my work I did against my team as a whole. I personally think I was a great asset to Alien Arcade; I was part of the original team a term ago and my placement as a sound/idea person carried through to this term as well. Of course I did other things such as modeling as well, but my main placement seems to have been unofficially in the sound & video department, and idea creation. This all being said, there was definitely good and bad that came with this project. I',m happy I got the chance to work on it, but given another opportunity, there are somethings I would change.
What went right?
1. Reporting to the team.
I always made sure I would report back to someone if anything I did was finished (along with a direct path to that thing), or if anything somehow was an issue. This really helped the team I felt because I was capable of doing more than I thought (if I told someone I didn't have much to do), and the team also knew exactly what I had been working on, and when it was finished. Some people didn't do this as well as me I feel, and certain games may have slipped slightly because of it--they were always fixed, but usually never arrived to class in the state they should have been in.
2. Democracy
It is a weird label, but honestly I have no other clue what to call it (maybe team synergy). Whenever I had an idea regarding a game, or an issue I had with an existing facet of one, or even a trailer decision, I ran it by the team. This made it so everyone was aware of whatever idea/issue I had, but it also made it fair as to what we should do with it. This essentially made everything a team decision, which I feel is really important for morale; everyone feels as if they have a say and in the end as if something important was credited to them. This occurred often when brainstorming new ideas (this method of thinking eventually led to Draw at Noon) or during what I call 'issue meets' where we go through every game and list what is wrong (this is how we agreed to handle certain bugs).
3. Documentation
Personally, I didn't do a lot regarding this, but I think the amount that I did certainly helped the team largely and made the necessary processes faster. When i gathered all of the sound effects for use in Alien Arcade, I made sure to document all relevant copyright information as well as a brief description as to what the ound actually is. This made it extremely easy for David to add this into the GDD later as well as the credits of Alien Arcade; and it also helped everyone else who was trying to put music into the game. Aside from this, my changelog submitted both to perforce and slack whenever I did something was very succinct and included exactly what went in and where each time, making finding those things easy.
What went wrong?
1. Timeliness
I am really bad personally when it comes to working in a timeframe, specifically because I work the best under pressure. That being said, I always got things in on time and never really failed to do a task that I was assigned to do for the week. I simply waited a long while or put the assignment on hold until the ladder end of the week to do other things in the meantime because that's how I've always worked. It wasn;t necessarily a detriment to the team, it just forced me to change over time--I went from working mostly Monday or Tuesday on the project to starting to work on Saturday for it. In some ways, this can be a positive thing; but it took 8 weeks to get there and I feel as if nothing but good would come from having me start and finish things earlier.
2. Not Getting Enough Playtests
Being in charge if playtests for Alien Arcade, this falls heavily into my hands I feel. However, a few others and myself always mentioned playtests to people and we never seemed to meet our quota like we did from last therm (which is probably due to the huge influx of team members). This means both on and off the motion base too; we managed to get many playtests our final week, but that was a desperation attempt because it was really required in order to fix bugs. If we had more testers in general, and specifically more on the motion base, I feel like a large number of bugs we discovered could be fixed, and the motion could certainly have been tweaked already. This was probably largely in part to there needing to be 3 people free, and 2 xbox controllers to even do a single playtest at all.
3. Time Estimation
This almost goes hand in hand with timeliness, but I'm setting it aside because this was a large reason why things were handed in later than expected as well. This term in particular, I ran into many computer issues (both on my personal computer and on lab computers) that caused my various tasks to slow to a slog. Whether it be the computer i was working on not having enough ram to handle a certain edit I made, or my computer deciding to randomly slow until I needed to do a system restore, or simply having something take longer than expected; time estimation always was an issue.
Lessons Learned:
- Reporting to the team allows everyone to know what's going on
- Team synergy is really important in a large group project for morale
- Documentation, no matter the form, will always help a process
- Working under pressure can be good, but in team projects it is not usually the best
- Playtests are extremely important to working out the flaws of a game
- It seems that estimating slightly more time than needed wouldn't hurt anything amidst all of the computer issues I ran into this term
No comments:
Post a Comment