Finding a place for Heliolisk as a GameDev case study
Side mission 93 in Pokémon Legends: Z-A, commonly searched as “finding a place for Heliolisk”, is a small but instructive quest for anyone who studies open-world design. A man named Trale stands outside Café Soleil with his Heliolisk and asks the player to find an apartment that satisfies a specific, picky set of requirements. The player walks a short route through Lumiose City, climbs a side ladder, and triggers a cutscene on a rooftop that meets every criterion at once.
From a production standpoint the quest is interesting because it compresses several open-world design techniques into a single, low-friction task. It uses a checklist of location attributes as a readable design pattern, it relies on map landmarks as soft wayfinding cues, and it ends with a single, unambiguous “this is the spot” payoff. Reading quests like this with a developer lens can sharpen how a team thinks about side content density, reward pacing, and the difference between busywork and a satisfying micro-arc.
This article walks through finding a place for Heliolisk as a GameDev case study. It looks at the quest’s structure, the design vocabulary it borrows from, the way its requirements double as a natural wayfinding language, the production constraints that shape quests of this size, and the broader lessons about side mission design in open-world games. The goal is to give developers, designers, and technical learners a way to look at a tiny quest and extract reusable decisions for their own projects.
What the player actually has to do in finding a place for Heliolisk
For the player, the quest is short and satisfying. For a developer, that short list of attributes is doing real work. Each requirement is a clue, and together they triangulate to a single rooftop that satisfies them all. The rooftop is the only spot in the immediate area that combines a visible canal, a tower landmark, café access, a Pokémon Center within walking distance, and an accessible climb. A good design pattern in side content is to make the destination feel earned even when the path is short, and finding a place for Heliolisk leans on this heavily.
Why a quest this small is worth studying
Open-world games live or die by the quality of their side content. A campaign can have the best main story in the genre, but if every side quest feels like padding, players drift away from the world. A quest like finding a place for Heliolisk is a clean example of how a small quest can carry its weight without bloating the schedule. The mission is short, the destination is memorable, and the rewards feel tied to the task rather than grafted on as an afterthought.
It is also a useful study object because it is a single-quest quest. There is no chain, no follow-up, no hidden second act. The player accepts a request, walks a short distance, climbs a ladder, and watches a short cutscene that closes the loop. The lack of branching structure means the design choices that remain are spatial layout, landmark usage, and reward pacing. Those are the same choices a developer faces when designing dozens of similar micro-quests, so this one is a tidy reference.
The quest structure at a glance
Even a short quest has internal phases. Looking at finding a place for Heliolisk, the structure maps onto a familiar four-beat pattern. The setup is the request at Café Soleil. The clue phase is the list of requirements. The traversal is the fast travel to Café Gallant and the walk up Estival Avenue. The resolution is the climb up the ladder and the rooftop cutscene. Each phase is short, but each one is distinct in terms of what the player is doing and what the game is asking of them.
The phase model matters because it lets a designer see where the engagement lives. If two phases collapse into each other, the quest feels rushed. If a phase is empty, the quest feels padded. A short quest is forgiving, but a long sequence of similar quests magnifies any imbalance. Designing with phases in mind helps a team audit the experience before they ship dozens of variants.
What the Heliolisk requirements reveal about wayfinding
The list of requirements inside finding a place for Heliolisk is more than a gag about a picky lizard. It is a working wayfinding system encoded as in-fiction dialogue. Each requirement points to a distinct visual landmark: a canal, a tower, a café, a Pokémon Center, a climbable ladder. The player does not need a quest marker to know when they are close because the environment itself tells the story. When the canal comes into view, the tower is on the horizon, and the café tables are visible on a nearby roof, the player has already mentally solved the puzzle before they climb.
This is a useful pattern for any open-world team. A checklist of location attributes does double duty: it tells the designer what the destination must contain, and it tells the player what to look for as they approach. A purely abstract quest marker replaces spatial reasoning with arrow-following. A spatial checklist preserves the player’s sense of place and rewards map literacy. The latter approach is more work, but it is also what makes a city feel like a city.
Landmark density and the cost of a single rooftop
The rooftop in finding a place for Heliolisk has to do a lot. It is the quest destination, the payoff scene, the framing device for the requirements, and the visual centerpiece of the resolution. From a content budget perspective, a single rooftop has to be modeled, lit, dressed with tables and umbrellas, integrated with the surrounding street geometry, and scripted to accept a ladder climb and a cutscene trigger. That is non-trivial work for a side mission, but the cost is spread across the entire district because the same rooftops, cafés, and canal edges appear in many other scenes.
Asset reuse is the silent engine of side content. When a single rooftop can host multiple quests, multiple NPC routines, and multiple camera setups, the marginal cost of a new quest on that rooftop drops to nearly the cost of writing a new request and a new cutscene. The team’s job is to design districts with enough high-value locations that side content can be assigned to them efficiently. Finding a place for Heliolisk is the kind of quest that can only exist in a city built that way.
How requirement lists shape level design
A good requirement list is a contract between the writer, the level designer, and the player. The writer has to phrase each requirement in a way the player can read as a clue. The level designer has to ensure that the destination actually satisfies every requirement. The player has to be able to verify, visually, that the requirements are met. In finding a place for Heliolisk, every requirement maps to a feature in the world: the rooftop is accessible, the tables and umbrellas are visible, the café is across the street, the Pokémon Center is nearby, the canal is below, and the tower is in view. None of the requirements require the player to inspect a UI element or read a tooltip; they all live in the camera frame.
This contract has a cost on the design side. Level designers cannot place quests on rooftops that fail any of the requirements. Writers cannot list requirements that the world cannot satisfy. Tooling can help by flagging quests whose requirements do not match the destination’s tagged features, but the real check is human. A short quest with a short requirement list is the cheapest place to test that the contract holds.
Soft wayfinding versus hard quest markers
Most modern open-world games use a mix of soft and hard wayfinding. Hard wayfinding is the compass blip, the minimap dot, the painted line on the ground. Soft wayfinding is the visual story told by landmarks, lighting, and architecture. Finding a place for Heliolisk is interesting because it is almost entirely soft. The player fast travels to a known café, walks a known avenue toward a known tower, and reads the environment for the rooftop that fits. The hard wayfinding is reduced to a single point on the map.
For developers, the choice between soft and hard wayfinding is a real production decision. Hard wayfinding is cheaper to author and easier to test. Soft wayfinding is more expensive but produces a stronger sense of place. A useful production pattern is to lead with soft wayfinding and fall back to hard wayfinding only when the player has been stuck for too long. Side missions like this one work precisely because they trust the player to read the city.
The ladder as a tiny but important moment
The ladder on the west side of the building is the smallest piece of geometry in the quest and one of the most important. A ladder is a controlled vertical transition. It tells the player that the rooftop is reachable only through this specific path, and it turns the act of climbing into a small narrative beat. The cutscene triggers at the top, which means the player’s last physical action before the resolution is the climb. That sequencing makes the resolution feel earned without adding any mechanical complexity.
For a designer, ladders are a useful case study because they package a lot of meaning into a tiny asset. They are a soft barrier, a permission to enter, a camera framing device, and a moment of vulnerability. They are also cheap to place and easy to script. Any open-world city that wants to encourage rooftop exploration benefits from having a stable library of climbable transitions like ladders, fire escapes, and balcony rails.
Quest density and the silent economy of side content
A city like Lumiose can only carry so many quest destinations before the player gets fatigued. Quest density is the silent economy of side content: every new quest costs the player’s attention, and every new destination costs the world’s believability if it duplicates an existing one. Finding a place for Heliolisk is a good test case because the destination is a single rooftop, and that rooftop is unlikely to be the focal point of another quest in the same beat. The world absorbs the new content because it is a small perturbation on an already-busy district.
Designers planning side content at scale usually build a content budget per district. That budget is a mix of unique destinations, reusable destinations, and pure quest-marker destinations. A quest like this one falls in the reusable category, because the rooftop is also a backdrop for other scenes, but the requirements and the climb are specific to this quest. The mix matters because a district that is entirely unique destinations is unsustainable, and a district that is entirely quest-marker destinations feels hollow.
Rewards and pacing in a side mission of this size
Side missions earn their keep by paying the player back in proportion to the effort. Finding a place for Heliolisk asks for a short walk, a fast travel, and a single climb. The reward, as listed in the walkthrough excerpt, is a small but tangible set of items consistent with the effort. That is a healthy ratio. If a quest this short offered a top-tier reward, it would distort the player’s economy. If it offered nothing, the player would skip it after a few similar quests.
Reward pacing is one of the harder things to tune in open-world games. Designers usually build a reward curve across a district so that the player’s average payoff grows slowly across many quests. A short quest like this one is a useful unit of measurement. If the team can list ten quests of similar length and similar payoff without overlap, they have a working side content loop for a district.
Designing quest requirements that read as clues
One of the most useful design patterns in finding a place for Heliolisk is the way each requirement reads as a clue the player can act on. “Rooftop access” implies a ladder or stairs. “Tables and umbrellas” implies a café terrace. “Near a café and Pokémon Center” implies a main street. “Next to Lumiose Tower” implies the central district. “Near a canal” implies the southern waterway. None of these are abstract. They are spatial attributes the player can verify by walking.
Writers who want to design requirement lists that read this cleanly usually start from the destination, not the request. They ask what the destination already offers in the world, then write a request that calls those features out. The reverse approach, starting from a clever list and then hunting for a destination, tends to produce requirements that are funny but unverifiable. A useful editorial check is to ask whether a player could solve the requirement from a single screenshot.
Quest failure modes and how this quest avoids them
Open-world side missions tend to fail in a small number of recognizable ways. They can be too long, too vague, too repetitive, too disconnected from the world, or too dependent on UI prompts. Finding a place for Heliolisk avoids most of these by being short, specific, spatially anchored, and camera-driven. There is no ambiguity about where to go, and the route is short enough that the player does not have time to lose interest.
The remaining risk is the opposite failure mode: a quest so short that it feels trivial. The design choice that protects against this is the rooftop payoff. Climbing a ladder and stepping onto a sunlit terrace is a memorable moment because it is a vantage point the player does not normally reach. The quest is short, but its resolution is unusual, and that asymmetry is what makes it feel worthwhile rather than trivial.
Comparing side mission structures in open-world games
Side missions in open-world games come in many shapes, and comparing them is a useful way to extract reusable design patterns. Below is a compact comparison of common side mission structures, using finding a place for Heliolisk as a reference point.
| Structure type | Player goal | Wayfinding style | Pacing profile | Best fit |
|---|---|---|---|---|
| Checklist location (this quest) | Find a spot matching a list of attributes | Soft via landmarks | Short, one-shot | City districts with dense landmarks |
| Fetch and deliver | Carry an item from A to B | Hard via quest marker | Short to medium | Rural or low-density areas |
| Defend a point | Hold a position against waves | Hard via objective ring | Medium | Combat-heavy pacing slots |
| Puzzle chain | Solve a sequence of puzzles | Mixed | Long, segmented | Dungeon or shrine content |
| Investigation | Search a wide area for clues | Soft via environmental hints | Medium to long | Mystery or narrative content |
The checklist location structure used in finding a place for Heliolisk is one of the best fits for dense city content because it leverages the player’s existing map literacy. Other structures have their own strengths, but few combine short duration with high spatial payoff as cleanly as this one.
Production constraints that shape micro-quests
Even a quest that takes a player five minutes to complete has a long production tail. Writers draft the request. Voice actors record the dialogue. Cinematics teams plan the cutscene. Level designers verify the destination. Quest scripters wire the trigger conditions. QA tests every step. Localization teams translate every line. Each of those steps is a constraint, and the constraints compound as the team ships more quests. A quest like finding a place for Heliolisk has to be cheap enough to ship at volume while still feeling like a deliberate piece of design.
One of the most effective production patterns for micro-quests is to standardize the structure. If the team agrees that every micro-quest has the same four-phase shape, the same short duration, the same soft wayfinding approach, and the same modest reward band, they can pipeline the work. Writers focus on clue text, level designers focus on destinations, cinematics teams focus on resolution scenes, and QA tests within a stable pattern. Variance then becomes a design choice, not a production risk.
Checklist of reusable decisions from this quest
The task in finding a place for Heliolisk is narrow and well-defined. The walkthrough on IGN’s Pokémon Legends: Z-A side mission 93 page describes the quest as a hunt for a specific spot in Lumiose City that satisfies a long list of must-haves. Trale and his Heliolisk need a place with rooftop access that includes tables and umbrellas, proximity to a café and a Pokémon Center, a view near Lumiose Tower, and a canal nearby. The player is told to fast travel to Café Gallant in Magenta Sector 1, head northeast up Estival Avenue toward Prism Tower, and look at the building at the end of the street on the left. A ladder on the west side of the building leads up to the roof and completes the mission.
Looking at finding a place for Heliolisk with a designer eye, several decisions are easy to lift into other projects.
- Phrase every requirement as a visual feature the player can verify from a single camera frame.
- Lead the player to a known anchor first, then let the environment triangulate the final spot.
- Use a controlled vertical transition like a ladder to mark the moment of arrival.
- Keep the reward band modest and consistent with the duration of the quest.
- Make sure the destination doubles as a memorable vantage point so the resolution feels earned.
- Anchor the destination near two or more named landmarks so the player can orient quickly.
None of these are unique to this quest, but they are applied with unusual consistency. That consistency is what makes the quest feel like a designed object rather than a checklist entry.
How this quest compares to similar apartment-hunting quests
Apartment-hunting and home-hunting quests have appeared in many open-world games, and the pattern is recognizable. A character wants a new place, the player is given a list of must-haves, and the world provides one or more candidate locations. What changes from game to game is the density of the city, the clarity of the requirements, and the quality of the payoff. Finding a place for Heliolisk is on the cleaner end of the spectrum because the requirements are spatial, the city is dense, and the payoff is a single, cinematic rooftop.
A quick comparison helps frame the differences.
| Game | Quest pattern | Requirement style | Resolution payoff |
|---|---|---|---|
| Pokémon Legends: Z-A (this quest) | Apartment-hunt for a picky Pokémon owner | List of visible spatial features | Rooftop cutscene with all features in frame |
| Generic RPG home-hunt | Search for a house to buy | Money plus size or location tag | UI confirmation plus ownership flag |
| Detective-style apartment quest | Investigate a residence for clues | Clues hidden in interiors | Narrative reveal inside the apartment |
The Pokémon version is distinctive because it is a creature-comfort quest rather than a money quest or a clue quest. The player is not asked to afford the place, and they are not asked to investigate it. They are asked to satisfy a picky Heliolisk, which is a softer and more charming framing than the typical apartment quest.
Soft wayfinding and player trust
Soft wayfinding is a contract of trust between the game and the player. The game trusts the player to read the environment, and the player trusts the game to reward that reading with the right destination. A quest like finding a place for Heliolisk maintains that trust by making every requirement a visible attribute. The player never has to wonder whether they are in the right place because every visual cue points to the same rooftop.
Trust is also a pacing tool. When a player trusts the wayfinding, they spend less time staring at the minimap and more time looking at the city. That extra attention is the payoff the city needs in order to feel alive. Side content that supports the city in this way is more valuable than side content that replaces the city with HUD elements.
Common mistakes when designing checklist quests
Checklist quests are easy to write badly. The most common mistake is a requirement list that is too abstract, which forces the player to rely on quest markers and breaks the soft wayfinding contract. Another is a destination that satisfies only some of the requirements, which makes the player feel that the requirements are decorative rather than functional. A third is a destination that satisfies all the requirements but visually buries them, which forces the player to inspect UI prompts to confirm the match.
A useful internal check is to take a screenshot of the destination and ask whether every requirement is visible in the frame. If a requirement is hidden behind a wall, off-camera, or only revealed through a menu, the destination needs more dressing. Finding a place for Heliolisk passes this check on the rooftop because the tables, umbrellas, canal, and tower are all in view at the same time.
What the rooftop scene teaches about resolution design
Resolution design is the part of a quest the player remembers most. Finding a place for Heliolisk earns its resolution by combining two ingredients: a vantage point the player does not normally access and a single visual frame that contains every requirement. That combination turns the cutscene into a quiet tableau rather than a transaction. The player is not just being told the quest is over; they are seeing the evidence in a single, well-composed shot.
For developers, the lesson is that resolution design is about composition. A resolution scene should show the player the result of their effort in a way that requires no extra explanation. When the camera is placed correctly, the destination is the explanation. A quest this short cannot afford a weak resolution, because the resolution is most of the experience.
Quest pacing in the broader open world
Open-world games often use a layered pacing model. There are high-energy quests, low-energy quests, story-heavy quests, and exploration quests. Finding a place for Heliolisk is firmly in the exploration slot. It asks the player to walk, look, and climb, with no combat pressure. That pacing slot is essential, because not every quest can be a fight. A well-paced district has a rhythm that alternates between effortful and calm quests.
Writers planning a quest roster usually map quests to pacing slots before they write. A district with too many combat quests feels exhausting. A district with too many exploration quests feels sleepy. A district that mixes them in the right ratio feels alive. Quests like this one are the calm beats that make the loud beats possible.
Localization and the cost of clever requirements
Every line in a quest has to be translated, recorded, and tested. Clever wordplay that works in one language often fails in another, and requirements that lean on idiom can lose their meaning. Finding a place for Heliolisk is well localized because the requirements are spatial rather than linguistic. A canal is a canal in any language. A tower is a tower. A rooftop with tables and umbrellas is a rooftop with tables and umbrellas. The localization cost is mostly in the requestor’s dialogue, not in the requirements themselves.
Designers who plan for localization usually bias their requirements toward visual and spatial features. That bias also helps international players, who can verify the destination without reading every line of dialogue. The Heliolisk quest is a small example of a broader principle: the cheapest localization is the kind that does not depend on language at all.
Voice acting and the role of the requestor
Trale, the requestor, is the voice of the quest. His tone has to communicate pickiness without being annoying, and his list of requirements has to feel motivated rather than arbitrary. A well-cast requestor can carry a quest that would otherwise feel like a procedural checklist. A poorly cast requestor can sink an otherwise well-designed quest. The walkthrough on the IGN page gives the dialogue enough room to land because the requirements are short and the rooftop payoff is visual.
For developers, this is a reminder that the requestor is part of the level design. Casting, writing, and animation together decide whether the player cares about the destination. A quest that ends on a rooftop with a clear payoff can afford a short, charming request. A quest that ends in a generic room needs a longer, more emotional request to compensate.
Why this quest feels good even on repeat playthroughs
Replay value is a useful test of a quest’s design. A quest that is annoying on the second run usually has a structural flaw, like a confusing route, a slow combat section, or a puzzle that does not respect the player’s time. A quest that still feels pleasant on the second run usually has a strong spatial design, a clear payoff, and a short duration. Finding a place for Heliolisk tends to age well on repeat playthroughs because the route is short, the destination is scenic, and the climb is satisfying.
Designers planning for replay value usually bias toward spatial payoffs. A quest that ends with a new vantage point, a memorable view, or a quiet moment of exploration tends to feel different on every run because the player’s mood and route vary. A quest that ends in a UI screen tends to feel identical on every run. The Heliolisk quest is in the former category, which is why it survives repeat exposure.
Designing a district that can host quests like this one
Not every district in an open-world game can host a quest like finding a place for Heliolisk. A district needs a mix of climbable transitions, visible landmarks, a café or two, a Pokémon Center analogue, and a waterway. The Lumiose districts that can host the quest are the ones that already had those features for other reasons. Designing a district to host quests like this is therefore a matter of investing in features that pay off across many systems, not just one quest type.
A useful checklist for district design includes the following points.
- One or more tall landmarks that can be used for wayfinding and as a visual anchor.
- A network of rooftop-accessible buildings with controlled transitions like ladders or stairs.
- Café or terrace dressing that doubles as quest decoration.
- Service buildings like a Pokémon Center that anchor quest requirements.
- Waterways or canals that give the eye a horizontal reference point.
When those features are in place, a writer can build a quest like finding a place for Heliolisk by listing the features and pointing the player at the building that combines them. The level designer’s job is to make sure at least one such building exists in the district.
Tooling that supports checklist quests
A team that plans to ship many checklist quests usually builds small tools to support them. One common tool is a destination tagger, which lets level designers mark rooftops, terraces, and overlooks with feature flags. Another is a requirement matcher, which compares a quest’s written requirements against the destination’s tags. A third is a route tracer, which verifies that the player can reach the destination from the nearest fast travel point without crossing restricted geometry.
None of these tools are complex, but they reduce the cost of authoring a quest like this one from minutes to seconds. They also make it easier to audit the quest catalog for duplicates, missed requirements, or unreachable destinations. A team that plans to ship dozens of micro-quests in a city will benefit from at least one of these tools.
What this quest teaches about side content density
Density is a question of how much meaningful content a district can carry per square unit of city. Finding a place for Heliolisk is a useful unit of measurement because it is small but complete. It has a setup, a clue, a traversal, and a resolution. A district that can host many of these quests, with overlapping destinations and varied requirements, has a high density of meaningful content. A district that can only host one such quest per area has a low density and will feel empty long before the player runs out of things to do.
Designers usually tune density by looking at the ratio of quests to landmarks, the ratio of quests to rooftops, and the ratio of quests to NPCs. A balanced district has a ratio close to one quest per landmark cluster, with some overlap. The Heliolisk quest is the kind of quest that helps a district reach that balance without dominating it.
Applying the lessons to your own project
For developers, the practical takeaway from finding a place for Heliolisk is a set of small, repeatable decisions. A short quest is a good place to try them because the cost of iteration is low and the lessons transfer to longer content.
- Write requirements as visible features, not abstract tags.
- Lead with a known anchor, then let the environment close the gap.
- Use a controlled transition like a ladder to mark the moment of arrival.
- End on a vantage point that frames every requirement in one shot.
- Keep the reward band modest and consistent with the duration.
- Plan the destination before the request, not after.
These decisions are small, but together they are what makes a short quest feel deliberate. A team that bakes them into their side content template will get more out of every minute of player time, which is the whole point of open-world design.
Limitations and open questions
This case study is based on the public walkthrough of finding a place for Heliolisk and on general open-world design principles. It does not include interviews with the development team, internal design documents, or playtest data. Any deeper claim about the team’s intent, the iteration history, or the comparative performance of this quest against its peers would need additional verification. The article is intended as a designer reading of a public quest, not a definitive account of how the quest was built.
An interesting follow-up question for a future article is how this quest compares, in measurable terms, to similar micro-quests in the same district. Completion time, drop-off rate, and player sentiment are all useful metrics, but they require access to data that is not publicly available. A team with access to that data could write a more quantitative companion piece. For now, the qualitative reading is enough to extract useful design decisions.
Frequently asked questions
Where do you start finding a place for Heliolisk in Pokémon Legends: Z-A?
You start the quest by talking to Trale and his Heliolisk outside Café Soleil, which is located on South Boulevard a little south of Wild Zone 10 in Lumiose City. The quest is registered as side mission 93 once the conversation begins, and the request itself lists the must-haves for the new place.
What are the exact requirements for Heliolisk’s new home?
According to the walkthrough on IGN’s Pokémon Legends: Z-A wiki, Trale’s Heliolisk needs a place with rooftop access that includes tables and umbrellas, near a café and a Pokémon Center, next to Lumiose Tower, and near a canal. The destination is the only nearby spot that combines all of these attributes in a single rooftop.
Do you need a quest marker to find the rooftop?
You can complete the quest with minimal reliance on a marker by fast traveling to Café Gallant in Magenta Sector 1, heading northeast up Estival Avenue toward Prism Tower, and looking at the building at the end of the street on the left. The ladder on the west side of the building climbs to the rooftop where the resolution plays.
What kind of quest is finding a place for Heliolisk from a design perspective?
It is a checklist location quest, in which the player has to find a single spot that satisfies a list of spatial attributes. From a GameDev perspective, it is a useful example of soft wayfinding because the requirements are visible in the environment and the destination is a vantage point that frames all of them at once.
How long does the quest take to complete?
The quest is short. A player who already knows the route can complete it in a few minutes, including the fast travel, the walk up Estival Avenue, the climb up the ladder, and the rooftop cutscene. First-time players may take longer because they will spend time reading the requirements and orienting themselves in the city.
Why is the rooftop important to the quest’s design?
The rooftop is the resolution scene. It is the only place in the immediate area that combines rooftop access, terrace dressing, a canal view, a tower view, and proximity to both a café and a Pokémon Center. Because the rooftop is also a vantage point, it serves as a visual payoff that frames every requirement in a single shot, which is what makes the quest feel earned.
Is this quest a good model for side content in other open-world games?
It is a useful reference for any open-world team designing short side content in a dense city. The design pattern of writing requirements as visible features, leading with a known anchor, and ending on a vantage point transfers to many settings. The exact setting matters less than the discipline of making every requirement a feature the player can see.
What is the hardest part of designing a quest like this?
The hardest part is making sure the destination actually satisfies every requirement without burying any of them off-screen or behind UI elements. A checklist quest lives or dies on the camera frame at the resolution. Designers usually solve this by dressing the destination heavily and by testing the resolution with the camera placed where the cutscene will play.
Does this quest chain into other missions?
Side mission 93 stands on its own. There is no follow-up chain, no second request, and no return visit required. The reward is delivered at the end of the rooftop cutscene, and the quest is complete. This standalone structure is part of why the quest is so useful as a design reference.
What can a player do if they get lost while looking for the rooftop?
Players who get lost can fall back to the quest marker if the soft wayfinding is not clicking, or they can orient themselves by walking toward Prism Tower and looking for a building with a visible canal on one side. The combination of the tower landmark, the canal, and the café signage is enough to triangulate the correct rooftop without external help.
Leave a Reply