Inter level overlay

[JStrebeyko]

What it does

1) introduces <InterLevelOverlay> :stars:

The commit introduces the component to be shown in between levels, accepting the familiar Hint[] as props to create appropriate SpeechBubble instances. Additionally, it accepts type prop tightly coupled with the kind of graphics we have.

2) refactors <SpeechBubble> :building_construction:

For the overlay component to work, namely for it to be flexible, accept texts of different lengths and be up for CSS styling, I had to refactor the <SpeechBubble> component. The one we had had two major flaws:

A) <foreignObject> is difficult to work with and introduces SVG quirks into the already complex CSS / JS styling mix;

B) the component was incorporated into the SVG flow, and as such it must have been bound to the (board's) borders. Having it anywhere higher there meant introduced a class of nasty edge-cases and hard to manage fitting/resizing issues.

Now, the component (which should be renamed to Tooltip, but I'm leaving it for another PR for simplicity) is a regular HTMLDivElement, allowing us to use it anywhere we want, style it however we prefer and so on. It gets absolutely positioned depending on the context (board is default and there's overlay).

3) stubs global .scss :art:

During work it appeared to me that we handle responsiveness very poorly, mostly through arbitrary hard-coding width values and scaling down SVGs. Also, many of the re-appearing colors are being hard-coded. For standardization purposes and to open up discussion, there are some small style assets added, one with colors and one with the most common breakpoints for media queries. I used them in my work, hopefully some will use them, in theirs, too.

4) creates /dev/rock_talk page for feedback :mag:

I prepared a little demo page to easily interact with the overlay's properties. After switching to the branch, hit http://localhost:8080/rock_talk to play with them. Considering the upcoming presentation, feedback would be nice. Of course, unless some other issue finds the page useful, it should be deleted from the production build.

~What it doesn't do~

~The PR does not actually connect the overlay to the game-flow to save one from doing unnecessary work. There are important questions to be answered first, the most important one regarding how the overlay data should be stored in relation to the levels.~

[UPDATE] It puts the example overlays into the game flow! see discussion below

implementation notes

• besides the main functionality, there is a number of "soft tweaks" that probably should be applied after the initial feedback. They regard for example the exact graphics' size within the overlay, the .hint's font-size for consecutive breakpoints or the vertical distance of the tooltip from the graphic.

[stared]

A lot of good work! I think it is nice to develop things that way, so it is possible to check stuff before incorporating it in code. Good idea!

Did you test in on the phone, if it works?

If it works, I suggest going for the following:

• I suggest leaving the example accessible at /dev/rocks_talk;
• A single file rocks_talk.json with a list (array) of all dialogs, and with ids (I guess let's use strings for later use).
• /rocks/:id path for rock dialog (only the window), so to make it easily sharable.
• For now, when a level is won, after congrats, we link to the rocks talk board.

What do you think about that?

[JStrebeyko]

Hi there, @stared !

I checked it on phone and it works, although could use some soft-tweaks to ensure the tooltips do not overlap - I think it is a minor thing and can be fine-tuned on the next step.

I generally agree with the suggestions and my following commits incorporate their implementations. The only thing I did differently was calling the functionality rock talk (singular), just because it rhymes :notes:

Anyways, the upcoming commits do the following:

• move overlay playground to /dev/rock_talk;
• create a rock_talk.json data resource along with typecasts and useful functions for retrieving data;
• create the RockTalkPage/index.vue component to be served under /rocks/:id (more on that in a second);
• incorporate the testing overlays into the gameplay :fire:

:thinking: how does this work now?

1) In the @assets/data/rock_talk/index.ts there is an object called postLevelOverlayMapping - it lists the levels after which there should be overlays shown. :video_game: 2) The GamePage checks the mapping and if there is an overlay assigned to the current level, it substitutes the "confetti-you won" next level button link with appropriate overlay link (changed it from nextLevel to nextLevelOrOvelay); :fast_forward: 3) Upon clicking, the overlay gets displayed. In case there is no custom component registered, the overlay defaults to displaying rocks - it consults the rock_talk data using getRockTalkById() function. :moyai: 4) As of now there is a Next Level button on the bottom of an overlay, sending the user to the next level. :star2:

:left_right_arrow: test it!

There are three example overlays, one after each of the first levels. Simply finish level or push the "next level" arrow by the level's title and see how game flow gets redirected onto the overlay pages!

:notebook: notes

• For flexibility purposes the main component can display a custom .vue component in the place of the rocks if it is registered using customOverlaysList object (there is one dummy example)
• The overlay component offers a stub of a title functionality (self-explanatory I guess), not fully implemented - would like to discuss feedback and learn the team's desires first. Of course, some styling (and perhaps even route-view transitions? :heart:) could also do magic here!

[JStrebeyko]

Thanks for the remarks.

• As of code in assets - I totally agree. I did it like that because we do include the typecasts and the retrieving functions there for all the other asset types (levels, entries). :arrow_right: I am moving the file to the /RockTalkPage directory, which should simplify things. PR: https://github.com/Quantum-Game/quantum-game-2/pull/177

• When it comes to the global style sheets, they are considered static assets wherever I looked (1, 2, 3) :arrow_right: I am updating the webpack config with a sass-loader option to automatically prepend them, so they do not have to be imported per component using the @import rule. PR: https://github.com/Quantum-Game/quantum-game-2/pull/176

• <SpeechBubble> uses the wrapperRect dimensions to position itself completely relatively to it, with no hard-coded distances. It means that they will be always in the same position regarding the wrapper, no matter its size. The trick will be to have the tooltips of correct size using media queries.