# Hackaton ideas
## Games
**1. Game 2048**

#### :pencil2: Task Description:
Your task is to develop a smart contract that encompasses the rules of the game 2048. This contract should interact with other contracts known as "strategies" that will play the game with it.

#### :pushpin: The rules of the game 2048:

1. The game is played on a 4x4 grid, initially filled with two tiles, each containing the number 2 or 4.
2. The objective of the game is to combine tiles with the same number to create a tile with the number 2048.
3. On each turn, the player can swipe the tiles in four directions: up, down, left, or right.

4. When swiping in a specific direction, all the tiles on the grid will move as far as possible in that direction until they either reach the edge of the grid or collide with another tile.

5. If two tiles with the same number collide while swiping, they will merge into a single tile with the sum of their numbers. For example, two tiles with the number 2 will merge to form a tile with the number 4.

6. After each swipe, a new tile with either the number 2 or 4 will appear in an empty randomly chosen cell on the grid.

7. The game continues until one of the following conditions is met:
a. The player achieves the 2048 tile, resulting in a victory.
b. There are no more empty cells on the grid and no possible moves can be made, resulting in a loss.

8. The player's score increases each time two tiles are merged. The score is the sum of all merged tiles during the game.

9. The player can track their highest score achieved in a particular session of the game.

10. The player can choose to restart the game at any time to make a fresh attempt.

The goal is to strategically combine tiles, plan moves ahead, and optimize tile placements to reach the coveted 2048 tile and achieve the highest score possible.

#### :pencil: Requirements:
1. Smart Contract: You need to create a smart contract that implements the rules and mechanics of the game 2048. It should include functions for moving tiles in different directions (up, down, left, right), merging tiles, checking for valid moves, tracking the score, and determining game over conditions.

2. Strategy Contracts: Participants are required to develop their own strategy contracts that interact with the main game contract. These strategy contracts will implement the logic for making moves and deciding the best actions to achieve the goal of reaching the 2048 tile in the minimum number of steps while consuming the least amount of gas.

3. Optimization: Participants should focus on optimizing their strategies to minimize the number of moves required and gas consumption. Strategies should aim to achieve the 2048 tile efficiently by employing intelligent algorithms, heuristics, or AI techniques.

4. Example Strategies: As part of the task, you should provide several example strategy contracts that can play the game with the main smart contract. These example strategies should demonstrate different approaches and techniques for achieving the goal efficiently.

#### :bookmark: Hints for implementation:

1. The 2048 contract sends a message to the strategy contract with information about the game board, including the 4x4 grid and the numbers on the tiles.

2. Based on this information, the strategy contract selects a move (up, down, left, or right) and responds to the game contract with the chosen move.

