GOalGame

Plataforma gamificada para criação e participação em projetos de vida com foco nas ODS através de incentivos gerados pela gamificação e tokenização, estimulando doações após a conclusão do projeto.

  • 523 Raised
  • 76 Views
  • 5 Judges

Categories

  • EthereumBrasil

Gallery

Description

1. Descrição

O projeto foi desenvolvido por integrantes do grupo GOalGame composto por Amanda, Artur, Lucas, Vinicius e Yaesol. A proposta de solução é uma plataforma gamificada para criação e participação em projetos de vida com foco nas ODS através de incentivos gerados pela gamificação e tokenização, estimulando doações após a conclusão do projeto.


2. Objetivos e Justificativas

Disponibilizar uma plataforma para que qualquer pessoa consiga atingir seus objetivos de vida de uma forma lúdica, gamificada e interativa visando três pilares: 

  • Comunidade: Conexão com pessoas que estão buscando objetivos de vida semelhantes.

  • Melhoria na Qualidade de Vida: Incentivo através da plataforma para continuar diariamente concluindo os desafios.

  • Retorno Financeiro: Investimento em si próprio e nos membros do projeto de vida através de tokens.

Com cada projeto de vida sendo cadastrado em uma  - ou mais - ONGs que estão atreladas aos ODS (Objetivos de Desenvolvimento Sustentável), com o intuito de parte do valor ser revertido para essa ONG na conclusão do projeto.


3. Análise SWOT

Utilizamos o método de planejamento estratégico análise SWOT para identificar as principais características do projeto: forças, fraquezas, oportunidades e ameaças; além de maior entendimento na nossa proposta de valor.

3.1 Strength (Forças):

  • Imutabilidade contratual aplicada ao projeto de vida garantindo a confiabilidade;

  • Senso de comunidade;

  • Retorno Financeiro;

  • Incentivo através da gamificação para realização dos desafios diários.

  • Incentivo para o impacto social

  • Reprodutibilidade

3.2 Weakness (Fraquezas):

  • Acessibilidade web2

3.3 Opportunity (Oportunidades):

  • Descentralização da Web3 contribui na gama infinita de pessoas que podem se conectar através da plataforma;

  • Conectar-se a mentores que contribuirão para a jornada de usuárie

3.4 Threat (Ameaça):

  • Criação de comunidades maliciosas


4. Solução existentes

4.1.1 Play to Earn

        Jogar para ganhar é um modelo de economia de serviço que permite aos jogadores ganharem sem investir no setor de jogos Web3. Desenvolvem arquitetura econômica dentro do game. Exemplos: Axie Infinity, Upland.

4.1.2 Move to Earn

O Move-to-Earn é um novo modelo econômico da Web3 que recompensa os usuários por participarem de atividades físicas e esportivas. Exemplos: STEPN, Sweatcoin

4.1.3    Diferencial

Enquanto move to earn se concentra em recompensar atividades físicas e play to earn gira em torno de ganhar recompensas por meio do jogo, GOalGamer adota uma abordagem distinta ao mesclar os elementos de gamificação, tokenização e projetos de vida orientados para objetivos, fornecendo uma plataforma onde os indivíduos podem criar e participar de projetos de vida personalizados alinhados com os Objetivos de Desenvolvimento Sustentável (ODS), criando suas próprias jornadas de forma dinâmica.


5. Arquitetura de Solução:

6. Explicação Técnica:

Quando o usuário interage com o front-end do meu DApp, ocorrem diversas interações entre o front-end e a blockchain. Aqui está uma explicação melhorada dessas interações:

1. Ao clicar no botão da Metamask, são ativadas funções de conexão entre a Metamask e o servidor web hospedado. Essa conexão é necessária para estabelecer uma comunicação segura entre o usuário e a blockchain.

2. Ao clicar no botão "Criar Goalgame", algumas funções em Solidity são executadas. Resumidamente, essas funções pegam os valores inseridos pelo usuário em campos de entrada (inputs), tratam esses valores e os armazenam em um objeto criado no contrato inteligente (smart contract) desenvolvido em Solidity.

3. Para entrar na página de jogos, são executadas algumas funções que realizam uma chamada (call) ao contrato inteligente para buscar informações contidas no objeto mencionado anteriormente. Essas informações podem incluir detalhes sobre os jogos disponíveis, como pontuações, participantes ou outras estatísticas relevantes.

