bibliothecadao / eternum Goto Github PK

Goal:

Add a new unit of exchange in the game and find a name of the game currency other than “coins”.
The current implementation would be something useful for temporary testing of such a currency in the game. All implementation and names used to reference it will change in the future.

Problem

Currently we can only do trade of resource against resource but that means that it's hard to find the best price for each resource. Or even people who have the resources you need and are interested by the ones you have.

Solution

Add a new mean of exchange in the game that could temporary reuse the Resource component so that we can both mint it and trade it.

This is where its balance could be shown in the UI.

features

• only 1 hyperstructure per order can be created

• the hyperstructure first needs to be initialized/created by one realm of each order and has a certain cost

• once it's initialized, any realm of that order can send resources to it until a certain amount of resources has been reached

• for the resources to be sent to the hyperstructure, a caravan needs to be sent carrying the resources

• once that amount has been reached, the hyperstructure is considered 100% finished

I think muting the game should be very accessible. It's nice to have detailed volume options nested in the settings menu, but I think there should be a top-level shortcut to mute.

Eternum needs a notification menu. The game is feature rich, meaning there'll be a lot going on at all times, and it's played in a real time, competitive multiplayer environment, meaning losing track of any relevant information may result in significant damage to your Realms. Thus, gameplay-relevant information must always be highlighted and delivered to the player in a pronounced, prominent way, and this way is the notifications menu.

• The notifications menu is player-based, and will deliver only the information relevant for that specific player's empire. It'll have two versions: one with notifications pertaining only a specific Realm (standard setting in the Realms map), and one with notifications pertaining multiples Realms (standard setting showing all Realms in your wallet, in the world map).

• Additionally, a configurations menu should allow the player to customize whichever version of notifications they want to see where, e.g. if the player wants to see notifications for all Realms when in the Realms map or even if they want to pick and choose from their Realms. Ideally that could manifest as a toggle button to show notifications for all Realms even in the Realms map, with the addition of an option to checkmark specific Realms to be shown in notifications. The configurations menu should also have a toggle for dropdowns menus in notifications (show them opened or the default, closed).

• Notifications should not only be closable/dismissible, but new notifications should also be highlighted in the list to indicate they're new. The highlight can be done several ways: background, borders, colours, glow, among others. A new notifications loses its highlight once the player passes the mouse over it.

• Notifications can also be pinned and unpinned.

• Notifications' heading will redirect the player to the respective UI menu for that information.

A first mock-up was already made couple months ago:

Below is the list of notifications needed, with the caveat that as more game systems are implemented into the game (Banking, Crafting, etc.) the list of notifications needed will also expand. The list contains the information for both notification menu types: single Realm and multiple Realms.

• Offer accepted.
  For every time a standing offer is accepted. Notification heading redirects to the Offers menu.

• Single Realm version:
  Contains simply the text "Offer accepted" and nothing else. A dropdown menu will show resources sent, resources received (both individually), Merchants in Caravan, partner Realm, and real time distance remaining in hours.

• Multiple Realms versions:
  Same as single Realm, with the addition of the Realm name in the heading by the side of "Offer accepted".

• Offer proposed.
  For every time someone proposes an offer directly to your Realm. Notification heading redirects to the Offers menu.

• Single Realm version:
  Contains simply the text "Offer proposed" and nothing else. A dropdown menu will show resources sent, resources received (both individually), carry capacity needed, partner Realm, and travel distance in hours.

• Multiple Realms versions:
  Same as single Realm, with the addition of the Realm name in the heading by the side of "Offer proposed".

• Caravan Arrived.
  For every time a Caravan arrives in your Realm. Notification heading redirects to the offers menu, and claim button doesn't redirect, but instantaneously claims the arrived resources. The button greys out and becomes "Claimed" after.

• Single Realm version:
  Contains the text "Caravan arrived" and a "Claim resources" button at the end of the heading space. A dropdown menu will show resources sent, resources received (both individually), Merchants in Caravan, and partner Realm.

• Multiple Realms versions:
  Same as single Realm, with the addition of the Realm name in the heading by the side of "Caravan arrived".

• Labour finished.
  For every time labour production expires on any of the unique resources. Notification heading and button redirect to the labour menu, opening the employ labour/buy tools section for that specific resource.

