Baseline happiness is 100 up to 150 down to 50
industry starts at 25
food and culture start at 10
10 pop is supported by 1 food/culture
industry 23 hour cooldown from use
reduce starting population from 1000 to 100
reduce the population supported by 1 culture or food from 100 to 10
replace "Farms" with "Farm"
change to: let population = 1000 + (RealmBuildings.Housing * 75) + (RealmBuildings.Hamlet * 35) + (RealmBuildings.Farm* 10)

load_troop_costs

The function is throwing an error when more than 1 troop is built. Suspect it is due to the loop of the struct.

I'd like to propose a pattern:

State contracts shouldn't have any externally callable (@external) state modifying functions; state modification should happen only through functions in Logic modules. The Logic modules should import internal state modifying function and call them directly and not invoke State functions via interfaces (like in this example).

TBH I just came up with the idea while doing a code review, so I haven't fully though it through but I'd like to hear the opinions of others. Does it make sense? Is it limiting? Is it 💩 ?

I started a Discussion #49 about a contract header template:

# Contract title
#   Contract Description Line 1
#   Contract Description Line 2
#
# License

Here are the files I didn't feel confident in writing the title/description for. It's 3 lines total so should be pretty straightforward:
database/Storage.cairo
interfaces/IStorage.cairo
interfaces/ixoroshiro.cairo
utils/library.cairo
L03_Buildings.cairo
S03_Buildings.cairo
L05_Wonders.cairo
S05_Wonders.cairo

https://github.com/BibliothecaForAdventurers/realms-contracts/blob/3a92f96a8c9094c7ec34c0a2f90fecaa5bef5cad/contracts/settling_game/utils/game_structs.cairo#L168

Currently, upgrade_resource function will allow the upgrading of any resource.

It should revert if the attempted resource does not exist in the realm

For reasons that do not need much explanation, this repository will need a robust security policy.

Let's discuss and potentially bounty this out.

Change contract names to have no number as the beginning character

Docker container needs to be updated to include:

• Protostar
• Foundry

Once this is done we can set GitHub actions to run the protostar tests

Working on frontend integration of L2 contracts for testing Realms bridging and settling processes (and in future C&C and Loot distilling)- and the rest of the ecosystem (indexer, subgraphs etc) would require a shared Goerli (L1) deployment of the following (ideally with contracts verified on etherscan and referenced in the repo somewhere):

721 contracts

• Realms (@lordabrax think you might have one already or can start fresh)
• Loot
• GA
• Crypts & Caverns

Bridging/staking contracts

• Journey
• Carrack
• Bridge functionality

Docker container needs to be updated to include:

• Protostar
• Foundry

Once this is done we can set GitHub actions to run the protostar tests

For technical users a CLI is the faster way to interact with the contracts, so we should embrace this and build a beautiful CLI tool for interacting with the game. This doubles as a quick interface to prototype changes as the game evolves.

Ability to stake and unstake multiple realms in one transaction

bin/compile needs to be updated to account for account contracts

As the project has developed we have narrowed down the most elegant way to manage the game modules.

The new structure is:

Core:
settling_game/modules/module_name/module_name.cairo

Library:
settling_game/modules/module_name/library.cairo

Currently, all new modules are following this pattern, however, the original modules have not been reformatted to this.

This task involves migrating/renaming the old modules into this new structure.

You will need to:

• Move modules and rename with a new structure
• Update all imports
• Update test imports
• Update deploy script imports
• Add in IModuleName.cairo etc for the interface of that module nested in the folder.

Resources must be claimed before upgrading, otherwise, an unfair boost is activated.

Unsettled realms give a very large figure for available resources:

For user account page - require functions to claim/view all claimable resources per wallet (current is per realm id)

Upgrade Resource
Realm_id: 3
Resource_id: 1
Level: 1
https://goerli.voyager.online/event/184426_5_1

Build Building
Realm_id: 3
Building_id: 16
https://goerli.voyager.online/event/184202_9_2

Was a discussion about this.

