A new wiki is coming!

This wiki will be locked for editing on Friday, March 13, 2020, while we upgrade to a new wiki. Here is more information about our migration process.

This box searches only this space. The box at the upper right searches the entire iPlant wiki.

Skip to end of metadata
Go to start of metadata

Project: Game Group Project for ISTA 251 - Galen Bowman

Andres Garcia

Galen Bowman

Kai Blumberg

Jacob Bernard

Samantha Robbins

1. Write programs for people, not computers

  • The program for this game is obviously meant to relay basic concepts to the player. There are only a couple of characters in the game that you have to remember (yourself and your coach), obvious consequences for decisions the player makes (not eating well makes you underperform, throwing a punch when you should’ve dodged gets you punished), and you aren’t going to have to solve a puzzle in the middle of a story game.
  • A

2. Let the computer do the work

  • The computer, in this case, does most of the work, but all of the decisions are meant for the player to make. The computer keeps track of these decisions and gives the player certain perks depending on the decision made. For example, if the player chooses to go to bed early they become well-rested and can do things that a player who chose to do something else in the night cannot do.
  • A

3. Make incremental Changes

  • The project was not done using a version control system. Meaning that a version of the project was not saved and put aside before any major changes were made. Luckily, when working with Twine, this is not necessary. However, the project was done by working in small steps. After a large enough portion of the project was completed, it was tested to make sure all components interacted the way they were expected to. I.E links led to the correct places, variables had the correct numbers assigned, etc. The same testing was done after each edit was made and as the project went on. Making sure each new component was compatible.
  • Grade: A

4. Don’t repeat yourself

  • Twine is like storyboard writing. You can attach two panels together and move in a linear fashion. A goes to B, B can go to C or D. When replaying a scenario or a similar situation that has played out before, the easiest method is to just link to the same panel.
  • Grade: A

5. Plan for mistakes.

  • a. Add assertions to programs to check their operation.
    • The project was implemented in Twine an open-source tool for telling interactive, nonlinear stories. It makes use of the equivalent of "if statements" which are written in as passages and which are ordered logically in order to handle the the control flow of the steps which occur in program/game. There wasn't an obvious mechanism to add such testing assertions, but they were all manually tested.
    • Grade: B
  • b. Use an off-the-shelf unit testing library.
    • Twine employs modular story/code snippets to advance a bifurcating story, but there aren't obvious unit-test which can be deployed. Instead manual checks were performed.

    • Grade: B

  • c. Turn bugs into test cases.
    • Bugs were not officially turned into test-cases, however, when bugs occured being gaps in the story line's control flow it forced the creation of new code blocks to cover the bugs/gaps.

    • Grade: N/A

  • d. Use a symbolic debugger.

    • No symbolic debugger is available for the Twine language.

    • Grade: N/A

6. Optimize Software only after it works correctly -Samantha Robbins

  • 6a. Use a profiler to identify bottlenecks
    • The game itself is not a high functioning game, it also did not utilize code but instead the Twine game creation program. A profiler, in this case, was not required or necessary for the project. Even at multiple passage options, the game was consistent in speed and usability. 
    • N/A - A
  • 6b. Write code in the highest-level language possible 
    • This project was not written in code but was created in a workspace. The workspace had the appropriate level of performance for the project at hand, which was small and simple in nature.
    • N/A - A

7. Document design and purpose, not mechanics. - Samantha Robbins

  •  7a. Document interfaces and reasons, not implementations.
    • Within twine, each “passage” included a title of what that passage is asking of the user. It is a clear description of what that box includes. Since it is a story game on a program that builds as a service, commenting specifics was not an option so a document included a more in-depth description of each passage with corresponding titles and in the working order of the game. 
    •   A
  • 7b. Refactor code in preference to explaining how it works.
    • Since no code was used in the making of the game, the game itself was organized in the order of progression. Twine has the ability to move the passages around in a workspace and links possible next steps with a line. The passages in the game are ordered from start to finish and equally spaced for the multiple option passages in a readable format for any other user to come in and understand. 
    •     It has a clear beginning and a clear progression of where the game goes
    • A
  • 7c. Embed the documentation for a piece of software in that software.
    • Documentation in Twine was not used, links are allowed in the program but embedding software into it was deemed difficult. Errors and changed were documented by hand after running the game in its newest edited version compared to the last version. Yet, since the game was small, this was efficient. 
    • B

8. Collaborate.

  • a. Use pre-merge code reviews.
    • No versioning system was used which would allow for pre-merge code reviews. Instead portions of the code were written and tested before incorporation into the equivalent of the master branch.
    • Grade: N/A
  • b. Use pair programming when bringing someone new up to speed and when tackling particularly tricky problems.
    • Pair programming was necessary in order to collaborate on this project as no version control or merge revision system is implemented in the Twine language.
    • Grade: A

  • c. Use an issue tracking tool.
    • No formal issue tracking tool was used, Twine itself doesn't provide such a thing, however an informal word of mouth and interpersonal issues was list was used instead.

    • Grade: B


Final Grade: I would give this project a final grade of an 'B.' For what the project was, it filled a great deal of the criteria for this project model despite not using a lot of traditional computer coding. However, its shortcomings were mostly in the collaboration criteria. Twine is a game making tool that cannot be shared online. Because of this, it cannot be edited at the same time by group members. The group members for this project only used spare class time to discuss and work on this project together, so what coding there was on Twine, one person did it. However, the story was well developed and whenever a group mate had a question, the other members would answer quickly to the best of their knowledge. 


Post-Mortem Analysis

Good: Everybody contributed to their part and completed the assignment before the due date.

Bad: Some group members didn't have their notifications on slack so it was hard to reach out sometimes.

Ugly: N/A

Change: Have notifications on so that the entire group is updated when progression on the project is made.


  • No labels

1 Comment