Thousands of products. Less to send.

A bigger mall gives the connection more work

AUREL and VEKTOR contain 3,685 products in Amber Gallery. Joining a session means more than placing another worker in the corridor: shelves, loose boxes, carried products and cart cargo all need to belong to the same world. How we send that information matters especially when the host has limited upload capacity.

v0.29.1 focuses on that initial and late-join workload. There is no new storefront to point at; the work asked of the connection to share the existing mall is smaller. The shelves are already full enough without giving the send queue the same treatment.

Share the differences from a common starting point

The game now compares the host’s starting product layout with the joining player’s. When they match, the joining player reconstructs that starting world from local data, and the host sends only product states that differ from it. A moved box, a changed shelf or a product loaded onto a cart is then transferred in its current state.

This does not require everyone to start in an empty or perfectly organized shop. A disordered starting layout generated with the same settings can match too. A full-state transfer remains available when the starting baseline does not match; content with different shelf and placement geometry is treated as incompatible.

Zero product overrides does not mean zero connection traffic. Player, control and other world information is still sent. The more products that have changed from the starting layout during a shift, the more differences a late joiner needs to receive.

What the measurements show

In the recorded corridor test, 128 of 1,153 products differed from their starting state. Product synchronization message data fell from 44,072 bytes to 4,884 bytes, a reduction of about 88.9%. That figure applies to product transfer in this example, not the whole game’s internet usage or end-to-end joining time.

Fresh 3,685-product Amber Gallery worlds generated with 0%, 25% and 100% starting disorder needed no product overrides when both sides shared the same starting layout. Full product message payloads for those examples were 160,039, 157,276 and 148,984 bytes respectively. Here, 100% describes the initial disorder setting, not a shift in which players have changed every product.

Ready means the world has been applied

Join completion now checks the transfer identity, expected product count and unique product records. The joining player acknowledges readiness after applying the world state. Existing checks also protect actions made by other players during the join from being rolled back by an older starting-state packet.

On the EOS side, reliable state packets rejected because the send path is temporarily full stay in an ordered queue and are retried. The queue has memory and time limits; persistent blockage produces an explicit disconnect instead of silently losing important world state. The aim is to keep product state consistent under load.

The test team’s next shift

The release report records 146 passing focused development tests and 23 passing process reports across seven local runtime suites. The main network scenarios used 100 ms of simulated latency, a 32 KiB/s upload limit, and loss/reordering of unreliable traffic. Throwing and catching, cart cargo, concurrent and late joins, save/resume and four-player room flows were checked. A single-computer room lifecycle check against the live EOS service also passed.

The next priority is to repeat those situations on separate computers and internet connections. Have someone join while another worker is carrying products or a cart holds cargo, and check that everyone sees the same shelves, boxes and load. Start a new room with a different computer as host, including a connection with lower upload capacity. Separate-computer EOS gameplay and 12-player long-session acceptance remain open.

The network display now shows remote connection data in KiB/s and excludes the host’s local loopback. This measures application transport data; it is not a total internet traffic counter including protocol headers and retransmissions.

Use the same 0.29.1 package

The release moves to network protocol 24. Everyone in the room must use 0.29.1; it cannot share a session with 0.29.0. Save schemas have not changed in this patch. Successful Windows builds now add validated EOS settings and guides before preparing the ZIP and checksum. Keep the supplied eos-client.json beside the application in a configured test package; players do not need to prepare those settings themselves.

This first-transfer product work is implemented. Filtering ongoing movement traffic by each player’s area, further player/cart compression and a scheduler for total upload are separate development steps. Access to test packages is managed through the Playtest area. When reporting an issue, include version 0.29.1, the map, player count, host/client role and steps to reproduce it.