• Single Realm version:
  Contains the text "Coal labour finished" (with Coal being replaced by the respective resource name) and a "Buy more" button at the end of the heading space. There's no dropdown menu.

• Multiple Realms versions:
  Same as single Realm, with the addition of the Realm name in the heading by the side of "Coal labour finished".

• Food buildings expired.
  For every time farms or fisheries expire. Notification heading and button redirect to the food buildings menu, opening the build section for that specific resource.

• Single Realm version:
  Contains the text "Farm expired" (with Farm being replaced by the Fishery, when applicable) and a "Build more" button at the end of the heading space. There's no dropdown menu.

• Multiple Realms versions:
  Same as single Realm, with the addition of the Realm name in the heading by the side of "Farm expired".

          on my side, when i console.log the burner account here it's always undefined, so below it will always take the master account

Originally posted by @aymericdelab in #71 (comment)

Problem

Currently there are too many graphql request as every time a component with a graphql custom hook gets mounted, a new request is sent.

Possible Solution

Caching of the graphql result, this is a feature that might be available in current graphql-request library but tbd.
https://github.com/jasonkuhrt/graphql-request/blob/e5c8e7f43066f238f96016f8c3b5c6c3cd0141ce/tests/general.test.ts#L310

Notifications should be placed atop each gameplay-relevant feature, of which are five in the current Realms map: Fish, Wheat, unique resources, Market and Caravans.
Although all notifications will have icons and data displayed, different types of features will require a different amount of data, so while notifications should adhere to the same style their body will vary.
All notifications (as many other elements in the UI), must contain tooltips. Notification data will most of the times be presented as numbers, and the context for these numbers should be present as tooltips.
Notification elements will be individually clickable, opening the UI menu for that specific data (unless, of course, all elements lead to the same menu).
Although every notification will have its icon, when space allows additional icons could be made to give extra content to each data element.

Feature list:

1. Resources

For all resources, the icon for the map notification should be different from the resource icon. The map icon is supposed to represent the building that produces the resource, not the resource itself.

1.1 Fish

Notification will show (a) fisheries currently built and producing fish, represented by a single number; and (b) max fisheries that can be built, represented by a single number. Both elements can be displayed together as a “1/20” text.

Tooltips:
(a) Working fisheries.
(b) Total fisheries.

Redirects:
Both notification elements lead to the fish production menu.

1.2 Wheat

Notification will show (a) farms currently built and producing wheat, represented by a single number; and (b) max farms that can be built, represented by a single number. Both elements can be displayed together as a “1/20” text.

Tooltips:
(a) Working farms.
(b) Total farms.

Redirects:
Both notification elements lead to the wheat production menu.

1.3 Unique Resources

Notification will show (a) hours left in production, represented by hours:minutes:seconds; and (b) resource amount left to produce, represented by the numeric value + “left to produce”. (a) and (b) are two different elements that’ll be displayed separately.

Tooltips:
(a) Production time remaining.
(b) Resources in production.

Redirects:
Both notification elements lead to the “buy tools and labour” menu for the respective resource.

2. Caravans

Notification will show (a) average Merchant health; (b) numbers of Burghers and Retainers; and (c) Merchants working and Merchants idle. These three elements will be represented as percentages by default, however they’ll also be able to be represented as absolute numbers or carry capacity available. The last two will be alternative configurations accessible in the client configuration section, where players can change the default. The descriptors and tooltips displayed should also be slightly different for each configuration - in the case of descriptors, absolute numbers and carry capacity should be displayed as the element text + numbers (average Merchant health: 10) , while percentage representation would work best as a bar icon.

Tooltips:

• For percentages
  (a) Percentage of the average health of all your Merchants.
  (b) Percentage of Burghers (free Merchants) compared to Retainers (bought Merchants).
  (c) Percentage of Merchants travelling or with standing offers compared to unassigned Merchants.

• For numbers
  (a) Average health of all your Merchants.
  (b) Number of Burghers (free Merchants) and Retainers (bought Merchants) of your Realm.
  (c) Number of Merchants travelling or with standing offers compared to unassigned Merchants.