3. The 2048 contract executes specific actions corresponding to the player's move, such as shifting the tiles, merging them, and generating new random values. It checks if the number 2048 has been reached, if the player has lost, or if the gas for the game has run out. If not, it sends the updated game board to the player.
4. To enable extended message exchanges between the master contract and the strategies, [gas reservation](https://wiki.gear-tech.io/docs/developing-contracts/gas-reservation/) is necessary. The author of a strategy should reserve gas for their specific strategy.

<center>
<img src="https://hackmd.io/_uploads/HJS3w-ar3.png" width=500>
</center>

#### :100: Evaluation Criteria:
1. Functionality: The smart contract should correctly implement the rules of the game 2048 and handle interactions with the strategies.
2. Strategy Performance: The strategies provided should showcase effective approaches in reaching the 2048 tile with minimal steps and gas usage.
3. Code Quality: Well-structured and well-documented code will be appreciated, including comments explaining the logic and algorithms used.
4. Efficiency: Participants should demonstrate efforts to optimize their strategies for improved performance in terms of the number of steps and gas consumption.

Participants are expected to submit their developed smart contracts, including the main game contract and strategy contracts. Additionally, they should provide a brief explanation of their strategies and how they achieve efficient gameplay in the 2048 game. The judging panel will assess the functionality, performance, and efficiency of the submitted solutions.

**2. Conway's Game of Life**

Conway's Game of Life is a cellular automaton devised by mathematician John Conway in 1970. It is a zero-player game, meaning that its evolution is determined solely by its initial state, requiring no further input. The game is played on a grid of cells, where each cell can be either alive or dead.

#### :pushpin: The rules of Conway's Game of Life are as follows:

1. **Loneliness (Underpopulation)**: Any live cell with fewer than two live neighbors dies, as if caused by underpopulation.
<center>
<img src="https://hackmd.io/_uploads/SJOIuQCB2.png" width=200>
</center>

2. **Reproduction**: Any empty cell with exactly three live neighbors becomes a live cell, as if by reproduction.
<center>
<img src="https://hackmd.io/_uploads/BJNEn7RB3.png" width=200>
</center>

3. **Overcrowding (Overpopulation)**: Any live cell with more than three live neighbors dies, as if by overpopulation.

<center>
<img src="https://hackmd.io/_uploads/SJmJFX0Sn.png" width=200>
</center>

4. **Stasis**: A cell with exactly two adjoining cells remains the same.

<center>
<img src="https://hackmd.io/_uploads/rJxc6XCr3.png" width=200>
</center>

Watch the game demostration [here](https://www.youtube.com/watch?v=C2vgICfQawE).

The rust implementation of game of life algorithm can be found [here](https://rustwasm.github.io/docs/book/game-of-life/implementing.html).

There is an fun adaptation that can produce a competitive and strategic activity for multiple players.

#### :pencil2: Task:

1. Develop a smart contract that enables a multiplayer Game of Life.
2. Implement functionality that allows players to set the initial state of the game by specifying the positions of cells on the game board.
3. Create a mechanism for the game's evolution, where the contract automatically changes the state of the game board based on the rules of Game of Life.
4. If the evolution of the game stops, provide players with the opportunity to make additional moves.
5. Additionally, devise a mechanism that allows the contract to display the game's evolution on the client side. This can be achieved by sending messages containing information about the state of the game board, changes, and game events.

<center>
<img src="https://hackmd.io/_uploads/r1WAdV0Sn.png" width=400>
</center>

#### :100: Evaluation Criteria:

1. Functionality: The smart contract should correctly implement the rules of the Game of Life and allow multiple players to participate. It should handle the initialization of the game, the evolution of the game board, and additional moves when the evolution stops.

2. Game Initialization: The contract should provide a mechanism for players to set the initial state of the game by placing cells on the game board. It should validate and store the initial configuration accurately.

3. Game Evolution: The contract should autonomously evolve the game based on the rules of the Game of Life. It should correctly update the state of the game board in each generation and maintain the integrity of the game rules.

4. Player Interaction: The contract should allow players to make additional moves when the evolution of the game stops. It should handle player inputs and update the game state accordingly.

5. Client-Side Visualization: The contract should have a mechanism to display the evolution of the game on the client side. This can be achieved by sending messages containing information about the game board state, changes, and game events to the client.

6. Documentation and Readability: The code should be well-documented, clear, and readable. It should follow best practices and standards for Solidity development to ensure easy understanding and maintainability.

7. Testing: The contract should have comprehensive test cases to verify its functionality and handle different scenarios. Test coverage and accuracy of the tests will be evaluated.

8. Overall Design and Creativity: The overall design of the contract and any additional creative features or enhancements will be considered during evaluation. Innovative approaches or improvements beyond the basic requirements will be appreciated.

**3. Tower defence**

Tower defense is a popular genre of strategy video games where players must defend a specific area or path from waves of incoming enemies. The core gameplay revolves around strategically placing defensive structures, typically known as towers, along the path to attack and eliminate the advancing enemies.

The primary objective in tower defense games is to prevent the enemies from reaching a specific location, often referred to as the "end point" or "base." Players have limited resources to purchase and upgrade towers, which vary in types, abilities, and costs. Each tower has unique characteristics and attack capabilities, such as shooting projectiles, deploying traps, or casting spells, to target and eliminate the enemies.

Enemies typically follow predetermined paths or routes, and the player's goal is to strategically position towers along these paths to maximize their effectiveness and minimize enemy progress. Towers can be strategically upgraded or sold to optimize their performance against increasingly challenging waves of enemies.

#### :pencil: Requirements for the contract:

1. Map: The contract should include a built-in map where players can strategically place their towers and where enemies can move. The map can be represented as a grid or any other suitable data structure.

2. Towers: The contract should support different types of towers that players can purchase and place on the map. Each tower should have unique characteristics such as attack level, range, and attack speed. (In the initial implementation, there can be only one type of tower)

3. Player Balance: Each player should be provided with an initial balance that they can use to purchase towers. The player's balance should be trackable and updatable in the contract.

4. Enemy Waves: The contract should support the generation and sending of enemy waves to the map. Enemy waves should have different characteristics such as the number of enemies, their strength, and abilities. (In the initial implementation, there can be only one type of enemy)

5. Client-side Game Display: The contract should allow the client-side to display the game. The contract can advance one round of the game per block but can send messages to the client regarding all enemy movements.
Alternatively, you can use delayed messages to display real-time zombie movements by setting their speed (for example, 1 block equals 1 move). In this approach, the contract can use a timestamp or block number to determine the current game round. It can calculate the positions of the enemies based on their speed and the elapsed time. The contract can then send messages to the client, providing information about the updated positions of the enemies.

**4. Hearthstone**
**5. Checkers**
Hackathon Task:

Develop a blockchain-based game of checkers where two players can compete against each other.

<center>
<img src="https://hackmd.io/_uploads/SywsAsv8h.png" width=200>
</center>

The contract should include the following requirements and functionalities:

1. Game Board: The contract should have a representation of the checkers game board consisting of cells. Each cell can be empty, contain a white player's checker, or a black player's checker.

2. Player Moves: The contract should track players' moves and update the state of the game board based on their moves. All moves should be saved in the contract for verification and reproducing the checker positions.

3. Leaderboard: The contract should maintain a leaderboard where players can see their results and positions in the rankings. The ranking can be based on wins, losses, or other criteria.

4. Betting: The contract should enable players to place bets on the outcome of the game or the victory of a specific player. Bets should be encrypted to ensure the confidentiality of betting information until they are revealed after the game concludes.

5. Decryption of Bets: After the game finishes, the contract should have a mechanism for decrypting the bets and determining the winner based on the game's outcome. Decryption should be performed using specific protocols or algorithms to ensure the security and unavailability of betting information during the game.

6. Player Management: The contract should support functionalities that allow players to register, manage their data (such as nickname and wallet address), view their results, and interact with the game.

**6. Tic-tac-toe**

Design and implement a blockchain-based Tic Tac Toe game with betting functionality.

<center>
<img src="https://hackmd.io/_uploads/rJIK1luL2.png" width=200>
</center>

The explanation of the game mechanics for the blockchain-based Tic Tac Toe with betting:

1. Game Setup:
- The game is played on a 3x3 grid, divided into nine sectors or cells.
- Each sector can hold either an X or an O symbol.
- The game uses a card deck consisting of 52 cards, with 26 cards displaying X and 26 cards displaying O.
- After each round, the card deck is shuffled to randomize the order of the cards.

2. Betting Mechanism:
- Players place their bets on either X or O symbol before the game starts.
- Each player can choose their preferred symbol and make a bet accordingly.
- The bets are made using cryptocurrency or tokens, which are stored in the smart contract.

3. Gameplay:
- The game begins with an empty grid.
- Cards are drawn from the shuffled deck and placed on the grid, one at a time, until a winning combination is formed.
- The winning combination is achieved when there is a line of three identical symbols (X or O) horizontally, vertically, or diagonally.
- The player whose chosen symbol (X or O) completes the winning combination is declared the winner.

4. Payout Calculation:
- If the winning combination consists of X symbols, players who bet on X receive a payout proportional to their bet.
- The payout is calculated based on the total bet amount placed on X and the ratio of the individual player's bet to the total X bets.
- Players who bet on O and players who did not win receive no payout and lose their bets.

5. Smart Contract Functionality:
- The smart contract records the bets made by players and the chosen symbols.
- It manages the shuffling of the card deck and the placement of cards on the grid.
- The contract determines the game result and calculates the payouts accordingly.
- Payouts are automatically distributed to the winning players' addresses.

6. Leaderboard and Statistics:
- A leaderboard can be implemented to track players' betting successes.
- The leaderboard ranks players based on their winnings or win rate.
- The contract updates the leaderboard after each game, considering the payout received by each player.

7. User Interface:
- The game should provide a user interface where players can place bets, view their current bets, and check the game's progress and results.
- The interface should display the grid with the symbols as they are placed during the game.
- Additionally, the interface can show the leaderboard and relevant statistics for players to track their performance.

## Services
**1. Messenger**
#### :pencil2: Task:
Developing a blockchain-based messenger using the Gear protocol.
The Gear protocol is based on the actor model, which allows users to interact directly with each other without the need for smart contracts. To send and receive messages, you will need to use the [gear-js](https://wiki.gear-tech.io/docs/api/getting-started) library.
The example of sending and receiving message is provided [here]().

**Encryption of Messages**: To ensure the confidentiality of messages, cryptographic encryption methods such as asymmetric encryption using public and private keys of users can be employed. This way, only the intended recipient will be able to read the message.

**User Interface Development**: Creating a user-friendly interface for the messenger will enable users to easily register, send, and receive messages.

**2. File sharing platform**
#### :pencil2: Task:
Develop a file sharing platform where users can upload files to IPFS, send IPFS links in blockchain messages to recipients, and ensure encryption of file contents.

To accomplish this task, you need to follow the steps below:

1. Uploading Files to IPFS:
Implement functionality that allows users to upload files to IPFS. You can use the IPFS API or relevant libraries that facilitate interaction with IPFS.

2. Encryption of File Contents:
Employ asymmetric encryption using the public and private keys of users to ensure the confidentiality of file contents. This way, only the intended recipient will be able to decrypt and read the file.

3. Sending IPFS Links to Recipients:
Develop functionality that enables users to send IPFS links to recipients through blockchain messages. This can be accomplished by including the IPFS link in the message and sending it to the intended recipient's address.

4. Decryption of File Contents:
When a recipient receives an IPFS link, implement functionality that allows them to decrypt the file contents using their private key. This will enable them to access the decrypted file on their end.

5. User Interface Development:
Create a user-friendly interface for your file sharing platform. Users should be able to upload files to IPFS, obtain IPFS links, send them to recipients, and handle encryption and decryption of file contents.

## DAO
**1. No-code DAO**
No-Code Platform for Launching DAO

#### :pencil2: Task:
Develop a no-code platform that enables users to easily create and launch a Decentralized Autonomous Organization (DAO). The platform should provide a user-friendly interface that allows individuals or groups to set up their own DAO without requiring coding or technical expertise. The platform should automate the process of creating the DAO smart contract, configuring governance parameters, and deploying it on a blockchain network.

Requirements:

1. User Registration and Authentication:
- Users should be able to create an account and authenticate themselves on the platform.
- Implement necessary security measures, such as encryption and secure authentication protocols, to protect user data and ensure secure access to the platform.

2. DAO Creation:
- Provide a user-friendly interface to create a new DAO.
- Allow users to define the name, purpose, and initial settings for their DAO.
- Enable customization of governance parameters, such as voting mechanisms, voting weights, and decision-making processes.

3. Smart Contract Generation:
- Automate the generation of a smart contract for the DAO.
- The smart contract should include necessary functionalities, such as membership management, voting, proposal submission, and execution of decisions.
- Implement code templates or pre-defined modules that users can customize based on their DAO requirements.

4. Governance Configuration:
- Enable users to configure governance settings for their DAO.
- Provide options for different voting mechanisms (e.g., simple majority, quadratic voting) and quorum requirements.
- Allow users to define roles and permissions within the DAO, including administrators, members, and moderators.