Closed JStrebeyko closed 4 years ago
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:
/dev/rocks_talk
; 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.What do you think about that?
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:
/dev/rock_talk
;rock_talk.json
data resource along with typecasts and useful functions for retrieving data;RockTalkPage/index.vue
component to be served under /rocks/:id
(more on that in a second); 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:
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!
.vue
component in the place of the rocks if it is registered using customOverlaysList
object (there is one dummy example)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!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.
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 appropriateSpeechBubble
instances. Additionally, it acceptstype
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 regularHTMLDivElement
, 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'soverlay
).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
.hint
'sfont-size
for consecutive breakpoints or the vertical distance of the tooltip from the graphic.