A quick perusal of the documentation suggests that I’m going to need a better grasp of the unity event system to get my handling of VR controller raycasting working as I’d like.

My stars (and anything else that wants to be responsive) will need to handle input events and thus detect when a ray touches the construct (and stops touching it). This should allow me to do the sort of ‘hover text’ I want. I’ll likely try to work this up tonight and get my inflating stars code working with the DayDream (and perhaps the Vive as well).

I’m still wishing for a decent solution to modularity that would let me keep the common assets between the three platforms I’m interested in separate enough to make sharing them easy.

I’m currently maintaining three divergent versions of the code and assets with each configured for a different system. As the game rules implementation develops, this is going to become hard to support.

I just pushed an update to github that detects mouse over of stars in the game screen and temporarily bumps the size of the star up by a factor of eight (to show you pointed at it). I’ve also got some other minor bits working such as finding a script on an object given the GameObject .

I need to add code to read in the star names file. I also want to make the DayDream pointer do this same thing to stars you point at. In the longer run, I expect to add a UI panel that displays additional information about the star when you point at it and may very well magnify the size of the star and any associated information at the same time.

Now on to seeing what I can see with DayDream…

Now I’m stitching in some game logic and properties related to game play. Still need to get the systems loaded from the static stuff I’ve added and start building some game play but it feels like things are moving at a decent clip.

I’m also going to be looking at keeping some of the game logic in external, non-game assemblies. Being able to pull in external code that can be unit tested and perhaps even deployed in other areas is useful.

Hoping to get the basics wired in and then get back to interface work. I need to get the VR controls started. A user should be able to switch perspectives between several fixed camera spots with the controller. They need to be able to get a basic view of the state of the board from a distance and be able to view full details of a given star by pointing their controller at it.

• View basic star information available to a given player from a distance.
• Assemble a fleet (if fleet markers are available) from ships present at a star.
• Task an existing fleet with going to another system.
• Allocate this turn’s production to construction or research.
• Side effect of the above, move population from a planet surface to colony transports.
• Check transit time from one star system to another.
• See beacon area of effect for your existing beacons.

I’m now looking to store static text (potential names to be selected randomly, object configurations, etc.) in an accessible unity resource/asset. I want the game to access and load this information and the information to be packaged as part of the game after a build (i.e. in the DayDream *.apk file that gets deployed to the device).

Got it…text asset in a resources folder. My list of star names is now in place. Now I need to shuffle them and associate them with stars and (hopefully) display the names near each star. Ideally I want the name tags to always be positioned so that the normal of the tag passes through the camera and the vertical axis of the label tag passes through the associated star with a fixed distance maintained between the bottom edge of the name plate and the center of the star. Ideally the top of the name plate would be ‘up’ to the viewer as well. I’ll have to look into enforcing these constraints once I’ve gotten any sort of name tags working 🙂