In the previous lecture, we were talking about how you can install Truffle, and how you can start your first Truffle project. Truffle Standard Project, that I call it here in our GitHub course repository. Now what I want to do in this lecture is I want to take our game, and if I have a look into The Game in Solidity, SO2 The Game in Solidity, then you can find somewhere the folder FINAL GAME, which is the final game from the previous section we were developing in Remix. Now having the game in Remix is one thing, but putting it into a Truffle project is another thing. It doesn't take too long. But there are specific parts you have to take care of and this is what I'm going to do in this lecture.

And I want to start by creating just a brand new folder and I call it SO4, Our Game in Truffle. So, you know where you can find it when you want to look into that. And then I'm just going to open a new terminal and it is opening inside the right folder. Just make sure you're inside the right folder and our folder is empty. What I'm going to do next is, I have already Truffle installed in it, and if you have not then watch the previous lecture. I going to do a Truffle in it, and that will download the Truffle repository— It's an empty repository— and initialize it with these folders here. You can see them popping up here on the left side. So, we have one contract which is the migrations contract, one migration, no test and the truffle-config file. And what I want to do at the end of this lecture is take our game and deploy it to a Ganache. So, how do we start adapting this Truffle standard project to represent our game? Now, the first thing is I have to import all of our smart contracts and let's just copy them. And I'm going to paste them into the contracts folder here. Now they are in Truffle, but they are not visible to Truffle yet, especially when it comes to deployment onto the right network.

This is where these migrations files come in. And the migrations file are scripts that tell Truffle, "Take the contract— migrations in this case— and deploy it." And the deployer is kind of an object that gets initialized with the right configuration from this truffle-config file where we define several networks. Now, let us start with a simple migration where we are deploying our GameManager and that's it. We just have to deploy our GameManager because in our GameManager, we are deploying with the GameManager, the HighscoreManager and ThreeInARow game as well, in an undeployed way though; we are creating a new instance when we start a new game. So, at the end we just have to deploy our GameManager. Let's copy the migration. I'm going to paste migration and I'm going to call it '2_deploy_gamemanager.' And inside here we have to define, first of all we want to deploy our GameManager and I call this GameManager here as well. And then we deploy the GameManager. And the GameManager does not have any constructor arguments.

If it had any constructor arguments, then you have to give it here as additional parameters: the constructor arguments one, two, three, four, five. If its strings, If I don't know what kind of constructor arguments you have but they are added here at the end after the deployer. If you have a smart contract that needs the address of another smart contract, then you have to deploy the smart contract, and then you get back a promise. And then you have to do, 'then,' and then you get the instance. And here you get back the 'instance.address' that would be the address of the instance. So, for example, when you have an HighscoreManager and you want to deploy the HighscoreManager and give it inside the constructor as an argument, the address then you have to deploy it that way. But, in our constructor inside the GameManager, we are creating the HighscoreManager ourselves. So, we're not really deploying it in outside of Solidity. We are giving it here the address already itself. So, we don't need this at all, I just want to have it mentioned because it came up as a question quite often, how you add constructor arguments and how you work with instances that are deployed. Alright. Now, all we have to do next is we have to deploy it somewhere. And the question is, where are we going to deploy this? And this is defined in the truffle-config file. If you open the config file, there is a lot of comments. And somewhere it starts with module exports, and then there's the networks object inside and inside the networks object you can have several different networks. Now let me uncomment this one, and just give you an example of how this works and then describe it a little bit more in detail. Alright. So, I'm going to my powershell, to my terminal window here and I'm starting a Ganache CLI in order to have a Blockchain node running. I already have a Ganache CLI still running. I'm going to close this one first and close this one from our previous lectures as well. And I'm going to start a new one. Alright, my Ganache is running local host 8545. Just make sure that you have the same port here, if you have the UI version of Ganache CLI then port might be different. And then I'm going to start another terminal, just have to click on the + item here. Let me see where I am, I have to go to the right folder. Alright. And now I can type in simply, 'Truffle migrate.' Let's see what happens. It is compiling our smart contracts and it is deploying our smart contracts.

