cwru-hvz-core / cwru-hvz-source Goto Github PK

The JSON loaded by the OZ tree should escape quotes in people's names:

e.g. the tree is currently broken because of the string:

[{id:"player320",name:"Brock "Panda" Sandrock",data:{tags:2}

It would be helpful to include the location of found caches. Perhaps the administrator can indicate where a cache was hidden when entering adding one to the database.

Currently, the mission attendance list shows the player's current game state, not the state that player was in when the mission began.

Some fields of a registration, such as a Squad, off-campus status, or Card Code, should be editable after the game begins by admins.

I don't think any fields of a registration should be editable by the user themselves after the game begins.

So maybe this is a validation change that needs to be a bit smarter about what can be updated, and when.

Assuming a user is logged in, the user should be able to register for a game easily.

Upon registration, a 5-digit hexadecimal code should be generated for that player and stored in the corresponding column.

Instead of playing around with Case's SSO and customizing the login process for each school, let's just integrate CaseHvZ with facebook's single-sign-on. And, we will have a "non-facebook" login for the less intrepid.

Pros:

• Everyone has facebook.
• With facebook integration, we can maybe do some other stuff later (automated posts, or use it as our notification platform)

Cons:

• I would be slightly uncomfortable typing in my facebook password into another's computer. But typing in my SSO password makes me more uncomfortable, so this might not even be an issue.

The following error is causing a 500 error when attempting to access any page on the site:

ActionView::Template::Error (File to import not found or unreadable: compass. Load path: /home/hvz/cwru-hvz-source (in /home/hvz/cwru-hvz-source/app/assets/stylesheets/application.css.scss)):

When submitting a tag, if the map takes up a smartphone's entire screen, the user can no longer scroll around the page; they can only drag around inside the map element.

There should be a game controller. This controller should be resourceful and have all appropriate views:
app/views/game/index.html.haml
app/views/game/list.html.haml
etc.

Right now, games#show throws an error if the game has not yet begun. It's because there is no state data to generate the graph.

So, either the graph shouldn't be displayed or the page should just say something to the effect of "Sorry, nothing to see here".

Your call.

When you register, you should be receive a text saying something like "Thanks for registering for HvZ Spring 2011. Your card code is 12345. The game begins Wednesday at Midnight!"

See Issue #14 for more details about how to implement this. As for proper location, I think app/controllers/registrations_controller.rb will be the correct place to add this.

Players earn points for doing cool stuff. Here is what we need to make this work:

1. A mathematical function f(T) that models the difficulty of staying alive T hours. As a player remains human, this component of their score will increase every hour. When (if) they are zombified, this will continue to contribute to their total score but not increase further.

2. A model to determine how many points a "tag" is worth to that zombie. I'm thinking perhaps a percentage of their parent's kill's points plus a percentage of that player's points? This is tough indeed.

A programmatic way to sum those two, along with the score achieved from winning missions.

It makes sense that it currently does, but even the OZ family tree should not reveal the names of the OZs before it is time.

e.g. GET /game/:id/

On this page:
-- number of players
-- current status ("begins at _____", "in progress....", "human victory!", etc.)
------- if the game has yet to begin, registration info (dates and times) should be displayed
-- the missions that occurred during that game and their outcomes
-- the game's homepage text (this should be its own field in the games table)
-- more?

This might be as simple as selecting all records and keeping a hashtable, but either way, the current method used to calculate scores is not viable.

(In app/models/game.rb and lib/update_game_state.rb)

In lib/SendNotification.rb, create a method which accepts a list of people and messages and sends all texts at once without having to sign in multiple times.

Add support for avatar uploading and/or (I vote for 'and') gravatar support a la railstutorial.org.

If you turn from a human to a zombie, you should be texted.

Check out lib/send_notification.rb for the working implementation. Whoever is working on this needs to add a delayed job to send the notification. This looks like:

Delayed::Job.enqueue SendNotification.new([player], "message")

Following this tutorial has worked for me before:
http://www.aidanf.net/rails_user_authentication_tutorial

As a user, I should be able to login by clicking a "Login button". Then, by interfacing with Case's Single Sign On ( http://rubygems.org/gems/rubycas-client ), a new user object should be created and saved in case I return.

At some point, admins should be able to click a button and OZs will be revealed. This basically entails:

• Making the OZs show up as Zombies on the Scoreboard
• Correcting their point total to not reflect the automatic human survival bonus
• Not adding in points for kills while hidden (i.e. to keep their identity a secret)

For example, if your game is scheduled to start tomorrow, and you go into the Manage Games page, and select it to begin yesterday, you should be warned via a popup alert (or something) that you are accidentally starting your game.

Since you cannot edit times after they have passed, this option is irreversible (without database hacking). Some warning is thus a good thing.

It would be great if it was possible to see the player list and sort by time until starvation? This was possible with the old version of the site and would be very useful for humans trying to pay attention to population dynamics.

...unless you are logged in as a zombie.

Someone needs to make us a layout that we can fit all our stuff into.

If possible, use jquery-pjax to load the updated parts of the page only.

(Note: this issue is mostly just so I don't forget the name of it, because I had intended to find this during the summer but couldn't, despite my best Google efforts.)

The site should allow admins to email sets of people. We can use the Gmail SMTP and casehvz's address.

Sets may include:
Registered, not Registered
Humans, Zombies, Deceased
OZs
Waiverless
Faculty

Perhaps some nice set operations could be available to admins.

Informal message boards exist (at least for zombies) on facebook, so I think it'd be nice to add a board on the website to talk about strategizing. One available only to humans, and the other available only to zombies. A general talk board, too.

If the zombies die before the mission starts, they should be ineligible to receive mission feeds.

If they die during the mission, they should still be eligible.

This should recursively re-humanize any deaths caused by this zombie. It should regenerate card-codes for newly-revived humans and notify each player through SMS and e-mail.

Forums have been offline for some time. Diagnose the issue and bring them back online.

Production log grows without limit. Attempted to fix in commits 03e7578 and d035794, but did not succeed.

The homepage currently has way too many hacks in case there is not a game. These hacks should be removed and then magic applied so that when there is not a game in the database, the site continues to function.

A missions controller needs to be created. It should be resourceful.

GET /missions/:id #Shows the given mission
GET /missions/:id/edit #Allows a mission to be edited by an administrator
GET /missions #Shows all missions for the currently selected game (session[:game])
etc...

Admin validation should definitely occur on new, edit, create, destroy, and update methods.

Each mission has a description that can should support the use of Markdown or Textile (whoever wants to implement this gets to make the call).

Information should be shown about the mission including:
-- the start and end times (from the db.)
-- the winning faction (iff now > mission_end)

Admin should be able to see a list of all tags, and be able to delete them (See #31). Also, each tag resulted in two feeds -- those should be displayed too.

Game.current.utc_offset should reflect the game's UTC offset regardless of DST.

...from mission attendances.

Add a boolean column to the registrations table (use a migration) which represents "lives off campus."

People should be able to check the box while registering.
Admins and people should be able to check the box in the registration edit page.

I think we should start using ASAP (and keep using) RSpec as in RaillsTutorial.org. The setup is relatively simple and needs to be done only once. Relevant chapter here:
http://railstutorial.org/chapters/static-pages#top

The admin manager page should have a link to set a player's waivedness to "true" and players should be notified and then later removed if they do not have a waiver by a certain time.

^^^

Relatively simple object here....
Everyone should have access to GET /infractions/:id (infractions#show) and GET /infractions (infractions#list).

Only admins should have access to all the other resource actions.

Consult the db schema for exactly what infractions need to have.

Note that any frontend display of the word "Infraction" should be written as "Marks of Shame". :)

With some form trickery on the tags page, nefarious players may be able to submit administrative tags. Some validation should be performed here.

We should store the person id of the admin which logged an admin zombification.

As a user, I should be able to:
-- update my own Name, Cell Number, and picture

Let's implement this in GET /person/:id/edit

Base Mission "templates" that can be applied to any game. They should have comments and analysis of previous implementations of the missions and when they can best be applied in the game.

Strictly gameplay, of course--storyline can be different every time.

Installation of this app fails on current version of macOS due to a failure to install "pg 0.16.0 with native extensions".
error.txt

So, this might be as easy as adding a hashed_password column to registrations and then creating a separate login page which allows you to pick your own "username", which is stored in the "caseid" field.

We should ensure that the desired username does not match [a-zA-Z]{3}[0-9]{0,4}. Or, better yet, it appends a transparent "cia-" to the beginning of the username and stores that as the caseid.

Then, when they log in with their own page, it puts their username (plus whatever "cia-" business is going on) into session[:cas_user].

As a player with a registration for a given game, I should be able to register a tag in that game assuming that:

1. My faction ID is whatever value we assign to "zombie", or
2. My "is_oz" field is set in the database
   and
3. I am registered for that game (and the game has already begun)
4. The card code I input identifies a recipient of my tag
5. The tagee is whatever value we assign to "human".

Or, as a player with a registration for a given game, I should be able to register a tag without a card code for a recently finished mission (end time + 4 hours).

When a tag occurs, an entry should be populated in the Tags table, as well as a corresponding number of feeds in the Feeds table.

Just thought of this - when you report a tag, you should be able to pick two feed recipients from a list of players.

The list of players should maybe be sorted by time of death?