Ok, folks, please comment on this posting. Every team should post here a list of all the things that could go wrong with their development project. Be exhaustive and make sure that you discuss these as a group.
Every problem has a solution - now is the time to figure it out. Please also pose a solution for every problem you list.
Subscribe to:
Post Comments (Atom)
33 comments:
Team Jigy's risk analysis
Problem
1) We may not meet planned deadlines due to midterms.
Solution
We can schedule around midterms.
Problem
2) Gordon is the only one who can proficiently program in actionscript.
Solution
Gordon can give everybody else a crash course in actionscript.
Problem
3) We may have schedule conflicts for sufficient team meetings.
Solution
We can sit down and figure out everyone's schedule while planning our deadlines. Also, we can schedule online meetings instead of P2P.
Problem
4) There may be game coherency issues.
Solution
We can use storyboards and prototypes to lay out the game in detail before implementating the codes and visual features.
Problem
5) There may be inconsistencies in images because there are several artists in the team.
Solution
We can agree on a template style.
Team vapple's thingsThatCanGoWrong
problem: Our main programmer(Daniel) has not programmed in actionscript before.
solution: Actionscript is a not too hard to pick up and David has experience in it.
problem: Conflicting ideas on game concept may stall our process.
solution: Have more meetings initially to flush out and develop our concept.
problem: Time management and meeting deadlines are issues because of other priorities such as other classes/work.
solution: Better communication will allow us to work on different parts of the project and then put it all together.
problem: Artwork might not be compatible with code(sizing issues, transparency, etc.)
solution: Programmer can place some guidelines for the graphic artist at the beginning.
problem: Users might not have the most updated version of Flash Player.
solution: Have a notice saying which version is needed.
Team SQUARED risk analysis
Issue: Someone going somewhere without telling anyone
Solution: Email group mailing list if anything happens to notify them in advance
Issue: Everyone is separated one in North Van, Burnaby and 2 in different parts of Coquitlam
Solution: Meet in local starbucks somewhere mid way, web conference and keep in touch via email.
Issue: Everyone is working so tons of time conflictions.
Solution: Got everyone’s basic schedule and have used it to map out the future meetings etc
Issue: Computer fails and our work is lost
Solution: Use our website and email and backup all changes as much as u can. Possible svn server.
Issue: Family related issues…
Solution: Requires that we notify the TA about our man/woman down and redistribute the work and make sure no last minute things.
Issue: Blog/svn server is down or email goes down
Solution: We upload to the blog and email people out work on any significant changes
Issue: Trouble between teammates
Solution: Try to get them together and discuses the issue together and find a compromise then tell the TA if that fails
Issue: One of our key member(s) are down (ie. the only person who can do programming is ill)
Solution: Try to give everyone exposures to certain aspects of each others work, and make sure there are very open lines of communication, so someone else can pick up the slack. If this is not possible refer this issue to the TA.
Issue: Other pressing issues in life (ie huge midterm)
Solution: Tell people in advance and make sure the work that needs to be done is still done but the person who has the issue can still get their stuff done aswell.
Issue: Bad time management
Solution: Follow the gantt chart created and follow the to do lists the producer has on the blog.
Issue: Distractions (ie games(wow))
Solution: Change the users password and make him quit for a bit =p. JK. Try to open a line of communication to the person and hope they come around and quit themselves, if that fails tell the TA.
Issue: Teammate is sick or injured
Solution: Keep the lines of communication open and make sure to tell the producer and other group members of the issue.
Issue: Natural disaster
Solution: Call superman for help?? JK Plan ahead enough so unforeseeable problems can be avoided and will not hamper the construction of the game.
Issue: Slow equipments
Solution: Try to use school computers and make sure we know who has what issues with their computers
Issue: Compatibility with pc and mac
Solution: Get a mac… JK… make sure everything is in programs that can be both run in windows and osx and all documents be in pdf. Test this before hand.
Averse: The Team's risk analysis
Risk: Deliverables are not finished on time, or on schedule.
Likelyhood: Medium
Impact: Serious
Preventative Measures: To avoid a problem, we will start early and set deadlines. Additionally by keeping strong team communication we can anticipate and react to possible issues.
If it happens: We must immediately rally the team, and quickly assess and rectify the issue at hand.
Risk: Being “off brief” or moving away from goals
Likelyhood: Low
Impact: Serious
Preventative Measures: Keep in contact with TA and instructor on plans for the game. Keep a centralized and up to date project plan, so all members are aware of the end goals.
If it happens: Must have a team meeting at once, also must contact the TA and/or Instructor to ensure that we are fully aware of the issues at hand, and that we are able to move in the correct direction.
Risk: Internal Strife
Likelyhood: Low
Impact: Catastrophic
Preventative Measures: Ensure time for team meetings, and time for team activities to strengthen team bonds. Additionally implement systems of majority consent, while still considering and compromising to the wishes of the individual.
If it happens: Depending on the severity the situation should be dealt with first within the team, in the hopes of defusing any further issues. If it escalates it should be brought forward to a TA or Instructor to help curb any further issues, and hopefully help salvage team relations.
Risk: Over stepping realistic goals
Likelyhood: Medium
Impact: Serious
Preventative Measures: Constant sanity checks. Make sure that the key goals are being implemented before moving to any extraneous activities. Peer review of goals, and a coding/arting buddy can be helpful to keep others on track.
If it happens: Be willing to let things go. Having weekly meetings and assessing the damage of over reaching, and the path to putting the project back on track.
Risk: Technical limitations affect game usage
Likelyhood: Medium
Impact: Tolerable
Preventative Measures: Extensive research into Actionscript usage, and its methods. Additionally, assess possible in game actions during design phase, and decide what is plausible and possible when using Flash.
If it happens: Take a step back from the project and assess the end goal of the process attempted. Find ways to replace or redo the action so it can still fit the game. Also assess it on a level of need, and its affect on the fun and enjoyability of the game.
Risk: Artistic style detriment to speed
Likelyhood: Medium
Impact: Serious
Preventative Measures: Artists must decide on a set artistic style early on and must take the pros and cons of vector drawing vs bitmap drawing into consideration.
If it happens: Depending on how far into the project, likely course of action is to revise artistic goals, take a step back, and make decisions that will put the project before the style.
Risk: Power outage and other preventing factors
Likelyhood: Low (we hope)
Impact: Catastrophic
Preventative Measures: Bring a laptop or other means of displaying the project if going to presentations. Also keep all members informed of project status, and keep backups of data.
If it happens: If anyone has loss of power, or has other serious problems, they must immediately report it via phone to a team member. Additionally and if possible, the team should meet to assess the depth of their members works, and who can possibly take over their responsibilities.
Risk: Team member not fulfilling duties (absent not finishing project goals)
Likelyhood: Low
Impact: Serious
Preventative Measures: Team members are required to show the work they have done between meetings, and are encouraged to discuss issues and problems they may have experienced while working.
If it happens: Team meeting to talk with the member not contributing. Hopefully it is something that can be sorted out between team members, and delegation of the task to other members (if it needs to be implemented asap). If situation escalates, report the person to a TA and/or Instructor and hopefully it can be sorted out at the level.
Risk: Game cannot be used on school computers
Likelyhood: Low
Impact: Catastrophic
Preventative Measures: Consistent testing at all phases of development on a “stock” machine at school to check for lag and/or glitching.
If it happens: Since checking is mandatory and regular, it is likely the latest errors occurred within the latest editions. Check the latest code changes and see if errors can be found. If the problem is inherent in the system (from additions), see if there is a way it can be re factored to be optimized.
Risk: Disparity between workloads of teammates
Likelyhood: Medium to High
Impact: Tolerable
Preventative Measures: Meetings can be used to check on team member's work loads and stress levels. If one member seems to be doing more than others, make sure that the team member is willing to delegate some tasks to others.
If it happens: Talk with team and see if there are any better ways to split up tasks and create a more even workload for all.
Risk: Team unable to meet in person during week
Likelyhood: High
Impact: Tolerable-Serious
Preventative Measures: Post team schedules to a common schedule mechanism. Keep teammates involved of extracurricular activities and other events that may affect meeting times. Decide on set meeting times for the team for each week.
If it happens: Set up a meeting time online, or through voice chat to keep fellow teammates informed. Try to have meetings between like minded individuals (artists with artists, programmers with programmers) in addition to full meetings. Also try to have as many members meet as possible if one cannot.
Risk: Game is no longer fun
Likelyhood: Medium
Impact: Catastrophic
Preventative Measures: Playtesting, both within the team, and with chosen third parties. Constantly assessing our feelings and the feelings of others about our game, and tweaking as seen fit.
If it happens: Take a step back and decide what it is that is interfering with the game mechanic and the end goals of the game. Take a survey of the interested party's thoughts on the matter.
Risk: Bugs/Glitches make game unplayable
Likelyhood: Medium
Impact: Serious
Preventative Measures: Whenever new features are implemented they should be tested under ALL possible working circumstances. Additionally, have participants note any troubles encountered during playtesting.
If it happens: Assign the bug to the team member with knowledge of the area at error. Set priorities of errors and their affects on the game at large.
Risk: Team mate does not have access to technological resources needed.
Likelyhood: Medium
Impact: Serious
Preventative Measures: Take inventory of all technologies required to realize the goals of the game. This includes software and hardware.
If it happens: Try to decide how large of an effect this may have on that team mates productivity. Try to assign tasks knowing the limits placed on the member. Additionally try and help member gain access to the resources they need (such as server space etc.)
Risk: Focus shifts, or drastic change in goal
Likelyhood: Low
Impact: Catastrophic
Preventative Measures: Planning should consider smallest elements (mechanics) and should be built from the ground up. This ensures that even if higher level objects are changed, their lower pieces should remain (relatively) unchanged.
If it happens: Make a plan of attack. Massive changes should only be done if absolutely needed, and if they are planned out thoroughly and completely.
Risk: Game becomes too complex or convoluted
Likelyhood: Medium
Impact: Serious
Preventative Measures: Stick to principles and basic game mechanic. Utilize the K.I.S.S. strategy.
If it happens: Remove any parts of the game that or unneeded, or only serve to complicate and diffuse the gamer/game interaction.
Risk: Team meetings resolve few issues, become time wasters
Likelyhood: High
Impact: Serious
Preventative Measures: Set up meetings with a goal set, suggest that certain tasks be completed before leaving. Additionally give the meetings some structure and allow for time overruns.
If it happens: Team mates should have the responsibility to pull their members back on topic, and make note of those who do not wish to. If it becomes a serious issue, insist on strict guidelines for meetings and their outcomes.
#1
Problem
Our lead programming Ip is not proficient in Actionscript
Solution
Royce gets promoted from hobo (float) to hobo-co-programmer. And will translate Ip’s ideas and algorithms into Actionscript
#2
Problem
Our lead artist Tony can’t sketch on paper
Solution
Our producer June will take care of concept art, Tony will translate to digital.
#3
Problem
Producer June is too busy to keep team up-to-date
Solution
Royce gets promoted again and becomes hobo-co-programmer-co-producer to assist June.
#4
Problem
Team members all have busy schedules
Solution
Use and abuse emails and IMs to communicate.
#5
Problem
Game scope may be our of hand
Solution
Make the game modular in planning so we can cut out unnecessary areas easily.
#6
Problem
The detection algorithm or drawings may become too complicated, if all of the details are to be included. Time and performance may suffer from this.
Solution
Use a simpler but less efficient algorithm that may not be perfect but still fun. Use more cartoony graphics.
#7
Problem
Game ideas might become too detailed an complicated
Solution
Focus on the game core first, and then add on the extras later
#8
Problem
When team members work at home it will be hard to combine files, or keep track of the latest update.
Solution
A task schedule will be used to order the completion of certain tasks to avoid conflict if possible. If not possible, each member will keep a record of what they have done to their file to reduce the difficulty of combining.
#9
Problem
File version conflicts.
Solution
Each member will try to ‘obtain’ and use the same programs as the school.
Problem #1
1)program could run too slow (too many objects/etc - limits of computer)
Solution
Use less 3D and place it with 2D images
Problem #2
what if the bitmap images of characters do not fit in with the 3D environment of game
Solution
Use Maya to make the 2D images look like they belong in a 3D environment
Problem #3
3)Team member(s) may be absent due to unforeseen circumstances or s/he/they do not finish their assigned parts on time
Solution
All team memebers must check their emails and stay in contact
D103 Group #5
The Red Hot Vegetarian JaKeRa
Problem 1.)
Our team members all live in different city: Surrey, Vancouver, Burnaby. It is very
hard come up with a meeting place.
Solution:
We can arrange a Starbucks in the middle of all our locations so it's easier for each
one of us to go to the meeting. Alternative method can be meeting online via MSN, or we
can try to resolve any problems thru telephone.
Problem 2.)
The midterm period will affect our meetings and our progress in game making.
Solution:
Plan ahead, and keep in touch with everyone. Make sure that we all know each other's midterm dates, and we can rearrange for a better time for meeting. Also setting
realistic goals when there are midterms in that week.
Problem 3.)
None of our team members have sufficient programming skills for game developing.
Solution:
Ask the Prof and TA for help. Get help from other classmates who has programming skills.
Problem 4.)
Hard to come up with a good time for meetings. Each team member have different available dates and times.
Solution:
Use online communication programs, such as MSN, or Skype. We can all meet up at the comfort of our own home. We all need to aggree on the days and times to meet and plan other tasks around those times.
Problem 5.)
We have different ideas regarding our game.
Solution:
We can look at each other's idea, and pick out the best and interesting part, then combine it all together if possible. If not possible, vote for the best idea and stick with it.
Problem 6.)
Unpredictable diasters which impede our game making progress. Things such as HD failures, getting sick, having fights with girlfriend/boyfriend, experiencing depression, etc..
Solution:
Prey to God. Make sure everyone in the team are on the same page in terms of our progress and deadlines. Keep in touch with everyone and notify any possible conflicts with the game making progress. Re-assign the task to someone who can handle it.
Problem 7.)
Getting stucked at a point of the game developing stage.
Solution:
No worries, ask our Godly TA and Prof for suggestions. Get advise from the Pros and discuss the problem and extract the answer from them. If they are unavailable, get help from other smart IAT students.
Problem 8.)
Disagreement among team members regarding about the game.
Solution:
Stay calm, and ask other people around us for more input. The team leader should direct the team in the right direction and show leadership to slove such problems.
Team CL^2 's
Risk Analysis
[D101]
Ulrike Lam
Terry Chow
Yvonne Lei
Jason Chen
1.)
Problem: Living in different areas (Burnaby, Coquitlam, Richmond)
Solution: meeting after school or meeting online (MSN)
2.)
Problem: Time conflicts (school&work)
Solution: meeting after school or meeting online (MSN); we have our meeting manager, Terry, to arrange each of the teammate’s schedule; try to take 30 minutes for a short meeting (face to face)
3.)
Problem: Personal Issues & Special Family Occasions
Solution: Other teammates will pick up the teammate’s work; split up the work from the member who have issue with; notify instructor and TA immediately;
4.)
Problem: Medical health Issues
Solution: Other teammates will pick up the teammate’s work; split up the work from the member who have issue with; notify instructor and TA immediately;
5.)
Problem: Computer/Technical Problems
Solution: save every 30 minutes; contact the other teammates immediately; post in our team blog; send to other members when partly work is done; upload to the ftp
6.)
Problem: Only one programmer in the team
Solution: programmer will only be focusing on the program part of the game, and the other teammates will be doing other stuff
7.)
Problem: Artists only know how to do 2D graphic
Solution: then do what we know, 2D; avoid using NEW program
8.)
Problem: Argument among the teammates (different point of view)
Solution: feel free to suggest anything; team voting; making sure everyone is happy when the final decision
Team ROTBF
Problem 1: Programming
Our programmer, Tim, wants to try C++, but has little experience in it.
Solution:
If Tim is having difficulties with C++, we can change it to Python where all of us have a basic knowledge of that program.
Problem 2: Expectations
Our goal is set too high, not enough time to finish.
Solution:
Star with a small working game, and then only add on if time allows. Also, plan ahead and try to get it done early and before your other homework.
Problem 3: Scheduling
It takes a lot of time to meet in person and it is hard to find a perfect time where we are all free.
Solution:
Meet online, like we have been doing so far.
Problem 4: Sound problems
We want great SFX for our game, but it could make our program run slower.
Solution: Worry about it at the end, after the game is running. Then try out different sound settings on our files to make them smaller without losing too much of the quality. Hopefully this will prevent lag.
Team Neon kat
known challenges and risks:
hairballs and litter
1) Karl's availability
we have great ideas. but this project comes down to how much Karl can do. He is our foundation (you can't have a working game without the programming structure)
solution:
we're kissing it(keeping it simple =P). our game may be in c++ ...
2) c++ may have software which may produce bugs and system incompatibilities
solutiobn: "calling the terminator"
3) Alex's mad poly skills
Alex is used to creating models in high poly. with in our context we would like to go for a 2d/3d Mario look.
solution:
cranking down the high poly. googling techniques in regards to low poly models
4) texture
Charmaine has some knowledge of creating textures for maya... but not tooooo much.. just a few whiskers
solution:
Alex offered to give charmiane a tutorial
5) sound creation
meow meow meow... our lack of experience in sounds production
solution: using the library database of collected sound for sound effects for our game. & ilife's garage band has an abundant amount of source files.
6) team availability
solution:
google calender & online meeting(with constant reminders)
7) time management.
solution:
learning how to set milestones
8) the kitten
the lack of "job" specialty.
solution: trying her best to be as useful as possible.
You can view TEAM KAPILO's Risk Analysis HERE
Team: Intellectual Anarchist Team
Problem: Unforeseen Coding problems
Solution: Break the problem into smaller parts, and tackle it bit by bit/ seek help from others in class
Problem: Losing work from system crashes
Solution: Pressing ctrl+s a lot.
Problem: Unforeseen problems with teammates “well-being”
Solution: To support them, and encourage them through struggles, everyone else doubling their efforts
Problem: The big earthquake actually happening
Solution: Laptops!
Problem: conflict with other courses i.e. midterm/project week
Solution: plan ahead so that person finishes his/her part earlier
Problem: Story writer having writers block
Solution: Everyone getting together and making creative ideas, inspiring each other
IAT312 // Lab C
Team1 // DYSfunctional Studios
Problem: We are unable to deliver project milestones upon deadlines.
Solution: Producer should help keep the Programmer and Artist on track and make sure everyone is on schedule.
Problem: Unidentifiable coding error cripples the game.
Solution: Go through the Actionscript, line by line and check everything over again. Get more than one person to go over the code.
Problem: Gameplay is laggy due to inefficient code.
Solution: Reduce, reuse, and recycle the code to streamline the information processes.
Problem: Our primary game mechanic loses direction.
Solution: Review the 14 Forms of Fun and rebuild those forms around the mechanic.
Problem: Poorly developed game mechanics result in our game not being “fun.”
Solution: Make sure the game is tested thoroughly throughout development and make necessary changes.
Problem: Programming and Art departments are not in sync and one side is left waiting for the other to catch up.
Solution: Make sure a constant flow of communication is established and ask for help when encountering a problem.
Problem: Control scheme are not appropriate and make the gameplay suffer.
Solution: Test the alpha with multiple control schemes and get outside feedback.
our team, tyjosake's, list of problems and solutions can be viewed here
http://docs.google.com/View?docid=dgc8fn53_91dggksf
I was gonna reformat it, but then figured it probly wasn't worth it as it'll be reformatted later for the design document or charter or something anwyays. why do the work twice.
so view it there, and this is also a plug for using googledocs/writely for collaborative writing projects such as this.
colors indicate who wrote what. black is what was written in class.
-jody
Possible error (team AFK)
Some of the possible problems that our team may encounter fall into 2 category. Bugs and Ability.
1) Over estimation of our ability. Ideas maybe larger than they appear: Plans we have maybe great, but once testing out, we may find that the skills or knowledge required to accomplish them maybe much greater than what we have.
Solution: Continue to develop our ideas, and match our ability to ideas, possibly even alter mechanics slightly if required.
2) Time management. Due dates of various portions of the project is in conflict with other classes assignments/ study.
Solution: Have one person take charge as “producer” making sure we are meeting the dead lines proposed.
3) Bugs in program, our project are relatively complex, and can easily involve bugs which are not so obvious.
Solution: Spend more time into game testing, trying out different variations in order to debug them.
4) Difficulty of game play may not be suitable. The game maybe made too easy or too hard, which takes away the fun in the gaming experience.
Solution: Test it and retest it our selves, or perhaps get friends to try out our alpha or bata, making sure the difficulty is in the right range, else tweak it until it is.
5) Miscommunication between team members: One member may have one idea in mind as for how the interface may look, while the others have a different visualization in mind as for what others are talking about.
Solution: When sharing, or discussing with team members about various ideas, try to present them as visually as possible, ie: how is the panel or view going to be? Is it in the first person perspective, or 3rd?
6) Disagreements over ideas within team.
Solution: 1) Talk through the pros and cons of each individual idea amongst ourselves. 2) Find a 3rd person’s opinion, or perhaps opinion from TA etc.
Team NPsy3
Problem: Everyone has a different time schedule. It is hard to have a face-to-face meeting.
Solution: We could have a MSN online meeting whenever all team members are available.
Problem: One of our team members lives in Coquitlam; whiles two of our team members live in Richmond. It is hard to find a place to meet outside of school.
Solution: The best place is to arrange meetings in the Surrey campus.
Problem: Conflicts and disagreement amongst team members.
Solution: Have a talk with the other member or talk the problem out as a team, send emails to express idea(s).
Problem: Inconsistency in the drawings.
Solution: one person can be assigned the task to do the drawings while others work on other parts of the project.
Problem: None of us is familiar in ActionScript.
Solution: work together as a team and begin learning it.
Problem: Unable to meet deadlines.
Solution: Arrange times to work on the project and have set milestones (plan ahead).
Problem: Team members are sick and unable to show up.
Solution: The member will have to email before the team meeting or phone team members to inform.
Problem: Team members do not fulfilling duties.
Solution: we could create a blog and each of us has to write what we have done each week.
Problem: Our game contains too many words and the players are lack of interesting in reading it.
Solution: “A picture is worth a thousand words”, so we should show them and not tell the players.
Team Ataraxia
Risks and Solutions:
Problem 1: No one in the team is particularly good at Flash (Actionscript), the medium for our project.
Solution 1: We can look for tutorials online, pre-made code, books and the built-in help tools in Flash.
Problem 2: Our schedules are clashing.
Solution 2: We can reserve team members’ time a few days in advance to make sure we get the project done. We have already decided to start meeting at school on the weekends as we have (slightly less) hectic schedules then. Online meetings can also be arranged when schedules are tight.
Problem 3: We might do bad-quality work because of problem 1 & 2.
Solution 3: We make sure to implement solutions 1 & 2 to the best of our abilities.
Problem 4: We may have taken on more programming than we bargained for.
Solution 4: We can come up with alternate ideas or simplify our game if necessary.
Team RGB's risk analysis
Problem 1
Each everyone in our team is a full time student with jobs, which makes it harder to meet offline/online.
Solution 1
Try to keep the communication active by sending emails to each other to keep everyone updated about every single issue.
Problem 2
Everyone lives far away from each other. One lives in Langley, one lives in Coquitlam, and one lives in Vancouver. It might get harder to meet up for the hands-on activities.
Solution 2
Try to meet at school as much as possible, in order to avoid inconvenience of anyone.
Problem 3
We have some people in our team that have no experience in C++ at all.
Solution 3
We should always keep in touch with TAs, and get as much help as possible from them.
Problem 4
We are still not quiet sure about the game mechanics. Since we have chosen to use randomly provided special powers, we might have to figure out how to insert the randomly provided special powers without having a single case of the game being too easy or too hard for a player.
Solution 4
We have been playing a lot of games in which random items are given, and trying to figure out how the random items make the games even more exciting without making a player feel too unmotivated or too challenged.
Problem 5
There has been many times where each of us wanted a different style of image for the same character.
Solution 5
We will try to standardize the look and feel of the game after a few negotiations.
Team Momentum - Group #6
Section D102
Team members:
Ching Chun Kao (Kevin)
Jack Yeh
Justin Lee
Alfred Au-yeung
Problem: Unable to meet due to work/school conflicts
Solution: We, as a team, will schedule meeting three to five days ahead of time, so that we know everyone will attend. This is to prevent any schedule conflicts that might occur.
Problem: Team members confused on what to exactly do for their tasks.
Solution: I (Kevin), will direct, and assign tasks out to my team members. I have provided my cell phone number, so anyone who is confused with their tasks is able to contact me directly. I will try to explain their tasks to the best of my ability.
Problem: No goals for original background music yet.
Solution: As a team, we will discuss on whether we should include background music or not. From my past experiences working with sound, it requires a lot of dedication and time to develop a single musical piece. I will need to ask my fellow team members if they worked with any sound editing tools before such as Adobe Audition, SoundForge, or Audacity.
Problem: Lack of programming skills.
Solution: We know that we lack of programmers in our team, so we already set up to research for tutorials that is somehow related to making our Flash game. All team members will send to the team leader a Word document containing the website tutorial URLs that they’ve found to be useful.
Problem: Time management.
Solution: We will definitely apply some milestones to this project. By setting small, specific goals, we will accomplish more in terms of quality and quantity. We will most set up milestones for each week from now on.
TEAM FAR FAR AWAY: a horrible glimpse into the future
1)Programmer hasn't used Flash before
Several other team members know basic flash, so can help the programmer learn. Also, flash is not too horrible to pick up.
2)Everyone has busy schedules and may find it hard to meet up because we live in different cities
Be aware of each others schedules to plan convenient meetings ahead of time. We also have an online Wiki to facilitate communication between the whole team so that everyone is aware of what has happened during face to face and msn meetings, as well as current thoughts and progress of the whole team.
3)Loss of data
Keep the data in more than one place!!!! FTP, external hard drives, everything!!!
4)Risk of losing a team member due to illness or emergency
Make sure everyone is aware of the big picture, so the team will be prepared to divide and take over the responsibilities of another team member if they become ill.
5)Team member slacking or not pulling their weight.
We break thumbs
6)PC MAC compatibility issues
Constant testing to make sure everything is cross platform and bug free.
7)Conflicts between team members
Make sure there is a clear goal set so that everyone is working on the same game (not 4 different preferred versions). Making sure that everyone is able to speak there mind and communicate openly should help reduce conflicts.
8)Making sure everything is done on time
Set regular milestones and make sure we stick to them
Team The Pwnographers
LAB C
Problem: Programming skillset not strong enough
Solution: Ask the TA or peers for assistance. Have each member take on a programming
role.
Problem: Poor time management (other courses in the way, social lives etc.)
Solution: Set weekly milestone and project goals
Problem: Schedualing conflicts within the team.
Solution: Work semi-individually on different aspects of the project then collaborate
each week.
Problem: Art skillset not very strong.
Solution: Allocate more time to polish the art. Use simple but well made sprites.
Problem: Communication lines break down between team
Solution: Keep in touch via Instant Messaging, Text Messaging, Email, Phone, Face to Face
meetings.
Problem: The Scope of our project is too large to handle within the time.
Solution: KISS (Keep it short and simple). We build our game by adding features as we go
along, not by taking away features because the game is too complex.
Team #6 D103
Irving Lau Fang
Henry Kim
Daniel Lee
Problem: Meeting times.
Solution: Make good use of email and IM. Have constant meetings to keep all team members updated.
Problem: Lack of programming skills.
Solution: Ask the TA for assistance, do research and divide the load of programming work.
Problem: Keeping project updated.
Solution: Keep all the project work in a place available for all team members, for example a FTP.
Problem: Getting things done on time.
Solution: Set weekly goals that will encourage the team to finish parts of the project as the course progresses.
Problem: Sound.
Solution: None of us have a lot of background on music or sound effects. We will do some research on the issue and look for assistance regarding game music.
Problem: Different opinions.
Solution: We will discuss our differences as a team and reach a standard solution for the problem. If we can’t reach an unanimous decision, we will vote and go for what the majority wants.
Dagger Studios Risk Analysis
Problem: Falling behind schedule (too much work in other courses)
Solution: Further simplify the game by removing non key features
Problem: Data is lost due to hard-drive failure
Solution (Contingency plan): Backup data
Solution (Action Plan): Work off of some previous build and use design documents to rebuild additions to project
Problem: Team member gets sick
Solution: Re-distribute tasks to other team members
Problem: Product does not meet specified requirements (at any given point in development cycle)
Solution: Refer back to design document and use it as a basis for getting the project back on track
Problem: Catastrophic error discover in latest build
Solution: revert to previous working build
Problem: Required resource not present to complete the next feature on the list of things to do
Solution: re-schedule tasks
Team L'etoile Possible Problems and Solutions
Problem #1: Time management
Overloaded with other projects
* Solution: set a certain time weekly to be contributed for working on this project
* Second Solution: make the game modular. Set a schedule to complete each step of the game
Conflicting schedules
* Solution: arrange a time where we can all work on it together
Problem #2: Programming skills
No actual programmer in our group
* Solution: look at tutorials for actionscript and get some additional help from the TA's and/or the Instructor
Star effects (we have idea but don’t know how to program)
* Solution: find tutorials online that does similar effects, and experiment with it until we get the effect we want. Also, get help from other programmers.
Putting the graphics into the game with the coding (combining)
* Solution: start with the graphics first, and then incorporate the coding into it
Structuring the game in terms of programming (we can have several mechanics coded but may have problems joining them together)
* Solution: start with simple, main mechanics, and start to build on top of what is already coded
Physics – jumping up and down, stars falling
* Solution: find tutorials online, experiment with numbers, figuring out the mathematical representation of up and down, and when we still don't get the effect we want, ask David or other programmers who are efficient with actionscript
Problem #3: Different Artistic styles
Each person might have different preference of artistic style
* Solution: The producer will decide the artistic style of the game
* Second Solution: The artist of the team will draw rough drafts of pictures and will show the team to get confirmed. When it is confirmed, the artist will move into more details and into a final copy
Problem #4: Retrieving sound sources
Might not be able to find the sounds we wanted
* Solution: we will try to get sources from the internet or from the library
* Second Solution: produce our own sounds with recorders and adjust it with editing programs
POSSIBLE Problems:
* Injuries to teammates
* Natural Disasters
* Teammates getting kidnapped
* Cobras
-- Solution: Samuel L. Jackson
Team: The Unbeatables
Problem 1
In the beginning, our team was too ambitious and wanted to create a multiplayer game with fantastic graphics other than just a simple fun game. We thought we could use any program for the assignment and we planned to make use of the Warcraft III World Editor; however, David said that it’s not original enough. We have to change our plan.
Solution
We called for a team meeting and decided to work on the project with Macromedia Flash instead because it is easier than programming C++.
Problem 2
Only one of our team members is good in programming.
Solution
At the end, we chose to use Macromedia Flash because we are more familiar with it and it seems easier.
Problem 3
None of the team members have done Flash programming for games before.
Solution
We searched for tutorials on the internet. We discussed on the codes we need or don’t need for our game.
Problem 4
We have difficulty in arranging face to face meetings to discuss on the different issues of our game since all of us have different schedules.
Solution
We arranged online meetings, exchanged information through e-mails, and live chat on the phone.
Problem 5
It is even difficult to arrange phone conference with everybody.
Solution
Assign a team coordinator to make sure every team member is on the right track and have their working process in schedule. Compromise on a certain time every day when every team member will be on MSN.
Problem 6
It was difficult to control the car around the track.
Solution
Use circles in a second layer to make the car moves around it.
Problem 7
There were too many turns and corners on the track for the demo since our Flash programming was not yet fully developed.
Solution
Use an ellipse track for demo.
Problem 8
The color of the track was dull.
Solution
Design a more colorful track with bright colors. Add more elements e.g. bushes and trees to the background.
Mix brown with green.
Light green in the center.
Put colorful red and white blocks on the sides of the track.
Make it more graphical and attractive.
Problem 9
The color of the plants blends into the background color and do not show.
Solution
Modify the color to make it standout.
Problem 10
We would like to add sound to the demo but was not successful.
Solution
Solution not yet solved since we don’t have enough time before the demo.
Team Archers (Group 4)
Section D103
Phil Kim
Ching Hung
William Lang
Kyle Lai
Problem 1: Three of the four teammates are working and are unable to have face – to – face meetings frequently.
Solution 1: The members have agreed to have online meetings to discuss the development of the game. The teammates will individually use the lecture time to review and preview their own parts in the project and further discuss during online meetings and in labs.
Problem 2: The team has little experience in advanced computer programming such PHP and MySQL. This is especially problematic in creating database to keep scores in the game.
Solution 2: The team has decided to create a Flash game. Many flash basic tutorials are available online as well as assist from the TA. Flash is a great application which provides your audience engaging applications and it is fairly easy to write code with the help from the sample code library.
Problem 3: The teammates sometimes disagree with each other. Each member has his own opinion and suggestion, which causes arguments and debates.
Solution 3: We have divided the tasks and assigned specifically in which person would take the job. We have selected a project leader and he will be in charge of ensuring all suggestions and opinions are taken into consideration.
Problem 4: Too many features are presented in the game. Some of them might not be doable due to the lack of experience in programming.
Solution 4: We have decided to only focus on the main feature that cannot be taken out in the game mechanics. The rest will only be implemented when we have extra time. We have ranked which ones are more important.
Risk: Gameplay design changes as time for implementation decreases
Likelyhood: High
Impact: HIGH
Preventative Measures: Agree on a concrete design that is even more simple than originally planned. In this way we will have a working game. With the Alpha behind us it is a goood idea.
Risk: No fantastic game artists in our group
Likelyhood: Low
Impact: medium high
Preventative Measures: Since gameplay is more important, focus on that. Functionality is more important first and formost. If all comes to all cloning simlar sprites are possible, or even making the characters as simple as possible to bring out our strength (gameplay) even more.
Risk: Each team member has different programming backgrounds
Likelyhood: HIGH
Impact: medium
Preventative Measures: All agreed to program in one area and make up for eachother's weaknesses. Also, some general preogrammign ideas are more important, such as data structures, typical structures of simple games... Etc.
Risk: Interruptions from other courses, midterms and such
Likelyhood: HIGH
Impact: HIGH
Preventative Measures: Time management improtant as well as spreading out the work. Everyone should contriubte the appropriate number of hours a week for completion.
Risk: Lack of ideas for bettering game
Likelyhood: low
Impact: low
Preventative Measures: Look for outside sources of inspiration. Originality is not as important as a workgin game in the beginning (considering we did not start with a terribly original idea)
Risk: One person dominating work, ideas, etc.
Likelyhood: High
Impact: High
Preventative Measures: Either allow the person to continue and agree with ideas considerably to continue the project or force comprimisation.
Ah!!! Forgot to write the team name. Previous post is from
The Fighting Mongooses
Team 8
Lab D103 (Lab C? Late Friday afternoon)
Team Back Spasm's risk analysis
Problem:
Team members are underperforming from lack of motivation. Team members do not show up for lectures/labs. Team members do not attend meetings.
Solution:
Find out if the team member is overloaded with work, whether from this class or other classes. Make sure the team member’s eating and sleeping habits are not being affected. Lighten their workload.
Problem:
Team members lack programming skills.
Solution:
Choose a programming language that does not have as steep a learning curve as C++. Follow tutorials online and take out books from the library.
Problem:
Team members lack programming skills.
Solution:
Choose a programming language that does not have as steep a learning curve as C++. Follow tutorials online and take out books from the library.
Problem:
Team members not following the design guidelines made in the GDD.
Solution:
Have team members communicate with each other about their work progress frequently. Find out early and steer the team member’s work back on the right track.
Problem:
Team members do not complete their part of the work.
Solution:
Find out if this is due to lack of knowledge or other reasons. Communicate with the team member. If the problem persists, the rest of the team will take on the work left behind and inform the professor.
Team Back Spasm
Lab B
Post a Comment