#also mind if we continue this tomorrow

1 messages · Page 1 of 1 (latest)

fast quiver
#

trying to set up characters, arrays, and managers

tawny wasp
#

Ok.

fast quiver
fast quiver
#

hello, are you currently avaliable @tawny wasp ?

fast quiver
fast quiver
#

didn't you say to make an array for my skills?

tawny wasp
#

Yes, but weren't your skills scriptable objects?

fast quiver
#

ah well....I decided that SO's aren't really helpful here

#

it felt like I was just over complicating everything

fast quiver
tawny wasp
#

Where are you gonna store skill data?

#

And what exactly do you plan to do with these delegates?

fast quiver
#

I put them on the character prefabs

#

they will hold the skill data

tawny wasp
#

Do you understand what a delegate is?

fast quiver
#

function containers?

tawny wasp
#

Okay, let's say so. And how do expect them to hold any data?

fast quiver
#

the methods I made will hold the data

tawny wasp
#

Methods don't hold data. At best they hold temp data required for the method processing or hardcoded constants.

fast quiver
#

how do they not hold data? like my attack_one method

tawny wasp
#

That's the method yes. How do you expect to get a skill sprite out of it for example?

fast quiver
#

ah, it only holds at the moment data

#

and since its not in update nothing can be called over and over, only once when pulled

fast quiver
#

should I have done SO's?

tawny wasp
#

First of all, approach to what? What problem are you trying to solve with it?

fast quiver
#

skill storage

tawny wasp
# fast quiver skill storage

It doesn't hold a skil. It holds a method. At best it's the behavior of the skin. What about other type of data, like the sprite?

fast quiver
tawny wasp
#

Yes.

fast quiver
#

crap, what can I do?

tawny wasp
#

Well, you've been suggested to use SOs.
The other method is to define a plain class that contains the skill data and initialize it on the character prefab. In either way, you'll need to use interfaces of inheritance to define the actual behavior of the skill.

fast quiver
#

how would the SO's work?

tawny wasp
#

SOs are basically classes that you can serialize as assets.
Same as MonoBehaviour on gameObjects, but without gameObjects. They can live just as files in your assets folder. That's why they're useful for defining static data and referencing it from wherever you want.

fast quiver
#

So uh…I’ve actually decided on some design changes

fast quiver
tawny wasp
#

Okay

fast quiver
#

Im throwing away the idea of a skill menu or item menu that generates buttons, too complicated

#

The buttons mainly just puts SO’s into queue

tawny wasp
#

So what's the difference with what you planned before? The buttons are preexisting objects now?

tawny wasp
#

Ok, so what's the actual question?

fast quiver
#

Well it’s more about the SO’s since the Queue is just a gameobjecy array, I’m not sure on how to do the SO’s now

tawny wasp
#

A queue of SOs?

#

Just change the generic type of the queue🤷‍♂️

fast quiver
tawny wasp
#

Please ask whole questions. I'm kinda tired of playing the guessing game...

fast quiver
#

Well I’m not sure what to fill into the SO’s, my idea for the queue is to use empty game objects to represent the array and they would change if there was an SO was assigned, so from what I believe would I assign an SO to a gameobject in this case, and have it filled with just image data and on execute, or an SO not attached to anything and still have all that?

tawny wasp
fast quiver