Meetings:
Monday Meeting - Did playtests and received feedback.
Weekly Tuesday Meeting - Did various tweaks and balances to the prototype.
Week 12 Accomplishments:
- Coded fixes and tweaks to prototype, including:
- Screen shaking during collision
- Vary intensity of shaking depending on speed and angle of collision
- Shield around ruins during collision
- Make shield image
- Rotate depending on direction of collision, so impacted area is a different colour
- Recode ruins collision a bit so there will be no second rebound when the shield appears
- Tested different algorithms for bomb movement
Week 14 Goals:
- Make "thrusters" (engine trail)
- Give the bomb spawners a cooldown bar so the user can tell the status of restocking
- Make the ship automatically dock with the garage when approaching it
- Add a damage meter
- Add a system of adding damage
- Recode the bombs in order to allow for delayed detonation
- Make bombs float outwards to form a proper perfect circle when connected
Monday, November 26, 2007
Tuesday, November 20, 2007
Presentation Critiques (Week 11 Presentations)
Stick Ninja
Well, I'll start by saying that the team seemed to do a good work on the prototype, as well as the documentation of it. It's a pity that they were unable to show the video they made. They explained the existence of a character, enemies, and the weapons, but some other minor aspects of the game remain a little foggy.
They explained their prototype in great detail, and it emulated their gameplay mechanics well. They also always had the instructions available to the testers so they always had a reference - some things were a little complicated to remember offhand upon introduction.
The mechanic seemed to work and the testers had fun. As the tests went on, the team recognized things that could potentially make their game more fun. They also made some good changes from their feedback.
Zodiac War
This team had a really... presentable presentation. As a fighting game, they chose testers that were all fighting game gamers - this was a good choice on their part (choosing only those from their target audience), as this will probably yield the most usable feedback.
Unfortunately, for the majority of the presentation, I could not hear the speaker. He spoke very softly. All I could really tell was that they managed to get some good feedback, such as changing the pace of the game, creating more variation in attacks, improving controls, and ramping of AI. It was a productive session for them, and I think they did well for a paper prototype of a fighting game.
Crack Quest
Alright, this one made me laugh - definitely not for kids.
They made a pretty funky digital prototype. They had taken an existing game and edited it - it was rather humourous when the sprites would revert to the original game's. They developed the game well, all they needed was more art - more states for their sprites.
They received a lot of feedback on many different parts of the game, such as the need for additional weapons/enemies, cutscenes, and skippable dialogue. They were also given a potential new mechanic - dodging bullets. Originally, they could shoot down enemy bullets, but if this doesn't happen, they have a new mechanic that they can try out. I think it would improve the game as well, making it more challenging and skillful as opposed to a spam-fest.
Well, I'll start by saying that the team seemed to do a good work on the prototype, as well as the documentation of it. It's a pity that they were unable to show the video they made. They explained the existence of a character, enemies, and the weapons, but some other minor aspects of the game remain a little foggy.
They explained their prototype in great detail, and it emulated their gameplay mechanics well. They also always had the instructions available to the testers so they always had a reference - some things were a little complicated to remember offhand upon introduction.
The mechanic seemed to work and the testers had fun. As the tests went on, the team recognized things that could potentially make their game more fun. They also made some good changes from their feedback.
Zodiac War
This team had a really... presentable presentation. As a fighting game, they chose testers that were all fighting game gamers - this was a good choice on their part (choosing only those from their target audience), as this will probably yield the most usable feedback.
Unfortunately, for the majority of the presentation, I could not hear the speaker. He spoke very softly. All I could really tell was that they managed to get some good feedback, such as changing the pace of the game, creating more variation in attacks, improving controls, and ramping of AI. It was a productive session for them, and I think they did well for a paper prototype of a fighting game.
Crack Quest
Alright, this one made me laugh - definitely not for kids.
They made a pretty funky digital prototype. They had taken an existing game and edited it - it was rather humourous when the sprites would revert to the original game's. They developed the game well, all they needed was more art - more states for their sprites.
They received a lot of feedback on many different parts of the game, such as the need for additional weapons/enemies, cutscenes, and skippable dialogue. They were also given a potential new mechanic - dodging bullets. Originally, they could shoot down enemy bullets, but if this doesn't happen, they have a new mechanic that they can try out. I think it would improve the game as well, making it more challenging and skillful as opposed to a spam-fest.
Monday, November 19, 2007
Week 12 Assessment
Meetings:
Weekly Tuesday Meeting - Discussed the switch to a temporary 2D prototype. The 3D version of the game will be continued after the 2D one is done (most likely after this semester is over).
Sunday Meeting - Cody and I went through the first version of the prototype in order to do some balancing and additional features
Monday Meeting - We did playtesting with five users.
Week 11 Accomplishments:
- Started and developed a working 2D prototype in Flash including:
- Flight controls
- Bomb trailing
- Detonation and destruction of bombs and ruins
- Collision detection with bombs, bomb spawners, and ruins
- Rebound system using the ruins' tangent at the point of collision
- Intro/Outro animation per stage
- Core Menu
- Stage select
- Money system
- Garage with purchasable upgrades
- Pause
- Dialogue Box
- Various other features
Week 13 Goals:
- Refine bomb behaviour
- Add sounds
- Refine end of stage docking
- Instructions (in the form of in-game dialogue)
- Implement other features based on user feedback
Weekly Tuesday Meeting - Discussed the switch to a temporary 2D prototype. The 3D version of the game will be continued after the 2D one is done (most likely after this semester is over).
Sunday Meeting - Cody and I went through the first version of the prototype in order to do some balancing and additional features
Monday Meeting - We did playtesting with five users.
Week 11 Accomplishments:
- Started and developed a working 2D prototype in Flash including:
- Flight controls
- Bomb trailing
- Detonation and destruction of bombs and ruins
- Collision detection with bombs, bomb spawners, and ruins
- Rebound system using the ruins' tangent at the point of collision
- Intro/Outro animation per stage
- Core Menu
- Stage select
- Money system
- Garage with purchasable upgrades
- Pause
- Dialogue Box
- Various other features
Week 13 Goals:
- Refine bomb behaviour
- Add sounds
- Refine end of stage docking
- Instructions (in the form of in-game dialogue)
- Implement other features based on user feedback
Monday, November 5, 2007
Presentatioin Critiques (Week 9 Presentations)
3rd Cloud
This team had a great introduction, including good background info for their game, as well as their thought process. They took their time to make a digital prototype, and thus could prototype without hindering their game development - a good idea. With this, they could test their mechanics first-hand without having to transfer them to a paper prototype.
They chose testers with a good age range, yet still managed to choose people who could critique their prototype well. Prior to testing, they surveyed their users and gave them a synopsis. This is the first team so far that's tested their users in this aspect.
They received good feedback, and the biggest change they're planning to make is to allow the user to interact with everything. This will require a lot more programming, and I hope they have enough time to do it. They're also planning to make a user manual. I'm less enthused about this though, as most people will not read the manual, and they might end up relying on the manual to explain core aspects of the game.
On another note, they've developed their graphics well and it looks like the final game will be amazing.
Food Fight
They explained their prototype well in the presentation, but for their testers, they only provided instructions without any verbal instruction. Their game had a steep learning curve, and this resulted in their testers being quite confused. This was a bad decision on their part.
Most of the feedback they got was comments that the game was imbalanced. Just looking at the setup of the possible food items to be thrown though, this is pretty plain to see. I don't believe they took the original balancing into consideration enough.
Also, their battleship concept kind of blurs the metaphor of a food fight too much.
Drive Thru Tycoon
This group explained their core mechanic and goal, as well as the setup of their prototype, but they did not explain what their prototype WAS. All I know is that it was a real-time prototype. What the prototype entailed though, was not clear.
The presentation itself was not very good. Their slides were overly cluttered with text, and they read off their slides. Their speaker was also very soft. It's too bad he didn't go in Week 8 when the microphone was set up.
I don't believe they used their feedback well. All they mentioned that they got out of it was that they'd make a manual. I don't think this is the right course of action though, since they had a mini-manual in their prototype, and it didn't seem to help the testers. What they need is an in-game tutorial.
This team had a great introduction, including good background info for their game, as well as their thought process. They took their time to make a digital prototype, and thus could prototype without hindering their game development - a good idea. With this, they could test their mechanics first-hand without having to transfer them to a paper prototype.
They chose testers with a good age range, yet still managed to choose people who could critique their prototype well. Prior to testing, they surveyed their users and gave them a synopsis. This is the first team so far that's tested their users in this aspect.
They received good feedback, and the biggest change they're planning to make is to allow the user to interact with everything. This will require a lot more programming, and I hope they have enough time to do it. They're also planning to make a user manual. I'm less enthused about this though, as most people will not read the manual, and they might end up relying on the manual to explain core aspects of the game.
On another note, they've developed their graphics well and it looks like the final game will be amazing.
Food Fight
They explained their prototype well in the presentation, but for their testers, they only provided instructions without any verbal instruction. Their game had a steep learning curve, and this resulted in their testers being quite confused. This was a bad decision on their part.
Most of the feedback they got was comments that the game was imbalanced. Just looking at the setup of the possible food items to be thrown though, this is pretty plain to see. I don't believe they took the original balancing into consideration enough.
Also, their battleship concept kind of blurs the metaphor of a food fight too much.
Drive Thru Tycoon
This group explained their core mechanic and goal, as well as the setup of their prototype, but they did not explain what their prototype WAS. All I know is that it was a real-time prototype. What the prototype entailed though, was not clear.
The presentation itself was not very good. Their slides were overly cluttered with text, and they read off their slides. Their speaker was also very soft. It's too bad he didn't go in Week 8 when the microphone was set up.
I don't believe they used their feedback well. All they mentioned that they got out of it was that they'd make a manual. I don't think this is the right course of action though, since they had a mini-manual in their prototype, and it didn't seem to help the testers. What they need is an in-game tutorial.
Subscribe to:
Comments (Atom)