I must have missed this comment, so sorry for the year late reply. Pull-out stuff is really very simple. You just create a game object that is mostly off the screen. Then either use the IDrag interfaces to let the user pull the drawer out by setting the position of the drawer in the IDraging callback (you’d probably want to limit the range of motion of the drawer). Or setup a button that “opens” the drawer by setting the position of the object.

Thank you for your reply!

I’m still new to Unity (I’m a hardware engineer by day, so I’m used to programming in VHDL with a little C# and python to make things work in the lab), so a lot of this is over my head. Luckily, I know how to google and now have a starting point to figure this out. Would love to see more games, too!

Also, not sure if you’ve played digital board games on the App Store or Steam, but Terra Mystica there uses “pull-out” drawers for everything. For example, if you want to see the cult tracks, it pulls out from the side of the screen. Another board game does this as well, but I can’t remember which one. Would love if someone (ahem, that would be you) could tell me how that works.

Thanks again!

I’m glad you found the tutorial useful. I’ll consider making a more advanced tutorial, but in the meantime I can give a quick description:

The board in Automobile is made with standard Unity UI elements (almost entirely Image and TextMeshProUGUI) arranged by the built in layout managers (vertical/horizontal/grid layout). Many of the screen elements have custom scripts that are responsible for drawing the GUI to match the current state of the game. Those scripts have public members that hold the GUI components that they are going to manipulate and I use the editor to assign GUI objects to the scripts. I use prefabs for any GUI component that is repeated multiple times on the screen (like I did with the player area in the tutorial). So while the GUI looks complex, it is just repeating the same things I did in the tutorial with a lot more elements and images.

Concordia is a little different but is still similar. Everything outside of the map is the same as Automobile. The map is one large image that I drew in Photoshop by downloading a map of the region and then drawing and coloring in polygons. On top of that map image, I manually placed the cities and roads. Each city is a prefab with a class that does the drawing. The prefab is made up of GUI elements that are turned on and off, colored and have their sprite images set by the custom CityGUI class. The roads are similar. They are a prefab that has a class to draws them. That class scales and rotates the road so that it shows up between it’s two cities. The main difference is in how the model (classes that store the state of the map during the game) is linked up to the GUI. I don’t try to define a map model with data files, instead both the CityGUI and RoadGUI classes have OnStart functions that build up a map model by creating City class instances with links to connected cities, a link to their province, a unique ID and other game data.

Concordia has a couple other complexities for handling multiple maps (I made a scene for each map) and getting the map model constructed before a game is loaded (I broke load up into two parts – load the selected map to build the map model, then load the game play events), but I think that the basic system for building the model out of elements in the scene works pretty well.

Another type of game is Terra Mystica or Settlers where I use Gamelogic Grids to help with the layout of Hex maps. In those games, the map is defined in data files and the GUI is built when the game starts up. I still use prefabs with custom drawing scripts for each map element, but those game objects are instatiated at run time instead of baked into the scene.

Thanks again!