If I go back to our Ganache then I see that there are a lot of transactions started in somewhere in between. And these are the transactions. I'm going to scroll up a little bit, let me make this bigger. Then I see 'deploy the Migration' and then 'Deploy the GameManager.' And both get back a transaction hash first, and then it waits until the transaction is mined. Let me redo this. I close Ganache and I'm opening Ganache again, with a block mining time of 15 seconds in order to see how this really works. So now I've reopened Ganache, nothing is on the Blockchain, and what I want to do next is I want to hit reset here at the end, so just roll with me— I am explaining it in a second— while we're going to add this reset here. So, it's compiling again and now it's deploying, and you see it's waiting until the transaction is mined in the background the Ganache, we have 15 seconds block mining time, so it can take up to 15 seconds in order to mine this transaction. And then we see how much it costs, how much gas it cost to deploy this, and where it was deployed, with which account it was deployed and so on. So we see a lot of details and at the end we hopefully see that total deployment is 2 and that there is a final cost for deploying these smart contracts. Alright.

Now we have our smart contracts running on a Blockchain, our own development Blockchain, but there is a lot of things that happened in the background, a lot of magic. And I want to talk about this magic a little bit. When we are deploying a smart contract on a network, then it will create or write into this called artifact. They are Truffle artifacts and they contain a lot of information about the smart contracts, and about the networks where they are deployed on. And you can find them in the 'build contracts' folder, there are chasing files. Now let me open one of these chasing files and you will see as a first element, something that is very familiar for you— hopefully at this point— that's the abi. You have a lot of meta information as well. So, first you have the contract name, then you have the abi. Then when you scroll down, you have the actual bytecode of the smart contract, you have a lot more information about all kinds of things that are happening within the smart contract. And at the very bottom, you have, for the network that you just deployed the smart contract on, an address where the smart contract is running on.

So, if you are closing Ganache and reopening it, and it might have the same network IDE, then Truffle will assume that our smart contract is still running on this network. So this is why we added the reset, or else Truffle will not just redeploy a smart contract on a network IDE, it has already a smart contract, or this smart contract deployed with the same hash, meaning it didn't change, so we didn't change the source file, so it doesn't have to redeploy the smart contract. So, why is it so easy to deploy smart contracts to different networks with Truffle? Now, let me in this case— and you don't have to do the same here— I'm going to open Ganache, the UI version as well. And I can do this because the Ganache CLI version is running on a different port. So now I have a Ganache running on localhost 8545, that's the CLI version, and I have another Ganache running on localhost 7545— totally different database, totally different data inside. And going I still have my Ganache open here, just in case, and I'm going to change my truffle-config file so that I can easily deploy to two different networks on demand.

I'm going to copy this, and I call that one, that one I call 'ganachecli,' and the other one I can call 'ganacheui.' And I changed the port to 7545, and now the big question, is how can I distinguish these two? Well, I can give during migration, I can say, 'network ganacheui,' and it should deploy to the Ganache to the UI version. Hopefully, I didn't make a mistake. And here we go, we have two transactions: our ganacheui, and maybe you see somewhere even the log output, your network named ganacheui, and it goes into, it parses this truffle-config.js file, goes into the network's object, and sees what are the networks that I have here. And here's the difference: if I omit the network specification, so if I don't give it any networks parameter here at the end of our command, then it will automatically look for development network. So, if you have a development network and you don't specify networks argument here for our migrations command, then it will take the development network. Otherwise, it will just take the one that you specified here, and if it can't find anything, then it will probably give you an error. I hope it will. It doesn't say it doesn't know 'ganacheui234,' that I just typed in here.

So, it's kind of safe. And when you look at these comments in our truffle-config file, and you see there are already some normal use cases where Truffle gets used for, with this network's configuration file for. There is maybe an advanced configuration for a specific network that is used in house for teams, then there is one specific network which is the Ropsten test network where- we are not using- on the Ropsten test network if you're using Infura, which is an external provider, then we want to still be in control of our private keys. So, Truffle will therefore, in our case and we're going to use this later, use the so called 'HDWalletProvider,' where we can just input this Truffle mnemonic, and it will recreate the private keys locally, and then sign the transactions locally, and then send the signed transactions back to Infura in order to distribute it through the network. And there is also a private one which is useful for private networks. Then there's some more information, some more configuration but that's not concerning the networks. And for our lecture here we are done. We have adopted Our Game in Truffle, so we can start now with actual testing, which we're going to do in the next section.

Adapt the Truffle Environment for our Game

About