4. Ao entrar na página de interação com os jogos, outra chamada ao contrato inteligente é feita para obter mais informações específicas necessárias para interagir com os jogos. Essas informações podem incluir regras de jogo, condições de vitória ou outras configurações relevantes.

5. Quando o usuário interage com os botões do jogo, são executadas funções do contrato inteligente que têm finalidades específicas relacionadas a cada botão. Por exemplo, pode haver uma função para "iniciar o jogo", outra para "realizar uma jogada" ou até mesmo uma para "finalizar o jogo". Cada botão executa a função correspondente no contrato inteligente para garantir que as ações sejam registradas corretamente na blockchain.

A maioria dessas interações requer solicitações (requests) à blockchain onde o contrato está implantado. Algumas solicitações são apenas leituras de informações (chamadas), enquanto outras exigem o envio de informações, como assinaturas e gás, para realizar transações na blockchain. Isso permite que as ações realizadas pelo usuário no front-end sejam devidamente registradas e executadas na blockchain, garantindo transparência e segurança para o DApp.

Infura é um serviço que atua como um gateway para a rede Ethereum. Ele fornece uma maneira conveniente de se conectar à blockchain Ethereum sem precisar executar um nó completo localmente. Ao utilizar o Infura, os desenvolvedores podem se concentrar na lógica do aplicativo e na interação com a blockchain, sem precisar lidar com a complexidade de configurar e manter um nó Ethereum.

Existem diferentes tipos de comunicação envolvidos quando o front-end interage com a blockchain através do Infura. Vamos abordar os dois principais:

1. Chamadas de leitura (Read Requests): Essas chamadas são usadas quando o front-end precisa recuperar informações da blockchain, mas não faz alterações nos dados. Essas chamadas são executadas usando o protocolo JSON-RPC. O front-end envia uma solicitação JSON-RPC para o endpoint do Infura, especificando o contrato e a função a ser chamada, juntamente com quaisquer parâmetros necessários. O Infura encaminha essa solicitação para um nó Ethereum, que executa a função no contrato e retorna o resultado para o front-end através do Infura. Essas chamadas não exigem uma transação na blockchain, portanto não requerem assinatura ou gasto de gás.

2. Transações (Write Requests): Essas chamadas são usadas quando o front-end precisa executar uma transação que altera o estado da blockchain. Ao contrário das chamadas de leitura, as transações exigem uma interação mais complexa com a rede Ethereum. O front-end constrói uma transação, especificando o contrato, a função a ser chamada e quaisquer parâmetros necessários. Em seguida, a transação é assinada digitalmente usando a chave privada do usuário, garantindo a autenticidade da transação. O front-end envia essa transação assinada para o Infura, que a encaminha para a rede Ethereum para ser incluída em um bloco. A transação pode exigir o pagamento de uma taxa de gás para incentivar os mineradores a incluí-la no blockchain. O Infura monitora o status da transação e notifica o front-end quando ela é confirmada na blockchain.

O Infura atua como um intermediário nesse processo, facilitando a comunicação entre o front-end e a blockchain Ethereum. Ele lida com a complexidade da infraestrutura de blockchain e permite que os desenvolvedores se concentrem na construção do front-end do DApp, enquanto a comunicação com a blockchain é tratada pelo Infura de forma segura e confiável.


Dapp: https://hackathon-ethsp-angels-git-main-goalgame.vercel.app/

GitHUB: https://github.com/arturch2011/hackathon-ethsp-angels.git

Etherscan: https://mumbai.polygonscan.com/address/0x7fae45e44822a799d043d26d3698adefa4a2a556

Endereços:

- AngelToken = 0xe9f907BdA74BD062E829b68FD6aEe25a44Cd1DC1 // 0x1bc5cEC4Be75C23a27B0F5320ED1B763DE1c9098

- AngelsFactory = 0x2A14cc523f3d4dd6dC081FA25b31291A3c961aad // 0x5C831E10eF6Ce071E457A6d9171d431aFC3c3fab

- DailyImprovementsFactory = 0xC94a06B724E7c40c0384c848279F020a75b1FF59 // 0xaE9E3Ec7C9fC35fE4BbA9DB94EfEa3F2924EF75c // 0x0330705a927662e9266d4aCE865D404DE52F30d8 // 0x7Fae45e44822a799d043D26D3698AdeFa4A2a556

- DailyImprovementsFactory = 0x7Fae45e44822a799d043D26D3698AdeFa4A2a556

Attachments