• For carry capacity
  (a) Total carry capacity of all your living Merchants.
  (b) Total carry capacity of Burghers (free Merchants) and Retainers (bought Merchants) of your Realm.
  (c) Total carry capacity of Merchants travelling or with standing offers compared to the carry capacity of your unassigned Merchants.

Redirects:
(a) Merchants page.
(b) Merchants page.
(c) “My offers” page.

3. Market

Notification will show (a) Offers available to claim; (b) Your standing Offers; and (c) Offers in transport; all represented by the element text + number. Due to the nature of Offers, (a) should be a temporary element that disappears from the notification when its value is 0, and all three elements should have colour differentiators: every time the value changes the element gets highlighted in a different colour until the player hovers the mouse over it.

Tooltips:

(a) Offers that have completed: you have resources available for claim.
(b) Offers waiting for a buyer.
(c) Offer agreements being executed, resources will be available later for claim.

Redirects:

All notification elements lead to “My offers” page.

There are already a bunch of tests done on the main systems, these were working a couple months ago before there were some breaking changes in Dojo so we need to refactor.
It would also be interesting that you review the way the tests were done and see if we can improve.
Roll Your Own is the other big project on dojo (https://github.com/cartridge-gg/rollyourown). Would be interesting to take a look at how they do their testing.

Current way of doing testing for a system:

1. call spawn_test_world_without_init() from src/utils/testing.cairo, which will deploy a world and register the class hash of all systems and component, but it wont initialise it, this is a trick we're using in testing, because when you init your world in dojo, it means you need to handle permissions between systems and component as well, which we dont want to do for testing.
2. set necessary configs: some values from the world (like the speed of a specific transport unit), are set in specific config components so that we can have modify these to balance the game.

TODO:

• refactor testing.cairo

Systems for which we need to update current tests:

Labor

• build_labor
• harvest_labor

Caravan

• create_caravan
• create_free_transport_unit
• utils

Order (trading)

• make_fungible_order
• take_fungible_order
• claim_fungible_order
• attach_caravan

Currently we are using ChangeOrderStatus to cancel an order by just changing it's status to "Cancel" (status = 2).

We should remove the ChangeOrderStatus system and replace it by CancelOrder. That system would:

• make sure caller is maker
• make sure the order is open (status 0) and not accepted (status 1)
• change status from 0 to 2
• put the maker resources from OrderResource back in maker balances
• remove the caravan from the order and unblocking it

+ add necessary testing

If I try to sort offers using any of the categories it doesn't work. You can see in the image how I've sorted the offers by Exchange rate, but the list remains unchanged with the exchange rate distributed randomly. The same happens for all other headings:

Currently the components are set only after the tx is confirmed on the blockchain and events can be gathered.

We should use optimistic rendering in order to show the result of the tx before it's finished processing.

An example can be found here:
https://github.com/dojoengine/dojo-starter-react-app/blob/main/src/dojo/createSystemCalls.ts#L19

• create a simple 3D model for the hyperstructure that would fit well on the 3D map

New pattern designed here:

https://github.com/dojoengine/dojo-starter-react-app/blob/main/src/dojo/createSystemCalls.ts

As previously discussed, players must be able to create direct offers to a single Realm. This should follow the same flow that creating an open offers does, with the single difference that a field to introduce a Realm address should be available.

This would require the addition of the following UI elements:

• A field to input taker Realm in the creating offer menu. A possible implementation is a toggle with "Open Offer" (default) and "Direct Offer" as the options. When a player switches the toggle to "Direct offer" a field for "Realm number" appears. Player then just inputs a Realm number between 1 - 8000 and creates the offer.
• The partner Realm name displayed for the individual offer in "My offers" tab. In order to preserve space, it can be a simple "To: Realm" text.
• An identifier for each individual offer in "My offers" tab to differentiate open and direct offers. The text for direct offers can be the one above and for open offers simply an "Open" text.

@aymericdelab assigning you too since this is a function of the contract, so it'll probably require Cairo input for integration.

We need to see the entire map on load.

The entire city and all its regions should be visible. This isn't currently the case.
It should also be easy for the player to zoom back out to this overview at any time. Currently, clicking on certain tabs will move the camera in to a region (that's great), and then lock the camera there (not good). The player needs to be able to zoom back out to regain an overview of the whole realm.

When clicking on Show on Map we should switch to the map view with the realm centered in the middle.

Previously we were using the result of the graphql queries to directly query and use the labor data in the components.
We are now using something closer to the patterns used by Lattice by :

1. querying torii and syncing the components using setComponentValue
2. getting the entity values in the components using getComponentValue or useComponentValue

This pattern is what we use in RealmsTradeComponent and should be reproduced in Labor.

This feature is necessary primarily because of the chat menu: it has 0 gameplay utility and for most people it's something they'll just want to check occasionally - some won't check it at all. Right now it's a locked feature occupying a huge part of the screen, blocking actual relevant gameplay information in the Realms map. To remedy that, I suggest we add a feature to minimize this menu, providing the option to remove it from the screen while still remaining easily accessible. It can remain as an icon by the side of the screen while minimized, like this:

Although other menus are significantly more relevant and less intrusive, players still may want to minimize them eventually for a better view of the different screens. Thus, the minimize feature should be implemented in all UI menus (currently chat menu, Realm menu and notifications menu).

• Create figma mockups
• Implement in React
• Connect to contracts

This isn't high priority right now, but eventually we will need custom scroll bars.

The default ones are very distracting

Is your feature request related to a problem? Please describe.
We use optimistic rendering for the game so we already show the result of a transaction in the client before it's confirmed. But the user does not know if that result is definitive or not.

Describe the solution you'd like
It would be better UX to show the user the info but also add some sort of sign/logo/loading somewhere that shows that it has not yet been confirmed.

I was thinking also to have the data blinking until it's settled. Something that would look like this:
https://media.geeksforgeeks.org/wp-content/uploads/20200609161317/screen-capture-11.gif

We need to do a better job at communicating to the player what options they have, what options they don't have and what they need to do to get those options.

For example. right now, a player can click "Accept" on an offer that they do not have the resources to execute. This leads them down to a dead end in the UI. Better to grey out the accept button, and perhaps even add a little "not enough resources" warning label above or next to it.

There are probably other such issues in the client. If you run into an issue of this sort, it would be great if you can comment on it here so that we may keep track of it.

Currently the sub-menus to buy resources have a field to input the number of items to be bought with arrows to increase or decrease the amount:

When the input is limited between a small range - like food buildings work right now - an UI interface like the above isn't a problem since it provides players the tools to quickly find the amount of items they want to buy. In the case of tools and labour, however, it doesn't.

Tools and labour don't have any limit for how much of it can be bought in one go and they won't be always bought at similar amounts. Someone might buy a month of labour for one resource and only a day for another, for instance, depending on the funding they have and their specific needs. When dealing with large amounts the arrow functionality is useless, since increasing or decreasing labour units by small amounts would take a long time, and inputting the number directly would require from the player a lengthy process of trial and error by inputting different numbers until they find the amount they want.

Thus, the current input field for resource production should be replaced by a field that uses a slider instead of arrows. Not only does this solve all the above problems, but it also better informs the player about how much resources they have available to buy any specific labour. If someone wants to buy coal labour, for instance, they can instantly know the labour amount that'll cost 30%, 50%, or 100% of their resources by moving the slider around, since the max range for the slider will be determined by the max quantity of vault resources that can afford that labour production.

A slider icon would look like this, with the design be adjusted for the client, of course:

This happens when clicking and dragging on the 3D canvas, passing over an UI element.
We should make it impossible to select anything, basically. There might be exceptions to this eventually, but I can't think of one that currently applies.

Currently menus have fixed places on-screen, meaning when you open several of them they appear in the same place atop of each other:

While some of these menus don't need to be used together, some of them do, thus this menu stacking is an issue. There are several ways to solve this, a solution I thought of was to simply have the first submenu opening at the top left, and then having each subsequent menu opening below the last one until the end of the screen, and then beginning a new column by the right. That would probably require some adjustment of submenu sizes to make some dimensions are a bit more standardized.

What do you think @r0man1337?

As the image above shows, I get a warning "INCREASE THE AMOUNT OF UNITS" even though 1 unit already has about 33 times the carry capacity to execute a trade of 3kg worth of resources. Something is not right there.

To group concerns in space, we should move these labels where they belong: Right underneath the realm header.

Black Mirror Designer already did a little illustration of how that might look:

Realm name-bubbles expand when the cursor hovers over them, and contract when cursor moves away.

Minor annoyance- while hovering over one realm, try moving the cursor to the next. Often the contraction causes you to skip the next and hover over the third instead.

• add sounds
• realm background freezing a bit when executing transactions (can see it when creating an order for example)
• implement the new "Incoming order" component
• create new offer: show correct balances when selecting resources
• create new offer: display loading spinner after creating new offer (similar as in accept offer popup)
• caravans: implement new compnent design from figma
• add notifications
• implement sorting and filters
• implement "show on map" button
• update Realm popup header to last figma changes
• implement settings and login popups
• fix github issue from palomato: #30
• accept offer: balances not showing
• move queried data to zustand store, to have persisting state between tab switches
• add "hire caravan" feature, without creating an offer
• disable "Accept" button if you haven't enough resources
• fix warning message logic in creating caravan
• fix "No Labor" message if you bought only one hour of labor
• add "pulse animation" placeholders when loading
• make "secondary tabs" sticky to top

Some districts in the Realms model (ranch, labour and market to be exact) are already integrated with the client, being reactive to mouse hovers and displaying information, although some functionalities are still missing. There are entire districts, however, that still need to be integrated. To be implemented:

• Not only clicking on the respective UI menus should zoom the camera to the each map district, but the other way around should happen as well - it's in fact the more important reason for this feature. Players should be able to easily open the respective UI menus in order to do actions by simply clicking in the corresponding map district. For instance, when a player clicks on the Market district, the camera should zoom in on the district and open the Market UI menu so that the player can manage the game systems represented by that area.
• Fisheries need to be integrated. Their menu redirect would be the the resource list showing current fish production stats with the sub-menu for building fisheries opened at the side.
• Farms need to be integrated. Their menu redirect would be the the resource list showing current wheat production stats with the sub-menu for building farms opened at the side.

In MUD you can use defineQuery to subscribe to a query that returns a set of matching entities.
This would allow us to stop running these queries in 1 second intervals like we do here:

      const entityIds = Array.from(
        runQuery([HasValue(Position, { x, y }), Has(CaravanMembers)]),
      );
      setEntityIds(entityIds);

Ideally we could have that in a hook.

We should move all Account creation to Burner wallets rather than the built-in PK of Katana

Upgrade contracts to new Dojo version

{/* IDK why, but tailwind cant handle dynamic custom classes if they wasnt used before */}

@r0man1337 you need to add them to tailwind config in order for them to be included

When querying certain entity ids in the client, we are currently using a naive approach like this one:

const set1 = getEntitiesWithValue(Status, { value: 0 });
// get trades that have maker_id equal to realmEntityId
const set2 = getEntitiesWithValue(Trade, { maker_id: realmEntityId });
// only keep trades that are in both sets
const entityIds = Array.from(set1).filter((value) => set2.has(value));

since getEntitiesWithValue can only do filtering on one component at a time, we need to make multiple queries.

This can actually be improved using runQuery from mud. Here below is an example:

// If the first query fragment is "negative" (Not, NotValue) you need to provide an initial set of entities as the second parameter
const initialSet = new Set(component.entities()); // or world.getEntities() if you want to filter over all entities
runQuery([NotValue(Component, { value: X })], initialSet);


// If the first component is a "positiive" fragment, you don't need an initial set
runQuery([Has(Component1), NotValue(Component2, { value: X })]);

The camera shouldn't be able to move so far away from the city-centre on the horizontal plane. It leads to rendering issues at the screen edge and the model looks terrible outside a certain range.

We're currently using the main master account to do transactions in the world.
We want to switch to having each user use their own wallet for the tx through the implementation of burner wallets.
But currently since we haven't setup the approvals for systems to write the component values, only main master account can call systems.

Approving a system to write on a component is an entrypoint in the world contract, called "grant_writer".
https://github.com/dojoengine/dojo/blob/857cbc3db064fed11cf74aaaf53b8e3e3858ed21/crates/dojo-core/src/world.cairo#L214

The goal is to create a script that would authorise the systems to write to the necessary components.
Something like ./contracts/scripts/approve.sh
That script could also be called in the ./contracts/script/set_config.sh file as well.

• 1. Missing filters

Most of the market filters seem to be missing from the UI, currently there are only Resources and Orders, but we still need Travel time, Coalition, Trade Routes, and Trade Ratio. Also, Resources need to be split up between what you're selling and what you're buying.

Part of previous discord discussion about it: https://discord.com/channels/884211910222970891/989804511868620800/1109796133481488424

How it currently is:

UI mock-up with a few more, but still not all filters:

• 2. Marked filter icon

There are also some other minor issues with filters. The marked X icon is supposed to represent when a filter is selected, so players can easily change their existing filters. Right now it shows when a filter menu is open, which serves no purpose since the players don't need a visual cue to know the menu is open; the menu itself takes care of that. This needs to be changed so the X icon only and always appears when that specific filter has one or more options selected.

You can see the filter marked with the X when there's no resource selected, but the menu is open:

And here you can see the filter unmarked when the menu is closed, but there are resources marked to be filtered:

Seeing the purpose of the icon is to show a filter is currently selected, I'd also suggest changing the X icon for a checkmark icon, the alternative version of the two sketched out by Amaro:

• 3. Filters aren't working

Also, the filters do nothing right now, they're purely decorative. When I try to filter offers by resource or Order nothing happens, the list remains the same. We need to implement their functionality.

As can be seen here, I have offers filtered only for Order of Power, however the offer list remains unchanged showing me all offers from all Orders. The same can be replicated with the resource filter:

The first iteration of trade routes. This would create a route between the two Realms.

Contracts

System:

create_route
Inputs - position_x, position_y

Components:

Route

• entity_id - uuid
• position_x
• position_y

Usage

• entity_id - uuid
• number_uses

Owner

• entity_id - uuid
• address

When I click this "X", nothing happens. The settings menu stays present.

We now have entities/components subscriptions in Torii.
In the client the idea would be to be able to subscribe to the following components:

https://github.com/BibliothecaDAO/eternum/blob/main/client/src/dojo/contractComponents.ts
(not the config ones)

And update the internal tables using setComponent every time there is a change.

I think best would be to create a componentSubscription.ts file in dojo folder then instantiate the subscription in setup.ts.

Just get a loading spinner, that's all.

Here are the errors in my console, just in case it is relevant:

Uncaught (in promise) Object
index-1decbfba.js:5634 Uncaught (in promise) eb: 25: Transaction hash not found
    at FP.errorHandler (https://alpha-eternum.realms.world/assets/index-1decbfba.js:5634:132151)
    at FP.fetchEndpoint (https://alpha-eternum.realms.world/assets/index-1decbfba.js:5634:132284)
    at async create_realm (https://alpha-eternum.realms.world/assets/index-1decbfba.js:5645:332803)
    at async n (https://alpha-eternum.realms.world/assets/index-1decbfba.js:5623:10707)
DevTools failed to load source map: Could not load content for chrome-extension://dlcobpjiigpikoobohmabehhmhfoodbb/inject.js.map: System error: net::ERR_BLOCKED_BY_CLIENT
DevTools failed to load source map: Could not load content for chrome-extension://dlcobpjiigpikoobohmabehhmhfoodbb/inpage.js.map: System error: net::ERR_BLOCKED_BY_CLIENT

Every non-obvious element should contain tooltips, players should know the function of everything without having to leave the game screen. There are some clear cases where tooltips are missing/partially implemented, like for resources:

Resource name appears when hovering mouse over stored resources.

But they do not appear when hovering mouse over resources on market.

Besides these cases of partial implementation, there are also plenty of places where tooltips are needed in order to explain to the player what that specific feature/section/button does, necessary for providing an uninterrupted play session, easy on-boarding of new players, and seamless user experience. List below:

• Every resource icon in the client should display the respective resource name as a tooltip.
• Every Order icon in the client should display the respective Order name as a tooltip.
• Labour menu icon should display "Manage all of your Realm resource production here."
• Resources sub-menu icon should display "Look at your current production, or increase it by buying labour or buildings. Don't forget to harvest your resources."
• Trade menu icon should display "No Realm is self-sufficient. Trade with other Lords to get the resources you need."
• Offers sub-menu icon should display "Create new offers or examine offers made exclusively to you. Watch as offers are executed, and claim your resources when they arrive."
• Market sub-menu icon should display "Offers from all over the world are found here. Trade with your fellow Lords."
• Caravans sub-menu icon should display "You can only trade resources if there are Caravans to carry them. Manage your Caravans here."

There are more tooltips to be added that involve changes to current client. Once these changes are implemented more tooltips will be added to this list or introduced through other GitHub Issues (as is already the case for some).

The buttons for building things and accepting offers are no longer clickable if the player doesn't have resources. This is good. To improve UX a little further by giving the player more information as to why some options are not available. I suggest the following two improvements:

1. Adding a greyed-out button style. Right now "Build" button doesn't change style when it becomes unclickable, and the "Accept" button turns orange. Orange is better then no colour change, but I would prefer something less vibrant, more grey, to really emphasize that a button is unclickable. A colour like #766756 perhaps. This colour is already used in other places, like in this font and border:
   

2. Adding a red label next to the greyed-out button that says "Insufficient resources". Similar alerts could be used in other circumstances.

The happiness and defensive capability indicators for the Realms are displaying incorrect states:

1 . Defence is not a binary state, and "vulnerable/not vulnerable" doesn't say much. Defensive armies can range from 1 to 30 battalions, so if you build 1 battalion you're still quite vulnerable, while if you build 20 you're neither vulnerable nor overly secure. Defence should be a % indicator ranging from 0 protection to 100% protection - I quite like the idea of a ring representation for the percentage, but maybe you think another design works better @Amaro-Koberle:

The slightly different colours represent the percent of light battalions/heavy battalions, something that should be indicated by hover text: "This Realm has 18 Defensive Battalions stationed, divided in 6 Heavy and 12 Light". This indicator will be blurred in the present version, but we should have it ready either way.

2 . While happiness has indeed a base number and it's a binary effect, its gameplay effects aren't. It matters less if you're happy or unhappy and more how happy or unhappy you're. Thus, this indicator would be best represented as a number below or above 0, ideally accompanied by colours and a descriptor state. For instance:

Below -30 "In despair" Red Gradient 4
-15 to -30 "Very unhappy" Red Gradient 3
-5 to -15 - "Unhappy" Red Gradient 2
0 to -5 - "Discontent" - Red Gradient 1
0 to 5 - "Content" - Green Gradient 1
5 to 15 - "Happy" - Green Gradient 2
15 to 30 - "Very Happy" - Green Gradient 3
30+ - "Exuberant" - Green Gradient Gradient 4

Numbers are placeholders. Colours are examples, @Amaro-Koberle will know more about colour combinations than I.

The happiness UI will be further changed in the future once I design the system for it, but these modifications will most likely remain.

These decorative flourishes are nice, but right now they draw too much attention in an already visually busy UI. I would reduce opacity on these elements by roughly 70% to make them compete less with more gameplay-relevant UI elements.

Problem

Resources should be centered around the ratio number.

As previously discussed, we need to make custom resource icons. To repeat something I previously said in discord: the minimalist ones we have now are hard to memorize and thus not very user friendly since you need to consult a reference sheet to keep up with them.

Wood, coal, silver, gold, copper, all gems... several of our resources have imagery that's very identifiable and should make for instantly recognizable icons. And for the completely fantastical/made up resources it shouldn't be hard to create something unique in colour and shape that makes them very identifiable too - you look at it once, you remember.

Describe the bug
Some menu's don't show completely when using small screens

To Reproduce
Steps to reproduce the behavior:

1. Reduce browser window
2. Got to site and settle realm
3. Click market
4. Click create new offer
5. The menu won't appear fully

Expected behavior
The menu should show completely irrespective of window size

Screenshots
https://cdn.discordapp.com/attachments/989804511868620800/1149665801851371571/Screenshot_2023-09-08_at_12.18.14.png

Desktop (please complete the following information):

• OS: MAC
• Browser chrome