Do we think this is the best path forward? IMO, I think it is for now as we will try to reuse as much of the OZ implementations as possible.

Perhaps we have a:

openzepplin submodule -> base OZ repo
realms_openzepplin -> imports OZ utils into custom implementations

Thoughts?

We have these magic constants flying around (example) representing module IDs. It's better to use an enum for them, something like:

namespace Modules:
    const Settling = 1
    const Resources = 2
end

I've noticed that the contracts in the settling game use Uint256 as a type for Realm token ID instead of the Cairo native felt type. Do you think it would be possible to change the ID to a felt?

The main benefit of adopting the use of felts is TX cost. I don't think we'll ever be doing any math operations on the token IDs, there's no need to use this type. A Uint256 uses 2 felts internally so the calldata size for a single ID doubles. I know this might still be a tiny saving in a single TX, but the token ID will be used in tons of places and if there's going to be tens of thousands (millions?) of players, in aggregate, through all the TXs, it's going to account for something, right?

For reference, this is how Starkware currently thinks about implementing TX fees.

I deployed a wallet and am trying to play the Realms settling game (mint realms) following the README.

The steps include commands like nile mint_realm but the only realms-related commands I see are:

check_lords      Check balance
check_realms     Check realms balance
check_resources  Check claimable resources
claim_resources  Claim available resources

Let's leverage the power of StarkNets compute.

The current design requires the passing of currency and token reserves into the get_ functions. This is redundant since those values exist in the state and it is extra client calls. Proposing to:

Update to current functions

get_sell_price_with_royalty

• This function should just take a token id and return the current sell price of that token

get_buy_price_with_royalty

• This function should just take a token id and return the current buy price of that token

New functions
get_batch_buy_price_with_royalty

• This would pass in an array of IDs (up to n) and return all the buy prices. This would drastically reduce the calls needed to display in the client

get_batch_sell_price_with_royalty

• This would pass in an array of IDs (up to n) and return all the sell prices.

Needs a clearer explanation of how to launch the container.

Currently, it is nested in the settling game, but the container is relevant to the whole repo so it should be on the index readme.

• Return the full squad on the update of the squad
• Add Realm ids to any state change

Update event:
Combat_step.emit(attacking_id, defending_id, a, d, attack_type, hit_points)

Background
To continue community ownership over the protocol single-sided mechanisms will be put in place where stakers of Lords can earn interest on their deposits. This interest is calculated by the tribute generated from the protocol.

Tribute captured by the protocol

• 5% of all Marketplace fees
• 3% of AMM fees

Half of this tribute should be allocated to the single-sided stakers, who should be rewarded per block according to their % of the total staked amount.

WIP branch: https://github.com/BibliothecaForAdventurers/realms-contracts/tree/fix/formatting

Here are some notes I jotted down. Please discuss if you have any ideas or know what to do.

General

1. Solidity takes its inspiration from PEP8 https://docs.soliditylang.org/en/develop/style-guide.html
   1. they order functions according to visibility:

   constructor
   receive function (if exists)
   fallback function (if exists)
   external
   public
   internal
   private
   

2. Line length: 99?

Interfaces

1. Mix of snake case and OpenZeppelin functions (mixedCase)
2. CryptsIERC721 vs ICryptsERC712?
3. Add naming exception for Logic contracts: IL01_Settling

library

• namespace: CALCULATOR -> Calculator
• natspec priority
• @notice instead of @dev
• implement clip function for get_happiness
• returning asserts

      with_attr error_message("COMBAT_LIBRARY: troop_id cannot be zero"):
          assert_not_zero(troop_id)
      end
      with_attr error_message("COMBAT_LIBRARY: Invalid troop_id"):
          assert_lt(troop_id, TroopId.SIZE)
      end
  

  -> is_valid_troop_id(troop_id)
• library_module:
  • converted into namespace
    • not sure if you can use namespace, because you use initializer
  • removed #@implicit
  • getters don't have @view wrapper?\
  • function such as ERC721_owner_check -> erc721_owner_check
  • check_self -> when does it return 1?
