Alternative picked instances list

[D8H]

Abstract

Context

• A user wants to use 2 subsets of an object to check a condition or apply an action with 2 arguments of the same object.

Actual

• There is no mean to have 2 subsets of picked instances.

Expected

• Allow to have 2 subsets of picked instances somehow.

Use case 1: Grids with links

Context

• In my case, I would like to link 2 instances of the same object to build a grid.

Actual

• I use 2 objects: GridElement and GridElementLink. GridElement are the actual displayed objects and GridElementLink are hidden clones of GridElement.
• This allows to use the link action to build the grid, but it results to this sort of abominations:
  
• If you want to know more about this case, take a look at http://wiki.compilgames.net/doku.php/gdevelop5/all-features/extensions/linked-objects-tools

Expected

• Be able to link 2 instances of the same object

Use case 2: Procedural generation

Context

• There was a user that wanted to make procedural generated lakes and outline them with squares of mud so he needed to check that a water square was not surrounded by water.
• For each water square, he tried to check if its 4 neighbors were water to turn it to mud.
• I gave him wrong advices. Because, at the time, I thought that group picking was independent from object picking (I heard this advice before, used it and though it worked for the wrong reason).

Actual

• His solution didn't work because the 1st object was Water and the neighbor was Water too.
• No one could help him on Discord and I don't see him around anymore.

Expected

• Be able to write a condition between 2 instances of the same Object.

Solution brainstorming

• Do you see some cases where having several subsets for an object could be an issue?
• To make it works with group, technically, I think it would be like an alternative picked instance list. So, picking on an alternative group will pick on objects of the same alternative subset.
• Should it be limited to one alternative subset?
  • If not, do you think it should be defined beforehand likes groups or on the fly?

[4ian]

Do you see some cases where having several subsets for an object could be an issue?

