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.
Monday, October 29, 2007
Presentation Critiques (Week 8 Presentations)
Antlion
Their original idea seemed difficult to finish by the end of the term. They said they were narrowing their scope, and I think that was a good idea. Instead of doing a real-time strategy, they decided to step back to a turn-based strategy. This would greatly simplify the amount of scenarios they would have to take into consideration with respect to game play, game design, and programming.
They had a good choice in test subjects. Although there were a variety of different people, they made sure that every one would be able to properly critique the prototype and give constructive feedback.
One part of the presentation I disliked was that although they went into good detail about the testing of the prototype and the materials the prototype was composed of, they did not actually explain what the prototype WAS. Having not explained what it was, they were unable to show that their prototype actually tested the mechanics of the digital game they were planning to make.
After testing, they took their feedback into consideration and looked into whether the player should be able to choose to play an ant or an antlion. I think used their feedback well in this case.
Overall, it was a fairly strong presentation.
13/15.
They did not explain the mechanics very well in the presentation, and I got a bit lost. They also failed to specify what genre the game is.
Although I didn’t understand a big portion of the presentation, they did seem to delve deeply into the feedback they got from their testers. They took several suggestions into consideration with respect to scope and mechanics (even though I don’t know what the main mechanic of the digital game will be). Perhaps they were using the prototype to define the mechanic itself. Either way, they made good use of their test.
Had I some background knowledge about what their game, I think the presentation would have been fairly good. They just needed a better introduction.
12/15.
Mizu
They were very thorough, going in depth about several things including their influences and sources. Their story seems very well thought out and makes it look like narration will be one of the main aspects of their game. They also had nice concept art.
They explained their mechanic very well, and I was pleased to hear it as the first two presentations failed to do this. They very clearly stated the limitations of paper prototyping their game, and the difficulties of translating their digital mechanic into a paper form. I think their work-around was a fairly decent idea.
15/15.
Untitled
They need to think of a title (or at least a temporary project title).
They said that they would be simplifying their stages in order to decrease scope. It’s always good when a team recognizes that they’re aiming too high.
Their paper prototype tried to combine too many mechanics. They should have isolated one or two to test on paper.
It’s an action game, but had many puzzles. They really had to choose one and develop it. Through feedback, they realized this error.
As their testers went through the prototype, the team kept changing things as they went along in accordance to the feedback. Although this is a good way to provide a good experience, it makes it difficult to get consistent feedback. Multiple opinions are necessary on the same subject.
They greatly re-developed their game based on the feedback they got. I’d say the paper prototype did more for this team than any of the previous three. They used it well, and received good critiques.
14/15.
Week 9 Assessment
Week 9 Accomplishments:
Well, after making some flight code, there were some aspects I just couldn’t get right. I suggested that we purchase a Flying Starter Kit, and we did so last Tuesday. I’ve been modifying it, but am still struggling a bit. Collision detections works, and I’m halfway through developing the bombs.
For the bomb trailing, I had originally just intended to make objects that just use semi-simple math to follow the player. After going through this code though, I’m not entirely sure how to make objects do that. Instead, I’ll be making the bombs as AI spawns that follow you around. It will have the exact same effect, but is just different on the back end.
Meetings:
Last Tuesday, pretty much all day. We discussed progress, bought the Flying Starter Pack, and further developed some details pertaining to the game.
Week 10 Goals:
Monday, October 22, 2007
Weekly Assessment
What I did this week:
- Analyzed Torque 3D starter code
- Did researched in Garage Game Forums and various online tutorials for code that would be useful to our project
- Developed flight code
- Found a necessary method for importing maya models into Torque 3D
Where and When we met:
Surrey Campus/Tuesday Oct. 16: Discussed various aspects to the game and story, refined stage design.
What I will do for next week:
- Develop bomb pick-up code
- Develop bomb trailing code
- Develop ruins recognition and collision detection
- Develop detonation
- Analyzed Torque 3D starter code
- Did researched in Garage Game Forums and various online tutorials for code that would be useful to our project
- Developed flight code
- Found a necessary method for importing maya models into Torque 3D
Where and When we met:
Surrey Campus/Tuesday Oct. 16: Discussed various aspects to the game and story, refined stage design.
What I will do for next week:
- Develop bomb pick-up code
- Develop bomb trailing code
- Develop ruins recognition and collision detection
- Develop detonation
Subscribe to:
Comments (Atom)