• library_staking:
  • not sure what time_left implies
  • is it a library if it has storage vars?

tokens

• crypts:

  • Crypts_ERC721_Mintable.cairo -> crypts_erc721_mintable.cairo
  • `set_crypt_data(tokenId, _crypt_data), did you set tokenId because it's easier to call via frontend?
  • get_crypt_info -> returns the raw felt, fetch_crypt_data -> returns parsed data, naming could be better

• realms:

  • same remark data/info
  • realm_id -> token_id. Maybe it's better to stay specific, this way we can mix in ids from different token. foo(realm_id, resource_id)

• resources:

  • maybe some added functions that belong to the module library? e.g. check_owner, check_caller etc
  • check_can_action: again the owner+caller check
  • not sure where to put the custom upgrade()

• proposal to change s_realms to staked_realms

utils

• constants:
  • i'm not sure if constants are capitalized
  • make it into a namespace?
• game_structs:
  • TroopId: const Watchman = 1 -> Watchman since it's a const, should we put it in allcaps?
  • the namespace EnvironmentIds is referred to as a struct in the comments, but defined as a namespace
  • maybe we should rename this to namespaces and game_structs, or schemas?
  • right now, we are just using the namespaces in this file as enums
  • moved all the namespaces to constantsx
• general:
  • unpack_data: not sure about docs, also score is a weird name (in return)
  • load_single_cost_ids_and_values: check docs for correctness
• pow2: not sure about license
• template_module:
  • upgrade() here uses Proxy_only_admin(), while in realms_erc721 upgrade uses Ownable_only_owner(). Maybe we should change the function name to illustrate this difference?

Modules

I think it makes sense to keep the underscore and then combine it with CamelCase. e.g. L01_CamelCase. right now we are doing more akin to L01_Camel_Case.

• Arbiter:

  • we need to standardize naming and checking of owner/admin/arbiter
    • Ownable_only_owner() -> only_arbiter()

• L01_Settling:

  • here we import TRUE and FALSE from out constants, but somewhere else we import it from the OZ contracts
  • not sure why _set_total_realms)_settled is private
  • world_state -> realm_state?
  • _set_world_state: caller param unused
  • pillaging: if total_pillagable_days == 0, does the whole raid revert?
  • days accrued -> get_days_accrued? also, return variables names not matching
  • not sure about user_mint arguments

• L06_Combat:

  • uses realm_id instead of token_id (also my preference to be more specific)
  • just some naming conventions: attacking_squad = a = attacking_troops -> settle on 1 name

• Crypts:

  • things such as time calculation and resource claiming is shared with realms
  • not sure about params @ get_output_per_environment

It has come to the point where we should spin out the AMM into its own specific repository to allow easy contribution from outside collaborators.

This would involve the following:

• Moving contracts
• Environment setup using poetry and protostar to manage OZ dependencies
• Python deploy scripts
• Tests (these still need a bit of work for total coverage)
• Keep remote container

New blank repo made here - https://github.com/BibliothecaForAdventurers/ResourceSwap

Expected behavior of 'build_squad_from_troops_in_realm'

• Should concat troops after finding a free slot

Actual behavior

• Replaces entire squad with new input

View function is needed to see all troops on the Realm

To complete the marketplace the following is required:

• complete test coverage
• integration with ERC1155
• Bit mapping of the Trade struct so the cost to trade is reduced dramatically into 1 felt (examples on this technique exist in the core Settling game)
• Bulk buying in one trade of n number of assets

Currently Crypts and Realms share 95% of code to stake/unstake.

Investigate how to abstract this for any future erc721s that will need to mint/stake and read packed data.

1. In main settling game contracts
2. In realms-cli contracts

There are a few hundred minor automatic issues that need resolving.

For sanity checks, we need to clean these up so all new commits can be passed easily.

This is a good first issue for someone looking to jump into the codebase.

• convert happiness into number between 0.5 - 1.5 (min-max)
• pull happiness into resource claim and multiply resource value pre-wonder tax by the happiness rating

This will cap their production or increase their production