Not really... if we had support for "asynchronous" actions in the future (actions that "stop" and let other actions and sub events continue later when it's done (like a web request)), we'll have to restore the context of the object lists and the additional object lists. And remove from them the deleted objects. But that's it.

To make it works with group, technically, I think it would be like an alternative picked instance list. So, picking on an alternative group will pick on objects of the same alternative subset.

Correct. I think groups can contain "alternative lists" (and so become "alternative" groups, though it really depends what you put inside).

Should it be limited to one alternative subset?

Possibly not, at least I don't see a reason for limiting to a single alternative if we do something.
I imagine we could define "alternatives lists" in the events sheet. Let's do a quick recap of groups first:

Recap about Object Group

Currently a group is a way to refer to multiple objects at the same time. In other words, if a group "MyGroup" contains "Player, Enemy, Item", an action like
"Set X position of MyGroup to 100"
is almost exactly equivalent to 3 actions:
"Set X position of Player to 100", "Set X position of Enemy to 100", "Set X position of Item to 100".

This is also the reason why groups can't be used to have "alternative lists": they are just a synonyms for referring to multiple list of objects.

Recap about object lists

It's important to note that all conditions and actions are working with lists of objects.

• A condition is filtering a list of objects. When you do "Player X position < 100", the condition generates code that iterate on all instances inside the "Player" list, and remove the one failing the condition (by checking the return of a function call).
• It's important to note that these lists of objects are either:
  • Created and filled with all the objects of the scene, if the object was never mentioned.
  • Otherwise, inherited/reused from the previous condition (or action, or parent event).
• An action is basically iterating on the objects. When you do "Set X position of Player to 100", it's translated into code that will call a function for all instances inside the "Player" list.
• Object lists are also:
  • "scoped" to their event. When you go to another event, you start again from the lists that were inherited from the parent event (or from nothing, for top level events).
  • there is also a way for actions/conditions to declare that they want a object list but without filling the list in case it's not used yet. This is the case of the Create object action.

That's pretty much it.
For now there is a 1:1 mapping : 1 object name in an event = 1 object list.

Potential solution: The alternative lists of objects

While groups are just "synonyms" for more than one object, "alternative lists" are, as the name implies... lists of objects.

So they actually still linked to an object, but are separated. For example you could do:

Alternative list: "OtherEnemy" is a list of "Enemy" objects.
Condition: "X position of Enemy < 100"
Condition: "X position of OtherEnemy > 100"
Action: "Turn Enemy toward OtherEnemy"

and this will turn all enemies that are on the left toward the (or at least, one of the) enemy that is on the right.

The question is now where we should declare these alternative lists.
I think it would make sense to have them similar to groups, i.e: declared for a whole scene. It might be possible to think about having these lists "scoped" to an event, but that's also more work on the events code generation.
EDIT: actually, it would make potentially a lot more sense to have them declared at any point in the events, so that you can "copy" the objects in a list, and make it in another list.

[Silver-Streak]

I wonder if a lot of this can be solved with more control over object picking. We've had a discussion around this on the forums in the past, in that these issues aren't unique to GDevelop, but in GDevelop we do not have Pick Nth, Pick based off Z order, etc.

https://forum.gdevelop-app.com/t/more-pick-conditions-for-object-selection/29410

As far as I can tell, object instances always generate in the same order, and I think the "First" instance would always be the initial object activating the condition (or the first one on the list, etc), and the rest of the order would be the natural object list that occurs.

[Silver-Streak]

Also, we really need an option to "Unselect" because of how the "Number of Objects" condition and "Count()" expression pick all objects, without the user realizing it will.

[Bouh]

Picker selection is a problem with raycast, if we want launch a raycast between two instances of the same object, the raycast takes into account the instance of the "sender" and returns the first instance. If Pick nth is added, it can solve this problem.

--

Le sélecteur est un problème avec raycast, si nous voulons lancer un raycast entre deux instances du même objet, le raycast prend en compte l'instance de l'émetteur et renvoie la première instance. Si Pick nth est ajouté, cela peut résoudre ce problème.

[Silver-Streak]

@4ian I'm working on a quick Point-and-click adventure template/example to submit, and realized that without the ability to "Pick highest/lowest Z order" (and to a lesser extent, Pick Nth), the conditions are going to be relatively unoptimized (either with each object needing to be called out specifically, or with a lot of "This object group but not this object group" style conditions).

Has any conversation/thought/etc happened around more object picking (and unselect) options?

[D8H]

I'm not sure if that can help, but the Draggable behavior takes the highest z-order of its object instances.
Is it in case a character moves over an interactive object? When the interface overlaps interactive objects because of scrolling?

[Silver-Streak]

For Point and click games, there's actually quite a few instances where higher/lower Z-order is important:

• For game similar to King's Quest or Day of the Tentacle, you can look at a hotspot item but can also look at the background. This means without "Highest Z order" picking, to avoid conflicts when "looking at" something (identifying if it's the background or the hotspot item), you will need two events: One for "Cursor is over Background AND Cursor is over hotspot item (inverted)", one separately for "Cursor is over hotspot item" With "Highest Z order" everything can be in the hotspot object group and you only need one event.
• For games similar to Myst, you can have hidden hotspot objects behind the "background" that you're supposed to be able to click. But you can run into conflicts with trying to interact with it instead of the background (almost the inverse of the above)
• For any type of adventure game, if you're trying to combine items or have them interact with each other, without being able to "Pick Nth" or "Pick lowest" you're going to have a hard time selecting between two inventory items in the same group.

There are workarounds for some of these, but they're pretty messy vs pick highest/lowest/specific Z order, pick Nth object (this one may be hard as the user won't see the object IDs, but it is a pretty standard function in other engines). Pick Next object (eg: don't pick the first object initiating the condition) would be helpful as well.

Hopefully this helps add some clarity.

[D8H]

Possibly not, at least I don't see a reason for limiting to a single alternative if we do something.
I imagine we could define "alternatives lists" in the events sheet.

What I meant by only one alternative is a global picked instances list alternative. For instance, with TurtleEnemy and MushroomEnemy objects and Enemy group, there would be TurtleEnemy (other), MushroomEnemy (other) and Enemy (other). Picking Enemy (other) would pick TurtleEnemy (other) and MushroomEnemy (other).

I ask this because it's hard to see how global list alternatives could be named by users. And if alternatives should not be global, I don't see how groups could work.

Moreover, I don't see cases where 3 picked lists for one object could be necessary.

actually, it would make potentially a lot more sense to have them declared at any point in the events, so that you can "copy" the objects in a list, and make it in another list.

To adapt this to dual global picking, it could be an action like "Make _Object_ picked objects for both picking sets".

[4ian]

I ask this because it's hard to see how global list alternatives could be named by users

If you need a second list of objects, you must have a reason and the name should be that reason :)
For example, can be something as simple as "OtherTurtleEnemy", but it would rather encourage a good naming like "AlmostDeadTurtleEnemy", "MovingTurtleEnemy", etc... according to whatever conditions you're using on them.

