{"id":178,"date":"2012-04-22T20:45:20","date_gmt":"2012-04-22T20:45:20","guid":{"rendered":"https:\/\/projects-old.etc.cmu.edu\/factomo\/?page_id=178"},"modified":"2012-05-01T03:19:03","modified_gmt":"2012-05-01T03:19:03","slug":"post-mortem","status":"publish","type":"page","link":"https:\/\/projects-old.etc.cmu.edu\/factomo\/?page_id=178","title":{"rendered":"Post Mortem"},"content":{"rendered":"

Introduction and Overview of the Project<\/strong><\/h2>\n

The Factomo project is sponsored by General Motors. \u00a0Our client representatives, Bob Tilove and Ron Lesperance, are from GM Research and Development.<\/p>\n

The original goal, as stated by the clients, of this project, was to create a full-scale simulation experience of an automobile assembly line.\u00a0 This project would range from allowing the player to manipulate part installation order at individual assembly stations, the positioning of tools (while keeping track of ergonomics and worker position), worker comfort criteria (such as music playing and the temperature of the facility), as well as the interactions between workers on the line.\u00a0 Finally, the game would be centered on crowd-sourced cooperation \u2013 having many people, possibly in a competition setting, attempt to work off each other\u2019s design ideas and layouts; the idea being that this could lead to the creation of a new layout or series of trends that could be used by GM in the real world.<\/p>\n

Within this large-scale goal, we chose a small component.\u00a0 Working off what we were able to learn about Fall 2011 semester\u2019s project, Sigma, we continued down the track of creating a simplified plant layout experience.\u00a0 This time, however, since the goal was to really focus on the layout itself, rather than worker-manager communication, as was the case with Sigma, we took a different approach.<\/p>\n

The core of our product is the plant layout experience.\u00a0 To do this, the player is presented with a simplified series of steps to build GM\u2019s En-V concept vehicle.\u00a0 These 11 stations must be placed in a prescribed order, as dictated by the client.\u00a0 Certain parts can be installed in any order, but the main choice the player has is what machine speed to select.\u00a0 To do this, one must consider the production budget as well as production goals to ensure that the decision will in fact increase efficiency.\u00a0 Upon completing a layout, the player enters simulation mode and watches as cars are made.\u00a0 The game then measures the amount of time it takes to create 10 vehicles, extrapolating this information out to a 30-day time frame, which provides a more useful metric.\u00a0 The faster one is able to produce vehicles, for the lowest cost, and with the least floor space consumed, the better the layout is.<\/p>\n

As for collaboration, originally we had sought to implement a system to track references between designs.\u00a0 This would allow us to track the usefulness of designs and allow an additional metric for measuring success, but we had to remove it due to a lack of client interest and time limitations. \u00a0As a result, the ranking system displays the most successful layout currently available in the system for players to continue working on.\u00a0 While we lose the ability to have players work on and attempt to improve an \u201cunderdog\u201d layout, we do gain data integrity, because without the ability to track who is referencing what design, it would be very easy for a player to simply make a very minor change and have his name appear as a more successful layout.<\/p>\n

Deliverables<\/strong><\/h2>\n

For this project, we have created a Unity WebPlayer based game (a standalone executable will also be compiled), which stores and accesses content in a central MySQL database.\u00a0 There is also a registration website that interfaces with this same database to handle user authentication and to help players learn more about the game as well as manage their account information.<\/p>\n

The following is a breakdown of how the system works as currently implemented during development.<\/p>\n

Registration website on ETC web server \u2013 accesses DB information stored in MySQL on Ubuntu Virtual Machine \u2013 sends email to players regarding registration & account management<\/p>\n

Unity WebPlayer game stored on Ubuntu VM, calls PHP scripts held on same VM to connect to, read, and modify content from MySQL DB on the VM.\u00a0 (In the case of the executable, it accesses these PHP scripts on the VM and makes the DB changes.)<\/p>\n

All of this content will remain at the ETC, managed by IT, but will also be packaged for future implementation elsewhere.<\/p>\n

Additionally, we will be supplying a Game Design Document and software documentation, that chronicle how we got to where we are, what features \/ client requests we addressed, what we didn\u2019t address and why, and what feedback we have received, from both playtesters and our clients.\u00a0 They will also outline deploying the products.<\/p>\n

What went well?<\/strong><\/h2>\n

This project was a challenge right from the start and the number one issue we had was the large list of requirements or requests provided by the client.\u00a0 That said, we were, in time, able to pretty successfully weed through and prioritize what they wanted and what we felt we were able to do.\u00a0 Overall, the team worked reasonably well together, given the level of frustration provided by a massive scope.\u00a0 By the time we got to half presentations the feature set and idea of the game was mostly set \u2013 we knew it was going to be almost exclusively about plant layout and that it was going to be a stripped down version of that.\u00a0 There was no way we would be able to simulate the experience at the level our clients really wanted.\u00a0 In the end, coming up with a final product that is playable and reasonably useful has proven to be an impressive feat, considering the disorder the massive scope initially placed the team in.<\/p>\n

Other things that went well include working with our clients and playtesting our product.\u00a0 All things considered, our client was quite easy to work with, excluding the ambiguous project itself, Ron, especially, was very willing and eager to share with us whatever information we requested.\u00a0 He responded quickly and seemed to be genuinely interested in what we were doing.\u00a0 On our trip to Detroit, both Ron and Bob took significant time out of their schedules to meet with us and give us a tour of an active assembly facility.\u00a0 While this was slightly embittered by the general lack of direction of the project, it is safe to say we are all pleased with what we have been able to accomplish and the relationship we have all been able to cultivate.<\/p>\n

Our playtesting sessions also went remarkably well.\u00a0 We gained highly valuable feedback from all of the tests arranged and many of our player\u2019s suggestions were incorporated directly into the product, especially when it comes to UI and tutorial elements.\u00a0 Finally, we were also pleased with being able to have some engineering industry workers examine the product and deem that they do see potential in attempting to bridge the gap between simulation game and simulation software.<\/p>\n

What went wrong?<\/strong><\/h2>\n

Many things.\u00a0 Our top issue this semester was communication.\u00a0 Whether it involved the client, scheduling, or keeping our advisers in the loop, there was a thorough breakdown throughout the semester.\u00a0 Most likely, this issue started when the problem of scope really became a main issue.\u00a0 It is unlikely that any of us anticipated the indecisiveness on the client\u2019s behalf or the number of decisions that would be left completely up to us.\u00a0 Instead, we anticipated a more complete idea from the client and unfortunately we were faced with an abstract concept from which to try and create something.\u00a0 Discussions with the client turned into something closer to negotiations early on and while that sentiment eventually disappeared as production began, it tarnished what could have been a better and more collegial relationship throughout the project.\u00a0 It is likely that, to some extent, this was also a carryover of last semester\u2019s project as well, so we kind of had to clean up whatever impressions they had of the last team\u2019s abilities before we could introduce our own.\u00a0 This is something that we should have tried to forecast and deal with in advance.<\/p>\n

Overall, an abstract idea would have been fine, but what we received was more like an abstract idea with an exceptional list of requirements.\u00a0 This was not particularly helpful and while it may have looked like they presented us with a viable idea, it instead became so large that it took us many weeks just to get our heads around.\u00a0 Adding this to our tour of a GM assembly facility, we realized all that they envisioned and were collectively blown away by the proposition.<\/p>\n

When it came to scheduling, a lot of the issues revolved around not having a firm grasp on what the end product was going to be, because we were unable to really figure out what the client was looking for or would be satisfied by until well into the semester.\u00a0 Ultimately, it is unlikely that this really changed the outcome of the project, but it did certainly lead to a bit of floundering when it came to answering what we were going to do next or how we were going to approach something that was not started yet.\u00a0 We were probably saved by our various skillsets and perseverance as far as being able to address problems as they came up, but it was less than ideal.<\/p>\n

Keeping our advisors in the loop proved to be a challenge in part because of a lack of a defined schedule.\u00a0 As a result, they were unable to efficiently head off issues in advance.\u00a0 There was also the situation of a language barrier.\u00a0 This made it difficult to quickly and accurately ascertain the status of any component of the project.\u00a0 While not necessarily a huge problem, it did result in some collective hesitancy to either ask about the project in depth or unilaterally reveal project material on the part of team members.<\/p>\n

Quarters presentations were farce-esque, in part due to a lack of any real tangible progress on our parts, but also due to a fair bit of negativity from faculty\/staff when it came to this client and project overall.\u00a0 We did not anticipate this, and expected a clean slate from them, as all but one of the team members was new to the project, but this was not the case.\u00a0 As a result, while we did get some good advice, such as Jesse\u2019s suggestion to immediately start prototyping (which we did), there was also great concern about the client\u2019s intentions and expectations for the project.\u00a0 We were already frustrated by the project at this point and this added tentativeness from the ETC-side was not particularly helpful or insightful, when we could only address what we had done with the project and client up to that point in the semester.\u00a0 While it is important to leave as much open to the team members as possible, as far as dealing with the client, dictating what we would be able to accomplish, etc., some sort of baseline should have been established at quarters or previous to quarters by faculty\/staff with the client if there was a genuine concern, which there seemed to be.<\/p>\n

Lessons Learned<\/strong><\/h2>\n

The top thing we learned was to define as soon as possible, for the client, what is and is not possible, closing doors and limiting the project as much as possible well in advance of beginning production.\u00a0 It would have been a better case scenario if we had been able to do this, then adding more features if we had time.\u00a0 Unfortunately, we were so collectively daunted that attempts to prioritize features, combined with pushback from the client, resulted in wheel-spin until we had enough of a time crunch that we had no choice but to lock-in and go, addressing what we could, when we got to it.\u00a0 This was obviously not a good situation, and contributed to a long list of issues, most of which were outlined above.<\/p>\n

Had this process occurred more properly, it would have likely allowed for more conventional ways of scheduling and task management to be used as well as for more information to be exchanged between the clients, advisers, and team members.<\/p>\n

Having a remote client with tech barriers is an issue that should be addressed early on and will consume an inordinate amount of time.\u00a0 In the end, we were able to have the game work over their network, but because of a lack of IT support on their end, we were prevented from having them go hands-on with a product until way at the end of the semester.\u00a0 Even with technical issues, had they been closer we would not have had to worry about this, as much, and it would not have had a negative impact on the client\u2019s impression of the team.\u00a0<\/strong><\/p>\n

Conclusion<\/strong><\/h2>\n

We do not know what the client\u2019s final plans for this project will be, but we do plan on having it be accessible, with servers running, at the ETC, until it is determined that it is no longer of use.\u00a0 The server setup is fairly straightforward with no really special configuration required so there is limited concern about that.\u00a0 Finally, the product runs well in Unity WebPlayer \u2013 a plugin that is fully cross-platform, so there is limited concern about compatibility.\u00a0 Our clients have also expressed an interest in having the deployment information sent their way, for possible use internally, which it will be.<\/p>\n

Overall, this project, while frustrating, also had many rewarding moments. \u00a0The final product attempts to hit as many requests as possible, while still being playable and stable.\u00a0 In the end, given the relative disorganization this semester started with the end result is impressive and a very good platform to attempt to build off of in the future.<\/p>\n

Download PDF version<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Introduction and Overview of the Project The Factomo project is sponsored by General Motors. \u00a0Our client representatives, Bob Tilove and Ron Lesperance, are from GM Research and Development. The original goal, as stated by the clients, of this project, was … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":6,"comment_status":"closed","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-178","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=\/wp\/v2\/pages\/178"}],"collection":[{"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=178"}],"version-history":[{"count":6,"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=\/wp\/v2\/pages\/178\/revisions"}],"predecessor-version":[{"id":194,"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=\/wp\/v2\/pages\/178\/revisions\/194"}],"wp:attachment":[{"href":"https:\/\/projects-old.etc.cmu.edu\/factomo\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}