Q.U.E.S.T Final Wiki
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of product
- 4 Reflection
Project Progress Summary
For a detailed timeline, click <font="12" color="red">here
|Week No.||Progress Summary|
1.Mid term scope vs. Final scope
- The table below is to summarize our new project scope after the mid-term evaluation.
2. Re-scope project with client
- Removed VM Portal and Kampung Centre
- Removed players to stay in own Kampung
Reasons For Removal
After the midterm presentation and discussion with client, we realize that we under-estimated the difficulty level of developing a facebook cum flash based game. Due to the time factor, manpower and skills, we re-scoped our project with our client. The functionalities dropped were derived after we discussed with our client and supervisor. Our client would like us to focus more on the game and the educational features it can bring, hence dropping the volunteer management scope.
3. Enhanced feature
We added new features in this game to further enhance My Kampung's ability to educate player and our project objectives.
- Wiki Info Pop Up
We have included an "?" icon at the top right corner of each item on the navigation. When player click on the icon, there will be a Pop Up box that will include:
Tips for playing the game
-Voluntary Activities at Kampung Temasek
-Information of NGO
-Real life Construction Knowledge
-Links to Wikipedia
We hope that through this function and the playing process of the game, player's will be able to gain more knowledge about kampung's lifestyle and their heritage.
- Facebook: Invite friends and Post on wall
This function will enable player's to invite their friends to play "My kampung". Not only that, players are able to post on their own personal wall about their achivement in the game itself. We hope that through this function, it can help to increase Kampung Temasek's awareness.
1. Game Development Process - Programmers & Designer
Usually, the designing team and programming team in the whole game development process works very closely with each other. This is due to the fact that many graphic changes need to be made in the midst of coding. In our special case, our designer is our client, hence although he is extremely helpful, our team would like to trouble him as minimum as possible for graphic design. Therefore at times, when we need to edit some of the graphics he did, be it resizing or touch ups, we need to edit the graphics by ourselves. The challenge here lies in the very fact that none of the members in our team are proficient in Photoshop, hence all of us had to start from the very scratch and try to edit the graphics. This takes up a lot of our time and is a very tedious and nerve wracking process to go through.
2. High programming difficulty level
Firstly, we have to learn various new coding languages (Flash AS3, PHP5, Facbook api), as well as learn how to link and integrate between Facebook API PHP and Flash AS3. Our team had a tough start climbing up the steep learning curve of Flash AS3. Although we had geared ourselves up with basic tutorials on Flash AS3 before January, we were shocked by the number of things we have to further learn in order to do such a high level game. Given a tight time line, we had to push ourselves to the highest limit and support each other when we just started out, fighting the temptation to drop the project. However, one we manage to climb up to the top of the learning curve, our progress sped up by a large extent, and besides completing the project on time, the great sense of achievement made all these worthwhile.
Additionally, the integration difficulty level was extremely high especially for the facebook api since the coding structure had shifted from PHP SDK to Graph API from 2008 onwards. This caused Most of the solutions online which addresses our problems to be outdated as there are very few tutorials or solutions regarding Graph API. We hence need to spend a lot of time to find out relevant information as well as study in depth about Graph API before we manage to find solutions to our problems.
1. Learning new programming languages: Action Script 3, PHP 5, Facebook Markup Lanaguage
- Progress sped up a lot towards the end of the project as team members are much more skillful in Flash AS3 Coding and PHP coding
2. Being able to connect database with flash game
- This is an extremely important hurdle which we manage to overcome it in the end.Otherwise, the game won't be able to deployed and run since the progress of the player and game statistics need to be saved in the database.
3. Experiencing the whole game design and development process
- Game development process is very different from application design.The first stage concept and design phase. The main objective of our game is to prove the concept that youth can learn knowledge through popular social networking website through fun games.
Project Schedule (Plan vs. Actual)- Midterm till End
Late compared to Planned date
Early compared to Planned date
|Iteration||Task/Function/Feature||Planned Start||Planned Finish||Actual Start||Actual End||Comments|
|5||Database||16/02/11||23/02/11||17/02/11||21/02/11||although late, but ended early|
|5||Testing & Debugging||04/03/11||07/03/11||04/03/11||07/03/11||-|
|6||Review Random Event & Capturing Animal details||08/03/11||08/03/11||08/03/11||08/03/11||-|
|6||Review Random Event & Capturing Animal design||08/03/11||08/03/11||08/03/11||08/03/11||-|
|6||Animal trap and Capture||08/03/11||14/03/11||08/03/11||16/03/11||-|
|6||Invite friends||08/03/11||21/03/11||08/03/11||28/03/11||a tough function.
Need to learn how to link facebook api with php.
Took much longer then expected to code and debug
|6||Wiki Info & tutorial||14/03/11||15/03/11||17/03/11||18/03/11||late end due to late start.
Delayed due to commitments to heavy project load from other courses
|6||Integration||22/03/11||25/03/11||18/03/11||20/03/11||sped up in integration as team becoming more proficient in Flash AS3|
|Deviation (days)||Interpretation||Action Plan|
|> -2||Too slow||PM reschedule or re-scope functionality with client. Move task to next iteration|
|-2||Slow||Not much changes to the schedule. PM push team members to put in more time, work harder for next task or iteration|
|0||Normal||Well within schedule|
|0-2||Fast||PM assess situation – to move on to next task/iteration or help the team|
|>2||Too fast||PM assess situation - Re-schedule, do more testing|
*Name in red represents the member in charge of that particular function
||Desmond was initially in-charge of the Facebook feature. Due to commitments to a dance performance, task allocation was changed. Christina stepped in and take charge of part of the Facebook features - Invite friends and Share on Wall|
||Christina was initially in charge of the tutorial. However, after UAT 2 feedback, a new tutorial must be made for 1st time players. Due to Christina's examination commitment, Bau stepped in to take charge of the new tutorial as he do not have any examinations to tackle.|
|Database & Deployment||
*Ranked in order of highest complexity first
1. Creating a social game using Flash AS3
Building a flash game to run on flash player 10 requires actionscript 3 technical knowledge. The initial research for tutorials in this area took up alot of the team's time. This is also the core knowledge the team needs as it involves building a graphic interface, coding event handlers' between objects and connection to the MySql database. Slightly after midterm, we reached the peak of the learning curve - event handlers, interact graphics on stage and database connections becomes our bread and butter.
The next biggest challenge the team faced is - getting the database set up. Getting the database up is another pillar to project; next to graphical interface and event handlers. Without a database, there will not be a "save" and "continue" game feature which allows players to revisit the game later and continue from where he/she has left off. There were many possible ways to implement the database connection between flash and MySql. After a long time of research, it was decided that PHP5 will act as a web service to transfer data from the MySql to flash, vice versa. This feature takes up alot of time to implement. But once the correct algorithm was used, subsequent integration between different features and the database posed no issue.
3. Facebook API
Integrating our flash game with facebook has to work or our project will fail to meet our client's criteria. Researching the right piece of tutorial took up quite abit of time as most tutorials provided before 2008 were outdated as since then, facebook has changed its code structure in terms of APIs provided for flash and facebook integration. We are glad that besides implementing the invite friends' feature, our team also managed to implement additional features such as "like" and "post on wall" for our client.
Quality of product
|Metrics||Schedule Metric (Planned vs. Actual Schedule)|
|Requirements||Storyboard||Storyboard narrated by QUEST Project Manager in video format|
|Analysis||Use case||Use case diagram|
Due to copyright issues, we are not able to upload the code up here.
Scalability & Performance
When our client first approach us, their request was to concept prove a something, which is the transferring of knowledge from a game to the player in a fun manner. Not just any game, but more specifically a Facebook game. Hence, scalability isn’t something that we took into consideration during the design phase due to time constraint.
We did however found out the limit of the server that the client provided during the second UAT. When there are more than 10 player playing concurrently, the game will start to lag. We analyze the problem and came out with two possible explanation. First, our client’s main website is being hosted on the same server and we are sharing the server’s resources, hence the issue. Secondly, due to our coding structure, the server is not able to handle player’s request.
At the end of our project, we suggested two solutions. First, they are to upgrade the server vertically or horizontally if they are considering deploying the game full time. Secondly, we are able to help out and reprogramme our game and consider scalability as part of scope during the design phase.
Reliability & Availability
During our 2nd UAT, one of our objectives is making sure that the game is available at all time and do not crash due to any coding errors. At the end of our 2nd UAT, the game crash once due to a hidden bug. What happen to only one of our player is that his items were wipe off the map even though it is still located in the database.
Our team manage to duplicate the problem so that we are able to analyze and solve it. During our 3rd and final UAT, and with the number of tester tripled, no such issue happened again.
In conclusion, our team can confidently say that in terms of the reliability of the game with regards to the game coding structure itself, it is reliable.
For our project, this is how the architecture works. First, players need to be facebook users who have login to facebook. When they access My Kampung in facebook, facebook server retrieves the My Kampung Flash game from Kampung Temasek's server, which in turn retrieve all the game data for that particular player from Kampung Temasek's Database. If the player is a first time player, his/her personal information such as his/her name will be retrieved from the facebook database and sent to Kampung Temasek's server and be stored in Kampung Temasek's database. This is of course done after the player had given the permission for facebook to transfer these details to Kampung Temasek's server. If the player were to diagree to sending these personal information, he/she will not be able to play this game. During the game, updates will be carried out and stored into Kampung Temasek's database as players continue to play the game.
|UAT 1||UAT 2||UAT 3|
|Date||12-13 Feb||10 Apr||13-14 Apr|
|Venue||Email & Facebook||Standard Chartered Lab (focus grp)||Email & Facebook|
|Objective||Testing of the interface, layout and user-friendliness||To collate more Qualitative results. Testing of the whole game.||To check whether enhancement done after UAT 2 feedbacks were done in the right directions|
|UAT 2 Feedbacks||Solutions||Remarks|
||New Tutorial for 1st time player||
|Spamming of Harvesting||‘5 action points’ rule||
|Not aware of Wiki feature||
|Lagging of game when 10 players play concurrently||Scalability Issue||our team focus more on proof the game concept that we can educate player and create social awareness for KT in a fun and interesting manner, yet with KT’s objectives in mind.
Hence we did not put handling scalability as one of our project goal.
Design improved significantly for UAT 2. For UAT 1, our design has not been confirmed and we have been using other online images. For UAT 2, we already have all the design which is tailored for the game, hence explains the significant improvement.
User friendlnness also improved . User find it easier to navigate and the building items are labelled hence making the game more understandable and more user friendly.
Clarity refers to the whether the objective of the game is known to users. However, although we improved from UAT 1, it is still either neutral or unclear to other users. We hence improved it and made it extremely clear in the compulsory tutorial in our final version.
Finally, as we have yet to indicate KT’s presence in UAT 1, UAT 2’s awarness factor increase significantly as we did promote KT in our final version.
UAT 3 clearly shows us that our enhancement did improved the quality of the game, as improvements in all the 4 categories (design, user friendliness, clarity and awareness) had show improvement.More importantly, clarity improved a lot as we stated the objective clearly during the 1st timer tutorial. The other 3 categories mainly around the same with slight improvements (partly due to an increased in respondents)
1. New programming languages
These challenges then turns into our learning outcomes after our team overcame them. First, we are now much more proficient in these 3 languages, AS3, facebook API as well as PHP 5. We are now able to make use of these 3 languages, especially flash AS3 to develop new game, and even websites using Flash. Doing normal games such as a shooting game or even Flash-based websites are much easier for us. With these new programming languages learn, we upgraded our programming skills to a whole new level and hence this will definitely help us in our future endeavors.
2. Game development process
Our team also managed to learn and experience the whole game development process. We actually spotted some similarities between the game development process and software development process which we usually learn in SMU. For example, having a user-friendly software/game is still a key factor, and we still do iterations, testing, debugging and deployments in the game development process, similar to a software development process.
The difference of game development lies in the fact that the game design(graphics and interface) is extremely important to a game whereas for software design(graphics and interface), the latter usually follows quite a standard template. Also, the development of the game theory is a tedious and challenging, since we have to think from a programmer's perspective as well as a player’s perspective. Having experienced the whole process, our team hence manage to gain some in depth knowledge about how the process work and hence may help us in the future if we were to venture into another game development.
Additionally, this whole game development process had allowed us to identify the various choking points of the process, and hence this will allow us to mitigate and have much better plans in the future if we were to do another game related project.
Lastly, having to constantly communicate with a real life client was an enriching experience for all of us. This is a totally new area different from school, where we do not follow a case study or write up of what we should do, and we have no steps or guides to follow through. We had learnt that there is no way a real life project will always have changes going on the way, and the key to tackle all these changes efficiently and professionally is to have constant communication with the client, and make very sure that we understand what exactly our client wants.
One interesting example that we had learnt from this project is a small mistake which we had made towards the end of this project. Our client had once suggested to use one of Kampung Temesek's architect's picture to act as the "tour guide" for our tutorial. Hence, we did and did not confirm one more time with our client whether the architect had agreed to this. As we were rushing to have our UAT 2 carried out, we launched the UAT 2 immediately after we had completed the tutorial function(with the architect as the tour guide) and hence this was were we made our grave mistake. The architect had actually disagreed to have his picture in the game, and hence when our client went to the website to check out the game, he was shocked to see the architect's face there as acting as the tour guide! Therefore, an urgent request was made to us to stop the whole UAT 2 process in order to take off the architect's picture. This impacted the progress of our UAT 2, causing a delay in the schedule. Luckily, not much damage was made as UAT 2 had just been launched and few had started to test it.
After making this mistake, we understand that it is always important to keep constant communication with clients in order to be on the same level as one another. Furthermore, this real life client experience had boost our confidence level in dealing with real live clients and hence will aid us in the our future working life.