I'm also a bit afraid the "Enemy (other)" could be read as "other enemies, so the enemies not picked by conditions". I.e: the opposite list of "Enemy". Which is not the case, it's just a different list (that can contain or not the same objects).

Moreover, I don't see cases where 3 picked lists for one object could be necessary.

It's hard to imagine indeed, but I believe if there is a way to have a "other" list, then people will want a "other other" list, etc...
Though I don't have an immediate good example coming to my mind. Just a feeling that it's either one object list, or any number...

[4ian]

Maybe an example in the case of procedural generation, you could want to check the Cell objects that are adjacent to a Cell (so you need a For Each on the Cell object, then get the neighbouring cells using a second "NeighbourCell" list), and then also check the Cell objects that are adjacent to each of these (so you get the neighbourings cells of each "NeighbourCell" into a 3rd list "DistantNeighbourCell")?

Might not be the best example (or make sense as an algorithm), but still something that could be useful?

[D8H]

I like the ideas of naming and generalization and if there is a way to make it easy to understand it will be really great, but I'm afraid of how groups will work with this.

For instance:

• Define OtherEnemy from Enemy
  • Enemy is in collision with OtherEnemy
    • --> TurtleEnemy do something
    • --> MushroomEnemy do something

TurtleEnemy is the Enemy or OtherEnemy?
Here, a union of OtherEnemy and Enemy seems more logical but I don't think it will always be the case.

[4ian]

That's a good question, seems like handling groups can indeed be a headache.

To answer to your question using the current logic:

TurtleEnemy is the Enemy or OtherEnemy?

The content depends on what is inside the "Enemy" group.

• If "Enemy" group contains "TurtleEnemy", then any manipulation of "TurtleEnemy" will only apply to those previously filtered by conditions made on "Enemy".
• If "Enemy" group does not contain "TurtleEnemy", then "TurtleEnemy" was never seen before in the event so it's using all the "TurtleEnemy" from the scene.

But, according to the logic I was suggested at least, one thing is sure: OtherEnemy is an entire different list of objects, so "TurtleEnemy" is not linked to it.
It will apply to the TurtleEnemy, whatever you did with OtherEnemy.

The thing to understand here is that "OtherEnemy" is a list. It's a new name, it's separated from MushroomEnemy, TurtleEnemy, etc... it's now considered as separate. So whatever you do with the other lists won't impact it.

[D8H]

Using this example again:

• Define OtherEnemy from Enemy
  • Enemy is in collision with OtherEnemy

In this case, it will be problematic because each instance is in collision with it-self so all instances will always be picked.
Does it mean that only "for each instance" should be able to name a picked instance and that the instance of the iteration is excluded from the picking for this iteration?

N nested loops would allow to have N independent named instances and use them in conditions and actions with the remaining instances without any conflict.

[4ian]

In this case, it will be problematic because each instance is in collision with it-self so all instances will always be picked.

I don't think it's problematic, conditions operating on multiple object lists (using twoListsTest at least, like the collision test, distance test), have a check to avoid testing the same object:

GDevelop/GDJS/Runtime/events-tools/objecttools.ts

Line 108 in 80ddc9c

arr1[k].id !== arr2[l].id &&

Does it mean that only "for each instance" should be able to name a picked instance and that the instance of the iteration is excluded from the picking for this iteration?

I'm not exactly sure about your question, but in theory these nested loops should work.

The way For Each event work is that it takes the content of the object list you specified, and repeat the event for each instance in the object list (meaning that for each iteration, the object list contains a single instance - but the name is unchanged).

For example, we could maybe do:

• Condition: Enemy variable "active" = 1 (let's say that we're interested only in "active" enemies)
• Actions: none
  • Sub event: Define OtherEnemy from Enemy
  • For each Enemy:
    • Comment: Here the "Enemy" refers to the single enemy of the "for each" iteration
    • Comment: But OtherEnemy still contains the entire list of "active" enemies
    • For each OtherEnemy:
      • Comment: Here the "Enemy" refers to the single enemy of the FIRST "for each" iteration
      • Comment: Here the "OtherEnemy" refers to the single enemy of the SECOND "for each" iteration

