#Pokemon fan game data
1 messages · Page 1 of 1 (latest)
Scriptable objects with unique IDs
You can use an editor script to generate a unique GUID for every scriptable object
@tribal finch
So, I could have 3 Bulbasaur and their IDs would be 1-3 and the code would separately remember which prefab each ID is set to?
A small-scale cooperative game sample built on the new, Unity networking framework to teach developers about creating a similar multiplayer game. - com.unity.multiplayer.samples.coop/GuidScriptable...
It really depends on how you want to refer to your pokemon
But yes
So it could be like
1-bulbasaur
2-bulbasaur
3-pikachu
2-bulbasaur
Wait there's a way to store lists with numbered rows or something like that right?
No not like that
I would be
1 - Bulbasaur
2 - Charmander
3 - Squirtle
4 - Pikachu
And then you'd keep a list for a players pokemon
which would just be a List<int>
But the concern is more about what if I have more than one of a pokemon. And how would I store each one as a separate object in a long-term storage?
Do they have their own properties?
They would have, yes. Minor data to each, like bond or gender
okay just wrap that in another data object such as a class or a struct
Nothing as expansive as stat distribution and move pools, though.
but these are runtime and dynamic objects, so scriptables wouldnt be good for that
So you'd have 1 scriptable which defines a blueprint for the pokemon, this one has an ID
and then you'd have another object which looks something like this
public struct Pokemon
{
public int Id
public int[] MovePP
public int Hp
public int Level
}
An individual instance ID or a species ID?
Store a List<Pokemon> instead
It would be a species ID
But it is ofcourse possible to also generate an ID for every unique pokemon
(or just hash it)
But how would I go about storing the multiple instances of the generated pokemon? Do I just put the current not-in-use in a parent ddol object?
What do you mean?
What are generated pokemon?
You mean "wild" pokemon?
I don't know what the scope of your project is
Super cool project by the way :)
Almost deckbuilder-like? You're offered a choice of 3 cards" that will have preset data (moves, name, sprite, types) and more randomized data (nature, berry preference, gender)
Idk how deep I'll go into development. It's more for personal practice and learning and a proof-of-concept
Is it required to store the pokemon not in use?
I am getting he feeling that you might have some more design choices to make, If you are just looking to learn I would recommend that you just start building it, but stick to only 10 pokemon for now, that way if you need to redo something you dont have to do 151 objects again
Just develop untill you run into more problems
I want them to be available to be swapped out cards in deck with cards you've collected.
You should go read about Scriptable Objects.
Which means cards not currently being brought into the next scene need to be stored permanently somehow.
Then as Ham suggested, start with ONE pokemon, then go to two. If you get two to work, you should be able to get 20000 to work.
Unless I'm supposed to store them all in a ddol parent object. But fully loading everything like that seems like a waste of resources.
You need to stop spewing random stuff, and read for a bit mate.
Go checkout what a Scriptable Object is.
Understand how they work, then see if that fulfills the majority of what you need. From there, iterate, or come back if you realize "hey guys, i explained it wrong earlier, an SO won't work because I just learned they do X and i need Y"