Hello everyone, my name is George. I would like to work on card number 195 titled the same as this thread. It says it is a good first task, and I am confident I can complete it.
Edit: Link to the card
https://open.codecks.io/unity-open-project-1/decks/15-code/card/195-allow-multiple-entry-exit-points-in-locations
Will be good to discuss the your ideas before you begin, based on good traditions.
P.S>
I think good style to add to your post the blue mark Official, it can be set after creation thread also.
Creating this post does not âassignâ a task to you, as community work isnât officially âassignedâ to one person. Anyone is allowed to work on a community card to give as many people the opportunity to contribute as possible, so feel free to fork the repository and create your own PR. Excited to see how you tackle this. 
While I can agree that explaining implementation is a good idea, what Iâve seen lately is that forum threads for cards mainly discuss implementation for complex problems and not straightforward first tasks like this.
Like I said in the other thread, @cirocontinisio is the one that usually gives the âOfficialâ mark, and for this particular task, itâs not really necessary because itâs a straightforward âgood first taskâ that shouldnât involve too much implementation discussion.
For example, there was a good first task a little while ago that Ciro shared a video of how to implement in GitHub comments, and no forum thread was created. I waited a few days to see if the people in that GitHub discussion would get to it, and when they didnât, I took a crack at it and completed it without creating a new forum thread saying I would, just a PR when the changes were in. From that experience, it seems to me that âgood first tasksâ arenât meant for collaboration and really just a way to get people the positive feeling of having a contribution to the project to build confidence to help with something more complex in the future.
I do not know how to do the blue mark thing.
It seems from the card they want the player to be moved to a specific spawn point in another scene when triggered.
I was thinking about having a scriptable object represent the spawn points(name, scene name, location, rotation). A simple script would handle the scene change and would take an object as reference. Other scripts(like a trigger volume, dialogue manager, etc) would give that script their point reference and ask it to execute the load. When the scene loads the character controller and camera move themselves to the needed location and rotation.
This is my initial ideas on this, but I expect there to be minor changes as I start working on it(if cleared to do so).
Based on shuttleâs post I am going to start work on this.
For sure, go right ahead and do an implementation. This is supposed to be a learning project, so what better way to learn than by doing?
There have been many people that made their first post ever (like you) to ask to be assigned a task on this project, and without a response, those people havenât been heard from on the forums again. It is great to ask for permission, but on something like this, the worst that could come of someone creating a PR to address an issue âwithout permissionâ is that it doesnât get accepted, but at least that person would have the experience of doing the implementation.
To tell another story, there was a discussion about making it easier for people to contribute on Discord a few weeks ago, and a lot of it was just not knowing that it was okay to try something. The other big thing was just the sheer overwhelming complexity of the project itself, which is why Ciro has been really great at trying to classify tasks as green/yellow/red for complexity. The only way someone new is going to ramp up is to start small, get some easy wins to build confidence, and then who knows, maybe one day soon contribute a bigger feature.
If you are the author of thread, you can edit the thread. In the upper part (in the Edit mode) of your thread will be link Thread Tools, from it you can select the Edit Title of this thread and set thread prefix.
You can get started nothing can stop you, the @shuttle127 (and I ) is very serious :)
But you must know - the main aim of this project itâs a learning the good style Unity programming. Which achieved by discussion different ideas and selection the best (optimal) solution. And if you want, that your realization will be finale realization which included implement all good ideas. Will be good to discuss it, before you spent to it many time, because exist possibility, that somebody give more optimal solution and the Community decide that it more appripriate for this project.
But if you ready to produce âsome prototypeâ which after it will discusse by Community , not spending many your time. itâs also ok.
I hope you see Game Architecture Overview and Event system (from Wiki) which is the base for Scene Loading in this project.
I noticed those things after looking at the code(after I made that post), and I intended to tailor my solution to fit with what already existed. Still thank you very much for showing me to the wiki. That is some very useful information.
Hey @georgefnix , welcome to the project!
I donât think regular users can mark threads as Official, only admins should be able to. Iâll set it as official.
I checked it, Itâs possible now, @cirocontinisio May be good idea to block it and make corresponding note regarding creation of threads for cards from road map
This is great @georgefnix ! Yes itâs a good idea to have a scriptable object to represent a spawn point. We can pass it as a third parameter to the scene loading event we are currently raising when we exit a location. This object would represent the entry point of the location to load. We will then have 2 MonoBehaviour scripts, the exit point one using a trigger (the one we already have) and the entry point one which writes to this scriptable object.
Thanks @cirocontinisio . Sorry for the delay, yesterday was trying to understand the systems and scripts that are already in place and working on a solution that fits within the current systems.
At the moment, but this may change:
The Scriptable Object representing the location(name TDB) is used in a new event the LocationLoader is listening to(I am not going to remove anything that already exists). The location loader does its normal thing, but once all of the scenes are loaded it raises a new event that communicates where to move the protagonist. Either the spawner or the protagonist(TBD) are listening and move to that new location. The exit code will have to be changed to have a parameter that accepts a SO representing location.
Edit: Amel, I read your post. That is very interesting and I will give it thought. I didnât consider the use of scriptable objects in that way.
Currently the loader accepts multiple scenes from an array to be loaded additively. It sets the first element of this array to be the active scene. Despite there being an active scene, it appears the other scenes are still being rendered. In the attached image(which is supposed to be beach) you can see forestâs trees as well as significant z fighting of the ground textures.
I am uncertain how this should be addressed. Either we do not load multiple scenes, or we disable the non-active scene elements(or some similar solution I am yet unaware of).
The other object I am contemplating. I am considering using the locationSO for my taskâs purpose. To wit, I would need to add two Vector3âs to that object. This obviously changes what the SO was initially defined for(to delineate between scenes for menus and scenes for gameplay), but it is exactly descriptive of what the task requires. I was initially going to make another SO with a similar name(ex: localeSO or placeSO), but a designer could easily get confused which SO they need to create. I seek feedback if this matters.
We wanted to allow to load multiple scenes at first because we thought we could have some locations split in multiple scenes. Now that we have a clearer idea of how the game will be like, we will have a scene for every location. So maybe we can remove the ability to load multiple scenes as it is apparently a bit confusing (and especially if we will not use/need it).
It is better if we keep the locationSO and the entrypointSO separated especially considering that one location can have multiple entry points.
Thank you Amel. I made quite a few changes based upon your input especially.
Regardless, this is my PR. It also covers card 197 since that uses the changes to card 195(and it was a small addition to my other work).
Edit: Based on feedback from my original PR I made an updated PR.
It can be found here:
I also made a video demonstrating my PR. It may not be done processing by the time you see this.
Quick reply after first look:
You use term the Location for points of spawn on scene? Itâs not good, because currently âthe Location in Editorâ itâs a some special type of SO.
IMHO it is more appropriate to change his name to something else - Scene point / spawn point and that kind of thing
It isnât just points of spawn on scene. It is points in a scene that can be used for anything including spawning a character(or teleporting, or whatever). For example, if an npc wants to walk to the clocktower they could query that location and begin pathing. In my opinion, in the context of video games a scene could represent a location, but in many cases it would represent an area(that has locations, ex: a town that has a market, bank, bridge, etc).
If it is important to the team I am not completely opposed to changing the names of the scripts.
Currently:
Scenes are represented by SceneSO
Locations in those Scenes are represented by LocationSO
If SceneSO is to be changed to LocationSO. Then LocationSO should be named something that isnât a synonym of location(like place). PointOfInterestSO or PointSO would be my suggestion.
Update: I am in the process of changing them to my second suggestion(which happens to be one of DSivtsovâs and is more general). It is a longer task then I originally envisioned as I have more to rename than the classes.
Update 2: Changes made. All instances(I could find) of Scene is now Location, and every Location is Point.
After reading the other thread(about card 197) and some thought, I have decided to remove my request to merge. The other card is closely related to this one(that is why a two additional scripts to 195 solved 197 for me), and because I changed aspects of how things were structed I feel like my solution steps on too many toes.
I do not regret this at all. I learned a lot, especially that I need to improve my communication. Thank you all. I will probably be back at some point with an improved process.
I took yesterday off, and with that time I realized that I still understand this problem well and I can contribute in a way that doesnât mess with the way things are done. In this pull request I tried to change as little as possible.
Pull Request: Multiple Entry/Exit by georgefnix ¡ Pull Request #275 ¡ UnityTechnologies/open-project-1 ¡ GitHub
PS: Thank you for the likes and responses to this thread.
