prefab creation

[sneakzttv]

I've created prefabs to ease the learning curve for new developers, this also leaves the samples untouched so they can be used as a point of reference as needed depending on the developers coding experience. Showing users a simple prefab with the block of code they're after is going to save us a lot of time in the long run when it comes to teaching the SDK & customer support.

Below I've listed the issues this fixes as well as a how to guide for testing (Thanks Juan!)

1. Problem: The example scene works great in terms of showing a working call. However, we can't alter this code.

2. Fix: Created prefab & script folders. Each each function now has a corresponding prefab and script in web3.unity\src\UnitySampleProject\Assets\Samples\web3.unity SDK\2.5.0 You may copy the code to a new script and make changes without having to worrying about breaking anything.
   

3. Problem: Editor inputs are clashing with my script inputs.

4. Fix: I've made the inputs on the prefabs private so the user is only editing code in 1 place (the script). This removes the possibility of human error and saves us some time in discord by ruling it out.
   

5. Problem: The example scripts are hard to find as they are deep in the menu hierarchy and they only work on a button.

6. Fix: Easy fix with the new examples! As I've added monobehaviour and removed the sample behavior, i was able to move the script onto the root of the object and bypass the parent classes awake call. It also makes it easier for new users to find and make changes to the script.

Whilst having it tied to a button is great for testing purposes, most users are probably going to want to initialize the call in other ways like events, triggers or external function calls etc. What if they have a claim call after winning a match, they'll probably want to fire that off after points are calculated. They're going to have to make these changes regardless, this way we're just providing a simple base for them to add inputs to and iterate on without needing to worry about parent classes & overrides.

Whilst advanced users will probably go straight for the sample code, beginner developers wont understand it. We should be catering for everyone here in my opinion, inclusivity plays well for increasing our userbase.

4. Problem: This SDK is hard to understand

5. Fix: Not anymore! It's now a 3 step process! This will also be pushed to the docs.

• Find and copy the prefab script in the very easy to find prefab folder
• Alter the class name and input variables
• Do something with the results. Simple!

To test these prefabs:

1. Place the sample login scene as your first scene and then a 2nd blank scene in your build settings.
2. Make sure your 2nd scene has an event system present (if we put the event system in the prefabs it loops when > 1)
3. Place as many prefabs as you like in the 2nd scene and test webgl/desktop (they stack on each other and have a close button)
4. The prefabs should resize dynamically for any screen size (mobile too) and results will be logged to the console.
   

Always welcome to make suggestions on how this could be done better.

[kantagara]

Problem: The example scene works great in terms of showing a working call. However, we can't alter this code.

Well, anyone who uses the SDK can alter the code because it's open source. When they import our samples they can do whatever they want with that stuff including completely altering the code to however they like it.

We already have 40 inheritors of the samplebehavior which are doing exactly what you also wrote for the samples, so I personally think that this shouldn't go to main.

[sneakzttv]

Just there to make things beginner friendly really so there's a separate block that they can iterate on rather then having to find an example and change things around to initialize it another way that isn't a button press.

[kantagara]

Well if you are an absolute Unity beginner, I still think that you should know the basics of the engine, like adding single script to a UI button object shouldn't be something that is slowing you down (And that is what we currently have).
What would be also benificieary is to actually have scripts per-protocol (so erc20, erc1155) etc, since that way you'd have a centralized place to call all the methods in a single script which I think would be beneficiary for the actual games.
Imagine that a round is finished,and you actually went in and have to update the balance or need some other stuff to have in a centralized place. Adding only one script that's dealing with all the stuff from the single protocol, in a production environment, should be the way to go (and is more memory efficient). For samples, we can leave the things like they are on SampleMain for sure.
It would be cool if you implement that yourself, if you need any help, don't hesitate to ask anything :)

[sneakzttv]

It's more so dealing with the parent class and the way it locks the tasks initialization to a button click from the inherited awake method call. We're going to have to teach users to remove that call and alter the script regardless as not everyone wants the call to be on a button click and not everyone wants to attach their script directly to a button somewhere in the root objects hierarchy.

We want to give developers the freedom to make any transaction call whenever and however they please whether it be through a button, an event or an external function etc. This just eases the learning process for new users that's all, otherwise we're going to have to teach it from the docs which is just increasing a new users onboarding friction.

Whilst I agree that a centralized protocol would be nice, it wasn't in the scope of the task. I can change the prefabs to use the protocols directly but I figured a simple layer of usability would be nice for beginners. Most users are still trying to work out the SDK and I believe the PR changes will go a long way in helping with that. Lastly, I'd be happy to work on a centralized protocol prefab with drop down selections for the next task if that's what we want, sure!

[nftpixels]

Hey Team,

Just reading through this now;

I believe the goal with the prefabs was to go back to the easy-to-use format of building by providing developers with a shortcut to go from A=>B when it came to game development - Which I support and the community as well.

After chatting with engineering and product, I found that stakeholders preferred for Prefabs to remain outside of the SDK.

In saying that though, what Sneakz did, did greatly improve usability by providing developers with a flow showing the "full story" in his examples.

It would be great if we can add categories within the documentation like we did with 1.6 and 2.1 showcasing the full story of each example. Starting from the entry point and providing a full example of how we go from A=>B.

Thanks for all the efforts put into improving the SDK team!

[sneakzttv]

That's how I thought we would do it, easy prefabs and the docs showing the prefab call right into the guts of the function. This way users can pick and choose how they want to execute their calls depending on their experience level. Also we don't need to update the prefabs unless an input parameter in the samples changes, as they're all referencing the same end functions it's light on technical debt.

Having it as a separate package is also a good idea too. I'm fine either way as long as we have something somewhere to point new users to so we can ease onboarding friction.

[robGG1997]

To add to what @kantagara mentioned, from a DevEx perspective this isn't ideal imo. I say this because the prefabs are basically the sample scripts with extra UI and depends on Web3Accessor. Everything in these prefabs I see is in the Sample scenes so I consider them to be redundant plus we probably should refactor samples to not have a MonoBehaviour per function, instead makes sense to have either simple classes or just methods per function.

[sneakzttv]

Closing and moving them into the docs after discussions so we don't bloat the SDK.