Because the app is using socket.io and Heroku for hosting it ran into issues during the daily restart of Heroku where players would lose connection to the server.

After digging online, I found this: https://devcenter.heroku.com/articles/node-websockets#option-2-socket-io-start-the-app

A combination of enabling http-session-affinity and preboot and upgrading to a 25$ a month professional dyno allowed the server to retain its stateful game memory in node.JS even after a restart of dynos:

https://devcenter.heroku.com/articles/private-spaces#rolling-deploys-with-zero-downtime

Closes: #365

Basic implementation of auth0 on both the server and client side of the game. This was a challenging endeavor that required 5 separate NPM packages just to get everything working. None of the existing auth0 socket.io integrations considered the fact that you might want to have authentication be optional (guest mode), which presented a challenge in writing this for the backend.

Client side:

• implemented the Auth0Provider and useAuth0 hooks to let components drive the state of log in / sign up / log out. When the player logs in, the WebSocket manager fires a 'login' clientToServer event to the socket.io client.

Server side

• said login event authenticates by using a Machine to Machine set of keys on a separate webserver-specific auth0 application. The server handles verification of a user and confirming their usernames
• B/c none of the auth0 specific npm packages for socket.io were configured to handle optional login, I modified some existing middleware to account for this scenario.
• We're still staying in a monolithic structure due to low # of players. The webserver will handle authentication requests 🙏🏻

Player impact:

• Players will now have to be 'guests' if they don't sign up
• Players will get engagement stats, titles / awards, and possibly profile pictures / saved decks / etc. once they register in the future

New sign-in screen:

We need a modal system to display:

• open source credits (#237 )
• game instructions (#249)

This ticket will encompass the creation of a modal system to display those things

• use React.Portal to create the modal on a separate layer
• lazy load the modals
• make the modals actionable in redux, e.g. closeModal, openModal(ModalTypes.INSTRUCTIONS)

Magic units are OP.

They can shoot past soldiers, they have great effects stapled to them.

Beside their normally low attack values, if they remain on board, they are super hard to stop unless the opponent already has a board.

We need more ways for physical decks (e.g. monks) to beat magic ones.

Ideas: A unit that costs 1 and an Iron that is a 2/1 that destroys an opposing unit if it is magical (Gargoyle?)

A unit that costs 2 and an iron that deals 1 damage to all magical units

• [ ] introduce restrictions to effects:

• [ ] introduce a 'destroy' effect
• [ ] make the auto-resolver respect restrictions (if no valid targets that match a restriction, bail out early)
• [ ] make resolveEffects for destroy + deal damage respect restrictions

The bamboo farmer unit is one of the most powerful units currently in the game and seems to have almost no drawback

It is basically a 1-resource version of this 3-mana card in MtG: https://scryfall.com/card/khc/80/wood-elves

This leads to some powerful starts for the divers / farmers decks that make those decks unfair against other archetypes.

A potential drawback that Bamboo farmer could incur could be: "on death: destroy 1 bamboo resource of your own"

• [ ] #253
• [ ] #254
• [ ] #255
• [ ] #256

Puts the decklist selection into a new slice called decklist. In the future, this will include custom decklists, but for now, it just has the premade decklist

Part of #197 - we need this so that we have a sense of what decklist to display for the top-level router component that displays the decklist

I recently added CloudFlare as a CDN provider for the app and tackling the Google Lighthouse issues highlighted in #157 .

The biggest problem highlighted by the report was the client-side Javascript resources, resulting in a 4.8s First Contentful Paint + time to interactive. On 3G this becomes even worse, with a 10.5second first contentful paint. (Source: lighthouse report, see #158 )

Added code splitting + bundle minimization to reduce the overall size of client.bundle.js.

Every piece of the app besides the router was put into bundles that load when actually called.

Bundle Size

This reduced the size of the initially loaded code (excluding node_modules) from 264kb to 14kb. Before:

After:

Speed / loading

The impact on speed was also significant (tested using no-cache, Fast 3g simulator with chrome dev tools locally)

Before (3.0 seconds time to first paint):

After: (2.4 seconds time to first paint):

Avoiding Flash of Unstyled Content

B/c file splitting / lazy-load causes the app to paint in a jarring manner (flashing into the screen), I introduced an animation for the appearance of the NameChanger component to reduce strain on the eyes:

https://user-images.githubusercontent.com/1839462/158162840-94fca1c5-28c9-4ae5-9f7a-75c57f5f6fb9.mov

Borrowed inspiration from: https://nextjs.org/docs/advanced-features/dynamic-import#with-named-exports

https://www.youtube.com/watch?v=kT6yYSwK1oA < using react-spring, some of the animations like a unit bouncing from board to hand, or a unit fading away after dying could stand to be animated to better convey what is happening to the players. investigate react-spring as a potential solution for this nice-to-have feature

Right now, the players' cemeteries are not visible (a la Hearthstone), but are shown on the UI

This is a stretch epic to make players able to cast spells that revive a particular unit from a cemetery, or return a particular card from the cemetery back to the hand

• [ ] Make a spell card that revives a particular unit
• [ ] Make a unit card that on entering, returns a target spell card to the hand

Effects happen when spells are cast or units enter the board. Effects require resolution (either automatic or player-controlled) in order to advance the game state along. Effects are processed from the top to the bottom of the card

• [x] #78
• [x] #77
• [x] #79
• [x] #80
• [x] #81
• [x] #82
• [x] #83
• [x] #88
• [x] #84
• [x] #85
• [x] #86
• [x] #87
• [x] #89
• [x] #90
• [x] #91
• [x] #96
• [x] #97
• [x] #99
• [x] #100
• [x] #109

In most games, you have the option to pick a name.

This commit adds:

• a WebSocket provider that provides down all descendant components (such as IntroScreen) a way to access methods (e.g. chooseName) associated with the socket connection

• we changed the intro screen to involve picking a name before seeing anything else.

demo:

https://user-images.githubusercontent.com/1839462/155854794-6f90f4fd-ba16-4382-a73f-59403c3e2090.mov

We don't let users pick an already taken guest name, but we don't alert them about it today. It fails silently right now and it's confusing.

• Push an event to the client that their name is taken via websockets
• Upon receiving this event, the form field turns red and shows an error
• Upon typing, this error goes away

out of the box, auth0 provides the social sign-in email as the nickname. There should be a clear button that indicates that you can change your name that makes a socket.io clientToServer call, which in turn makes a PATCH API request for the given user