Virtual Community v5.0.0.0

(lol this is so not ready yet)

• Virtual Community is an LTI virtual community application. It is currently deployed as an instance called Jayhawkville. Jayhawkville is a virtual school district, driven by simulated student data and case studies pulled from real-life schools. Throughout the program, students are prompted to visit and explore Jayhawkville in order to complete assignments, examine case studies and make crucial decisions that parallel scenarios they would face in a live school setting. Jayhawkville has over 30 simulated schools spanning suburban, urban, and rural communities, complete with educators and students representing diverse real-world environments.

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

System Requirements/Dependencies

What things you need to install the software and how to install them

• Java Spring/mvn
• npm

Installation

# Map Editor Front End
cd map-editor-react
npm install

Starting the server

# Backend
cd virtualcommunity-java
mvn spring-boot:run

# Map Editor Front End
cd map-editor-react
npm run start

Running the tests

Backend

To run tests and generate a surefire report (so it's easier to see test results)

• �mvn surefire-report:report
• Navigate to <<project root>>/target/site/surefire-report.html
  • If the html looks unformatted, you may have to generate the css first using mvn site

To check coverage

• mvn test
• Navigate to <<project root>>/target/jacoco-ut/mapeditor/index.html

Map Editor Frontend

npm run test will watch for code changes

Coverage

npm run coverage does not watch, but generates a coverage report

Deployment

???? Add additional notes about how to deploy this on a live system

Architecture

Backend & Data Models

The backend uses Java Spring Boot and MongoDB. 

Structure Definition

Structure Definition contains the size and link to svg files for a structure. Because buildings/trees/structures can be reused over and over again, they are defined once and referenced by id in the world. Structure Defintiion has a type (kind) that currently does not contribute to mcuh, but the idea is to use the type to associate templates and actions and anything else that could be standardized across types. So for example, it there could be a school type of building, and they display on the detail pane the School name, district, and the principal. 

World

World is a self contained snapshot of a world. It has a background svg that serves as the general terrain of the world that structures can be built on top of. Structures are stored as a list that contains the definition (id), name, and position. In the future, it is intended to contain data/descriptions specific to that instance of a structure and also events that can be triggered over the course of the program. 

Versioning

Version control is done simply by pushing a new instance of the world whenever it is saved. The most recently created world is considered the current version. Old versions can be reverted to by simply updating their created_at timestamp to be the newest. A world is thus referenced by its key instead of id (where the id references a specific version of the world). The route for get will return the most recent version that's also published (assuming this route will be used for displaying the world to students). 

Remaining Tasks

• Test the validators @.@ 
• Reorganize the files into sensible packages

Frontend

Structure Library (StructuresView)

This page may very well be deprecated later, but at the moment, it CRUDs all the structure definitions. 

Map Editor (WorldView)

Maps are drawn in three main parts: Map, Board, and Tile. It's broken up as such to try to manage browser efficiency. Does it succeed? We'll never know. Most of the data is stored in the Map Editor state in the store but it references structure definitions often. It is passed in a world when it starts and duplicates a copy in the mapEditor state. The duplicated copy then generates a board as a 2 dimensional array to represent the tiles and a list of unique structures to predefine them for efficiency. 

Map

The map draws the outer svg container and lays out the map components and sets the size in the browser. It still needs to be styled, but it's a start.

It draws the background image first, then it defines all the structures as <symbols /> that will be <use/>d in the world. ( <use> tags should help with efficiency since they clone the referenced item. ) 

Board

The board loops through the the tiles (generated by looking at the structure positions and sizes) to render the tile component and send mouse events to the store. This was separated from the Map component to prevent redrawing and relooping through all the tiles every time the camera changes (since camera is controlled by svg viewbox). 

Tile

Tile draws a a very low opacity rhombus to represent the tile if no structure is given, otherwise it draws the structure and uses a lot of math to size and position it correctly based on the x and y coordinates. 

Add Structure Tile 

If the user has selected a building they want to add onto the map and their cursor is on the map, it will draw a lower opacity version that snaps to the grid. Clicking will place it on the map. At the moment, there is no save functionality implemented, but it should be as simple as sending a post request to the backend using the mapEditor.activeMap as the body. 

Remaining Tasks

• Save maps
• Edit world settings
• Remove buildings
• Fix Quill or implement a new rce for descriptions and long form data
• Show errors if there were any in fetching/saving
• Many many more things