N nested loops would allow to have N independent named instances and use them in conditions and actions with the remaining instances without any conflict.

Yes I think so.

[tristanbob]

(Below was copied from discussion #2748.)

Is it correct to say that one weakness in GDevelop is that it is impossible to control interaction between instances of the same object? When using ForEach, you can only reference the instance that is currently in the loop. Can we think of a way to allow referencing other instances of the same object?

I ran into this problem with my Physics Chains extension. I had to use two different objects that connected ObjectA to ObjectB. I could not make an event that connected InstanceA to InstanceB.

What if we make a new Action that saves the currently picked instances with a Name that can be used later? (This Name functions as a temporary Instance Group.)

<previous code assigns an "ID" object variable to every instance>

EVENT:

• Condition: MyObject.Variable(ID)=1
• Action: Picked instances of "MyObject" can be referenced as "FirstInstance"

EVENT:

• Condition: MyObject.Variable(ID)=2
• Action: Picked instances of "MyObject" can be referenced as "SecondInstance"

EVENT:

• Condition: Distance between "FirstInstance" and "SecondInstance" is less than 10 pixels
• Action: Put "FirstInstance" around "SecondInstance" at a distance of 10 pixels and angle 0.
  Would this idea be helpful? Is there a better way to provide this functionality?

[tristanbob]

I think my idea of a dynamically assigned "instance group"...

Action: Picked instances of "MyObject" can be referenced as "SecondInstance"

...is functionally similar to what has been discussed above as:

Define OtherEnemy from Enemy

Am I correct in that conclusion?

[4ian]

Yes I think so! That's almost exactly if not the same idea.

[tristanbob]

I've been brainstorming this some more. I think it would be useful to offer multiple actions to manipulate these "dynamic object groups".

• Add matching objects to dynamic object group _______. (If the instance already exists in the dynamic group, no action is taken)
• Remove matching objects from dynamic object group _______.
• Remove all objects from dynamic object group ______.

These actions will provide a lot of flexibility to create a curated list of instances.

I also like the wording "dynamic object groups" because they can be used just like normal object groups in conditions and actions. The only difference is how they are created and populated (using Actions instead of statically defining them in the scene editor).

[D8H]

I'm not sure to follow. Can you illustrate the 3 actions with a small example?

[tristanbob]

Since Fog of War is what I'm currently trying to implement, I came up with an example that benefits from dynamic object groups. I believe this identifies a secondary purpose of dynamic object groups; reducing the number of objects to process. This should improve performance when working with very large quantities of object instances.

# Assume a scene that includes 200 units and a 100x100 grid of FogObjects (10,000 objects).
# FogObjects are solid black sprites on a layer above the terrain and units.
# Since their default opacity is 255, they hide everything at the start of the scene.

# Hide fog when units get near
ForEach("Unit")
 Condition: Distance Between "Unit" and "FogObject" < DetectionRadius
 Condition: "FogObject" opacity > 0
 Action: Set "FogObject" Opacity to 0
 Action: Add "FogObject" to dynamic object group "HiddenFog"

# Slowly bring fog back to 128 when units move away
# Because this dynamic group only includes recently seen FogObjects, 
# it should be much less than 10,000 objects.
ForEach("HiddenFog")

 Condition: Distance Between "Unit" and "HiddenFog" > DetectionRadius
 Action: Increase "HiddenFog" Opacity by 1

 Condition: "HiddenFog" opacity >= 128
 Action: Remove "HiddenFog" from dynamic object group "HiddenFog"



# Side note: If I didn't have a way to reduce the number of fog objects to check, I could do this:
Condition: UpdateFogTimer > 1 second
 ForEach("FogObject")

  Condition: "FogObject" opacity < 128
  Condition: Distance Between "Unit" and "FogObject" > DetectionRadius
  Action: Increase "FogObject" Opacity by 1
  Action: Reset UpdateFogTimer

Video

NO1Pw8ZNjQ.mp4

[D8H]

Thank you for the example, it's very clear (and really cool).

I wonder if this kind of optimization should rather be done by the engine directly. It seems hard to implement but the picking is an important part of the engine so I think it makes sense to optimize it.
The engine could decide to maintain a list of instances that match the conditions. Maybe based on the number of instances, the condition evaluation frequency...

[4ian]

I think this is a discussion about two different (even if potentially related) features:

• Alternative picked instances list would be there to give a bit more control on picked instances. It solves the issue of "I cannot distinguish easily between two objects having the same name" or "I want to remember some objects using a different name". In other words, this is about giving a synonym to an object name.
• While this is about remembering a list of objects to avoid always restarting at every frame from "all" objects (which is useful when there are thousands of them). In other word, this is about remembering, potentially for another frame, a dynamic list of objects.

(Side note about optimization:

• For optimizing a frame, you should have in your "top level" conditions something like "Condition: Distance Between "Unit" and "FogObject" < DetectionRadius', and then do everything in sub events. This being said, it's true that for HiddenFog there is no easy solution right now, apart from using a variable "IsHidden" and using a condition "Variable IsHidden of FogObject is true", at the "top" of the conditions (and only once! To avoid going through the thousands of objects multiple times a frame).
• Note also that in the future, the engine will optimize conditions like collisions, distance check, etc... to use "spatial hashing/partioning" to quickly find instances around another. As such, DO NOT USE "for each" if it's not needed. It would remove the optimization, as it would force to iterate on all instances).

)

So we could have two things:

1. An action/special event/something like Define OtherEnemy from Enemy - this creates a second list of picked objects "OtherEnemy". You can now refer to these objects as "OtherEnemy", and do conditions on them to filter this list, without impacting Enemy.
2. A set of actions that you described:

• Add picked "Enemy" to dynamic object group called "EnemiesSavedForLater" (If the instance already exists in the dynamic group, no action is taken)
• Remove "Enemy" from dynamic object group "EnemiesSavedForLater".
• Remove all objects from dynamic object group "EnemiesSavedForLater".
• Consider all "Enemy" objects saved in "EnemiesSavedForLater" (this loads the saved instances)

See how in the second set of actions/conditions, I need to specify which objects I'm saving (or "loading") from the group.
This is because we can't just say "Add matching objects to dynamic object group" => which objects? All? Even if these are things unrelated like the "Cursor" object (because you ran an action to check if "the Cursor is on an Enemy").

This shows that the two features are different, because I could also do something like:

• Add picked "OtherEnemy" to dynamic object group called "EnemiesSavedForLater".

Is this making sense? I have the feeling we're into something, but it's still a bit fuzzy.

[tristanbob]

I think this is a discussion about two different (even if potentially related) features:

I agree that we are talking about two different benefits:

1. Allow instances of the same object to reference each other in conditions and actions.
2. Increase performance by reducing the number of instances to process

Can we not provide both of these benefits with dynamic object groups? Your example of Define OtherEnemy from Enemy could be done with an action that adds all instances of an object to a dynamic group.

See how in the second set of actions/conditions, I need to specify which objects I'm saving (or "loading") from the group.
This is because we can't just say "Add matching objects to dynamic object group" => which objects?

Thanks for explaining this. I agree that the dynamic group actions will need to specify the objects that are being added/removed from the group. See below:

• Add picked/selected/matching "MyObject" instances to dynamic object group "MyDynamicObjectGroup"
• Remove picked/selected/matching "MyObject" instances from dynamic object group "MyDynamicObjectGroup"
• Remove all objects from dynamic object group "MyDynamicObjectGroup"

"Consider all "Enemy" objects saved in "EnemiesSavedForLater" (this loads the saved instances)"

Can we not simply treat dynamic groups like we do normal objects and object groups? The format above is similar to object linking, but if possible we should make this work the way users are most familiar with.

Note also that in the future, the engine will optimize conditions like collisions, distance check, etc... to use "spatial hashing/partioning" to quickly find instances around another.

This is cool!

As such, DO NOT USE "for each" if it's not needed. It would remove the optimization, as it would force to iterate on all instances).

Thank you for this instruction. I have not been diligent in try to make things work without ForEach(), but I will now only use it when absolutely necessary.

Is this making sense? I have the feeling we're into something, but it's still a bit fuzzy.

Thanks for discussing this, I do think these ideas will add a lot of value to advanced GDevelop users.

Related idea: I thought I came up with a clever trick. Create a dummy object that is only used to link with other objects. This will function as a quasi instance list that can be used to reduce the number of instances to process. However, I was not able to make this work as I expected.

BTW, here is the code that works similar to my video. As you can guess it is very laggy due to checking 10,000 FogObjects every frame.

[tristanbob]

I discovered today that the order an instance was created determines how "powerful" it is in "separate two objects" (when used on the same object type). Instances can only move instances that were created before themselves. This means the first instance created cannot move ANY other instances, and the last instance created can move ALL other instances. As you can guess, this will cause a frustrating experience in an RTS game.

This problem could be solved if we had the ability to assign "selected units" to a dynamic object group.

#  Manage membership of the dynamic groups
Condition: Object.Variable(Selected)=TRUE
Action: Add picked instances of "Object" to dynamic object group "SelectedUnits"
Action: Remove picked instances of "Object" from dynamic object group "NotSelectedUnits"

Condition: Object.Variable(Selected)=FALSE
Action: Add picked instances of "Object" to dynamic object group "NotSelectedUnits"
Action: Remove picked instances of "Object" from dynamic object group "SelectedUnits"

# Seperate objects logic
Condition: (always)
Action:  Move "NotSelectedUnits" away from "SelectedUnits" (only "NotSelectedUnits" will move)

vv39RRKAbT.mp4

[tristanbob]

We probably have enough use-cases defined to help guide the development of this feature, but I keep running into instances where I could benefit from dynamic groups. Building an RTS with hundreds of units interacting with tens of thousands of terrain tiles has really made it easy to identify CPU bottlenecks. This forced me to design scalable relationships by using a 2D array that units and terrain interact with.

The reason I need dynamic groups today is to select objects that have moved since the last frame, so I only update vision on those instances.

Remove all instances from dynamic group "HasMoved"

ForEach("MovingUnit")
   Check if "MovingUnit" is on the same tile as last frame
   If not, add "MovingUnit" to dynamic group "HasMoved"

ForEach("HasMoved")
   Apply vision around "HasMoved" objects (Requires calculating distances in the 2D array)

Without dynamic groups, I can only check if ANY moving object has moved to a new tile in this frame. Then I am forced to apply vision calculations to ALL instances of Movable objects.

[4ian]

Two things. First, testing your approach:

Could you emulate this with a Linked Object? Put a single "HasMoved" invisible object on the scene.
Then, you translate
"Add to dynamic group [...]" to "Link MovingUnit with HasMoved"

And "For Each HasMoved" to "Take into account all MovingUnit linked to HasMoved"

The "Take into account" means that you will consider the ones in "HasMoved" "group". There won't be any loop on all movables objects.

But remember that as soon as you have a condition using all movable objects, GDevelop has to iterate on all of them - you want to only have this once per frame (if not, not at all). Remember that using sub events is also a way for you to avoid to iterate on all of them.

Second thing, I think that you would benefit from optimisations done to be able to find objects near another (i.e: the Distance condition) without checking all objects in the scene. This is something I started a while ago but never finished (#1393).
These improvements are storing the objects on the scene into a spatial data structure. This means that when you use the collision condition, or a condition like the distance between two objects, we can quickly find the objects around another without testing all objects.

---

Anyway for now, if you can try to use Linked Objects to simulate your HasMoved/MovingUnit groups, you might get some good results already (because you'll avoid iterating on all objects in the first events).

[tristanbob]

**Could you emulate this with a Linked Object?

I tried using linked objects to function as a "group" of instances, but it didn't work the way I thought it should. I will do some more testing to see if I can overload the "linked object" functionality in this way.

Remember that using sub-events is also a way for you to avoid iterating on all of them.

This is actually the best answer! I was overthinking this problem. This was my previous logic:

Did the object change tiles? -> Add to a dynamic group -> Run Function: Apply vision for these units

But I didn't need that middle step at all!

Did the object change tiles? -> Run Function: Apply vision for these units

Second thing, I think that you would benefit from optimizations done to be able to find objects near another (i.e: the Distance condition) without checking all objects in the scene. This is something I started a while ago but never finished (#1393).

I am looking forward to spatial partitioning. It is currently not feasible to do distance checks on objects with millions of relationships (200 units x 10,000 fog objects = 2,000,000 distance checks). Fortunately, I have discovered a great alternative using a 2D array to store opacity values for each fog object.

Florian, thanks for mentoring me on my game dev journey!