S/W Design and Architecture

Final Project: Adventure Game with Microservices

Objectives

During this activity, students should be able to:

This activity helps students develop the following skills, values and attitudes: ability to analyze and synthesize, capacity for identifying and solving problems, and efficient use of computer systems.

Activity Description

This activity must be developed in teams of two or three people.

Write a text adventure game using a microservice architecture.

Text adventure games (often referred to as “interactive fiction” by modern scholars) use text to create virtual environments where a player inhabits. The program provides you with a simple written description of your surroundings, then asks you what you want do next. To move around or interact with your virtual surroundings, you key in text commands telling the game what you want your avatar to do. These commands are typically very simple, usually composed of just two or three words, such as “go south” or “get sword”. [...] By reading and typing text, you make your way through the virtual world, collecting treasures, fighting monsters, avoiding traps, and solving puzzles until you finally reached the end of the game.

Ernest Cline, “Ready Player One”, p. 226.

Requirements Checklist

  1. Application Code and Functionality
    1. The application must be comprised of at least three microservices plus the client code that integrates them all and provides the user interface.
    2. Each microservice must run in its own process and implement a RESTful API with JSON responses.
    3. One microservice must be written in a language different from Ruby (JavaScript, Python, etc.). The rest must be written in Ruby.
    4. Each microservice should have its own independent persistent store, shared with no other microservice.
    5. The text adventure game can be similar to those described in the book “Creating Adventure Games On Your Computer” by Tim Hartnell. It can have any theme that you want and it can be as large and sophisticated as you wish.
  2. Documentation
    1. You must write the documentation for your application’s design and architecture. See the example in: greeter.tgz. The greeter/README.rdoc file contains all the indications on how to produce the documentation. This is how the final result should look: greeter/doc/index.html.
    2. Your README.rdoc must contain these sections:
      • General overview
      • How to install and run the application and all the microservices
      • 4+1 architectural view model
        • Logical view
        • Process view
        • Development view
        • Physical view
        • Scenarios
      • Patterns used
      • Acknowledgments (optional)
      • References
    3. Every Ruby class and public method developed must be adequately documented using the RDoc markup language.
    4. All the source files must include at the top the authors’ personal information (name and student id) within comments. For example:
      # Final Project: Adventure Game with Microservices
      # Date: 03-May-2018
      # Authors: A00456654 Thursday Rubinstein
      #          A01160611 Anthony Stark
      

Deliverables

Place in one tarball file called microservices.tgz all the contents of your project.

Upload Instructions

To deliver the microservices.tgz file, please provide the following information:

Request PIN

Only one team member needs to upload the file.

Due date is Thursday, May 3.

Evaluation

This activity will be evaluated using the following criteria:

50% Implementation of program requirements.
50% Documentation.
1 The program and/or documentation was plagiarized.