Hi! I'm planning to make visionOS multiplayer app for people in same space(a room). I wanna know that if it's possible to use TabletopKit, Group Activities to create an app that becomes multiplayer(synchronize) with the people who are using it as soon as the app is opened without using SharePlay.

I am working on adding synchronized physical properties to EntityEquipment in TableTopKit, allowing seamless coordination during GroupActivities sessions between players. Current Approach and Limitations I have tried setting EntityEquipment's state to DieState and treating it as a TossableRepresentation object. This approach achieves basic physical properties synchronized across players. However, it has several limitations: No Collision Detection Between Dice: Multiple dice do not collide with each other. Shape Limitations: Custom shapes, like parallelepipeds, cannot be configured. Below is my existing code for Base Entity Equipment without physical properties: struct CubeWithPhysics: EntityEquipment { let id: ID let entity: Entity var initialState: BaseEquipmentState init(id: ID, entity: Entity) { self.id = id self.entity = entity initialState = .init(parentID: .tableID, pose: .init(position: .zero, rotation: .zero), entity: self.entity) } } I’d appreciate any guidance on the recommended approach to adding synchronized physical properties to EntityEquipment.

The sample code project Tabletopkit Sample found at the article Creating tabletop games here fails to compile with the following errors in Xcode 16 beta 6. error: [xrsimulator] Component Compatibility: Billboard not available for 'xros 1.0', please update 'platforms' array in Package.swift error: [xrsimulator] Exception thrown during compile: compileFailedBecause(reason: "compatibility faults") error: Tool exited with code 1

Is it possible to join a TabletopKit Seat while using the VisionOS simulator? Seems in the simulator, I'm able to interact with the board's equipment as the floating simulated camera with a PlayerID, but none of my seats have PlayerIDs associated with them.

The TabletopKit sample app builds fine with Xcode 16 beta 1. https://developer.apple.com/documentation/tabletopkit/tabletopkitsample I updated to the new beta 4 and downloaded an updated version of the Tabletopkit sample code but am now getting this error. Tabeletopkit Sample 1 issue SwiftUI.ToolbarContent:3:51 Main actor-isolated static method '_makeContent(content:inputs:resolved:)' cannot be used to satisfy nonisolated protocol requirement Add '@preconcurrency' to the 'ToolbarContent' conformance to defer isolation checking to run time '_makeContent(content:inputs:resolved:)' declared here If I go back to beta 1 it still builds OK. I tried its suggestion but it still won't build. Is there a workaround? I didn't see it listed.

Hi, I've been implementing a tabletop game over the last couple of weeks. One thing that I'm struggling with it getting an EntityEquipment to render. I've followed the instructions in the documentation: https://developer.apple.com/documentation/tabletopkit/entityequipment But still no luck. Any insights what I might be missing are highly appreciated. Note: I've also watched the WWDC24 talk https://developer.apple.com/videos/play/wwdc2024/10091/ several times and downloaded the example but while the pawns render in the example perfectly. In my own implementation of a pawn nothing renders.

Can a TabletopKit game with a variable number of players also have a variable number of AI, each playing a specific position? For example, a game that can handle 3-7 players, being set up for a specific game where 4 of the players are real, and an AI plays 2 other locations? The Kit appears to be setup to only be able to handle real (human) players. Thank you!

Does the current version of TabletopKit support having two or more game players to be at the same physical location? In these cases, the players would not want to see a Facetime persona around the table but instead should be able to see the physical player. Any other remote players would be able to see the personas of those players since they are not at that location. There are a couple of issues in this scenario (shared position of the board, players' location around the table, etc.), but they should be solvable. Thank you!