WordSerach - MemoryGame

** this is a memory game based experimet platform. **

Technologies

1. ASP.NET web app - Server side.
2. JavaScript - Client side.
3. MongoDB - Data Base.

Istallation

1. Open Visual Studio and clone project from git repository to a local directory.
2. Open solution in Visual Studio.
3. Click "Project" >> "WordSerach Properties" >> "Create Virtual Directory" save and execute "IIS Express(Google Chrome)".

Usage

The Flow:

As long as the user continues to move forward in the experiment he will have the following pages:

1. Concent page.
2. Instructions #1.
3. Instructions #2.
4. Example of game inteface.
5. Verification questions, to make sure all the instructions are clear and well understood - the user has 3 tries to answer correctly all questions.
6. Personal Details Page, the user supposed to provide some personal information - the user has 3 tries answer all questions and confirming he's not a robot.
7. The Game - the user and the agent finding a word in the puzzle, each on his turn according to the instructions.
8. End Game the user's supposed to fill in how many minutes each played by the format "mm:ss" after finishing the game.
9. FeedBack Page - the user's suppsed to answer all questions, altough he doesn't have to.
10. End page - last page, after clicking "submit assignment" the user will be redirected back to AMT.

Additional pages:

1. Error Page for Mobile access - experiment can not be done via mobile Smartphone.
2. Error Page for second(and more) time user - experiment can not be done twice or more by the same user.
3. End of experiment for a user that does not agree to term in Concent Page.
4. Error Page - should be redirected to a general Error page for any error that might occur during the experiment.
5. Too Many Tries page - in case the user answered incorrectly more then the numbers of times he's allowed to will be redirected here and finish the HIT.

remarks

All pages in this list are simple HTML Pages with some JavaScript and CSS, the text in the pages can be modified in pageName.cshtml:

1. Consent page - ConcentIndex.cshtml.
2. Instructions #1 - InstructionsOne.cshtml.
3. Instructions #2 - InstructionsTwo.cshtml.
4. Example of game interface - interfaceExample.cshtml.
5. Personal Details - PersonalDetails.cshtml, PersonalDetails.js.
6. End Game - EndGame.cshtml, EndGame.js.
7. End page - EndPage.cshtml, EndPage.js.
8. Error Page for Mobile access - MobileError.cshtml, MobileError.js.
9. Error Page for second(and more) time user - SecondTimeError.cshtml, SecondTimeError.js.
10. End of experiment for a user that does not agree to term in Consent Page - DisagreePage.cshtml, DisagreePage.js.
11. Error Page - ErrorPage.cshtml, ErrorPage.js.
12. Too Many Tries page - TooManyTries.cshtml, TooManyTries.js.

All pages in this list are complex self-generated by admins configurations:

** Full code documentation and configuration settings can be found in the relevant class **

1. Verification questions - verificationRulesScript.js.
2. The Game - Game.js.
3. FeedBack - feedback.js.

The structure of the server:

Besides the usual folders of asp.net we have 2 new folders.

The “ClientHandler” folder which holds the main logic of the server and the main models (json data represented as a class in c#) we use to keep track of the users. It holds a class called “ClientHandlerModel” which is responsible for the logic of the server. the rest of the modles in the folder holds only data.

The “Models” folder which holds most of the models that holds data (i.e. json data) and a class called “BoardModel” which holds the logic for creating new random matrices.

Controllers:

1. HomeController: responsible for suppling the views to the front end.
2. DataController: responsible for managing the data flow between the front end and the backend.

Generals:

Every new user that comes to the website starts in the ConsentIndex page and ends in the EndPage page. When he comes to the ConsentIndex he comes with 3 params. Those 3 params are stored in Cookies. And each time the front end sends us data about the user (or asks for data to show the user) we extract those 3 params from the cookies and put it in the “AmazonInfoModel” model.

All the info from the front end as well as all the info that we take from the database to give to the front end we put in the “UserModel” model (located in the ClientHandler folder).

The main class that is responsible for the logic of the backend is the “ClientHandelrModel”, and the main data structure this class uses is a static dictionary that maps a “WorkerId” (of type string) to a “UserModel” .

When a new user comes to the website 2 things happen

1. We create an instance of the “UserModel” model that will keep all the info we need about this user.
2. We create a thread that will download all the info the front end needs for the new user.

Game:

Each game consists of turns. A client game and an agent turn. The info of whose turn it is right now we store in a cookie and update this cookie each time the front tells us the last turn is finished. Each turn we supply the front end with the info he needs to conduct a turn.

ClientHandelrModel:

This class holds the logic of the backend. It has a static dictionary that maps WorkerId (of type string) to a “UserModel” instance. The dict is static so it will keep the data and not delete it (as it is a restfull api) . The dict holds all the users that are currently using the websites. A user will be deleted from the dict only after we upload the user data to database. We can access a user in the dict using the cookies from the user (which holds his workerid). Because we have a thread that downloads the info from the database and put this data in the UserModel in the dict and a different thread (the main thread that answers the front end) that may wants to also add or delete info from the dict so we use a mutex each time we touch the dict. The class is divided into 3 parts.

1. The first is to add info to dict from the frontend.
2. The second is to download info from the database and upload data to the database.
3. The third is to provide the frontend with the data he needs(usually the data we downloaded from the database)