Travel scene

[GillianYue]

86

1. research on map & colliders in 2D rpgs, what kind of data it should be and else - done

2. camera/navigation - see 86, experiment with and pick an option - done

3. scene logic, I'm pretty sure it can't be linear anymore, but what exactly? Better whip up a test scenario real quick to see what generally works best.

[GillianYue]

And it's looking like we've got some major code refactoring to do. I'm inclined to make GameFlow a script that only deals with line-based logic, and move things like loaders and canvas and dialogue boxes to their own new scripts. That way it's a matter of "in this scene we're using script a, c and d" and the scripts will be more in charge of only their specialized things and be calling functions from the other scripts if need be. Tbh, this is more important than shoving more functionalities into the current code base

[GillianYue]

1. We could use composite colliders to combine boxes and polygons attached to that GO (check the Used By Composite checkbox). In other words, for each map I should manually add in colliders, which is fair because I can't really expect this to be any more automated

As for the size of the map, I think just make sure the natural image size fits the scale of other sprites. Question is, how do we store the colliders? Having ready-made background prefabs and load them in? --> might not need to load in images anymore, but the entire GO --> better have both available as custom events

[GillianYue]

3. Segmented out gameFlow's code in gameControl update() using a boolean switch. Currently, it thinks we're either using csv files or in the travel scene.

TODO: think about setting up travel scene when gameFlow is no longer in the picture. We could do something similar to ivs load, but during Start() or Awake() (eventually this will need to happen during the official loading of the scene, but for our purposes right now loading on start would work

[GillianYue]

The 2D colliders are not colliding at the current moment, and the cause is unknown. I thought it was the way we updated player's position in nudge(), but changing it to force based didn't fix the issue.

Turns out, isTrigger should be unchecked for player's capsule collider. & yes, the previous way of updating position bypasses colliders, so we gotta switch to force based movement - not

[GillianYue]

2. Camera should follow player's movement, along with icons on the canvas + background mask.

That's set up. Now another thing is that we don't want the camera to move beyond the walls (to reveal spaces beyond the edges of the background). In other words, say we're moving up and reaching the top edge of the background image, we want the camera to stop following player even if the player keeps going up (player will stop once hitting the natural wall collider, but camera should stop even earlier, and the relative dist is half of cam view's width or height. Does that mean we should do raycast checking for camera as well?

[GillianYue]

CSV files for travel scene background setups; first line has the name of the prefab of background that will be loaded in resources. I added a travelSceneManager script that does the loading assuming assigned CSV and certain GOs. Now the only missing link is to "set" that assigned CSV in travelSceneManager during LoadScene --> this is a later job

at this point 1 is pretty much fully addressed, should move on to 3 if we're not missing anything

[GillianYue]

3.

Aside from BG which is constant (for now), the first thing that comes to mind is the placement of NPC/interactable items. There are obviously a set of things that are always interactable, but also ones that are dependent on time (e.g. only appearing in night) and conditions (special event NPCs, NPCs that only show after reaching certain status, etc.) Time is relatively simple, conditions more messy because of how many kinds there could be, and it's impossible to predict all at the current moment anyways

Things to consider:

• how to avoid conflict; should I have a clear picture of what each scene should look like at any point in the game, or should I allow some randomness and flexibility

• data format. As said earlier I don't think csv works anymore for this much complexity. We need a format that can clearly pinpoint the time, location and condition for something to show up, what happens when player interacts with it, what variables these interactions would affect, etc.

• what the data flow should be between scene and quests - this of course needs a proper quest saving mechanism

[GillianYue]

see #98 for discussion on quest data format

characters & NPCs are more complicated though, because the dialogues, events and interactions are not on a complete/incomplete basis. The same character can have various sets of dialogue under diff conditions, so how should we store all these, making sure that I can write with ease and clarity?

Tbh tho, I call it dialogue, it's more like mini code blocks of logic. Hmmmmm.

Postponed! Can't think of a proper solution, need more rumination