Currently just finished getting up to speed on powershell, now looking at PHP/MySQL back end coding. I want to become more familiar with React for SPA/front end work (particularly here for management of persistent storage of web service content) and need PHP/MySQL to create the back-ends for both VR code and other front end stuff.
I’m also looking at bit at WebGL and supporting libraries as being able to build out really interactive and graphical front ends for things. Lots to do and lots to learn 🙂 Been buried in work stuff for several years and now that is wrapped up and I’m just helping out with small stuff on other products I may have time to chase some of these home projects.
Continuing to read and watch Blender training information.
Blender
Getting a bit distracted by pulling in blender 2.8 build source code. I’m now a bit curious about the internals and may let myself be distracted by that now and again. Certainly planning to see if I can run a local build on Jabberwock…Chaos upstairs has path issues that I’ll need to resolve before I can do much on that front. One of the nicer things about having more than one build-capable machines around.
Unity
Looking at a few things in the immediate future
Get text working. Hover text labels over stars that always face the viewer with at a minimum the name of the star.
Build star gate model(s) in blender and import them into unity and then place gates in the view.
Build a simple information viewing panel in game and support star selection where the information for the selected star shows on the panel.
Build a simple mechanism for saving game and loading games. Need a persistence format for game data.
Look into adding simple feedback sounds to the game. At least a noise when a selection is changed in the star display.
Thinking that a VR game of life implementation might be fun and relatively straightforward. Perhaps on a sphere would be even more interesting…closed universe.
Also wondering whether a three dimensional version could be jugged together.
More of a fun toy than a real game, but perhaps fun to play with.
Need to think about how to map the quantized grid from a flat version into spherical layouts. Might make sense to do something with continuous placement with volumetric cells that bump aside any too close and attract cells that are near enough to aggregate. Would be similar but a bit different.
Orbital Simulation
Playing with a setup where masses could be placed in three dimensional space and then items released and run the simulation forward.
Could be fun to play with looking at the orbital mechanics issues .
Could move forward to a game where orbital combat is run through. Place vessels with real-ish engines and weapons. Implement UI and interaction to manage motion and allow planning and execution of maneuvers .
Interesting way to play with VR UI approaches if taken moderately seriously
The player is standing on the ground with a dark sky overhead. Controllers are used to cue weapons fire.
Inbounds are shown with location, trails showing previous track and various information attached as they move…possibly current velocity and acceleration vectors attached.
Player points at desired target and cues in a weapons system on that target (or targets sensors perhaps to gain more information)
As part of building the front-end to the shared web side aspect of the cluster game, I’m starting to lay out the RESTful interface to the database at the back-end of the server side.
I’m looking at several main categories using query parameters to filter results on aggregate areas.
players Returns a list of player names and ids. Details of a specific player can be retrieved (and changed) by accessing the player by player id as a sub-resource. Permissions do apply here…a normal player can only view or edit the details for their own information. An administrator can view and change information for any player.
id (immutable after creation)
name – Unique, human readable user name
email
is email public
password (settable only)
active
date joined
date last activity
games Returns a list of games in the database. With query parameters this can return games containing only a selected player or players, games that are in progress and perhaps other subsets of all stored games. Details of a specific game may be retrieved by game id. For normal players, only the details that their player identity has access to may be retrieved. For developers all details are visible and subject to modification.
id
player ids
turns One entry for each turn in the game so far. All open if the game is completed otherwise only information visible to this user is present.
turn number
units list
unit id
unit type ship type, planetary resource type, population
location type space or system or planet
location
player id
technology list
players
player id
technology id
level
investment
moves list
players
current turn
moves submitted (may be part of the turns container)
active
created
completed
final scores if completed
stars
options Options that relate to new games being started. Global lists (start information, admiral information and such). Generally these will only impact newly created games. Selected items may affect all games.
audit Audit log recording changes made using administrative privileges.
Once all player moves for a turn are complete, the turn is executed
Strategic level
Non-interactive combat resolution a the end of the turn
Units
Scout ships Small, unarmed vessels with unlimited range used to gather information.
Colony transports Large vessels that only exist to transport a group of colonists to a new star. Once the colonists debark, the transport ceases to exist as its parts are used to support the new colony.
Escort Small interstellar armed vessel
Assault ship Medium sized interstellar armed vessel
Capital ship Largest interstellar armed vessel
Defense platform Small defense system dedicated to the defense of a single planet. Combat equivalent to an escort.
System defense boat Medium sized system defense vessel. Equivalent to an assault ship in combat. May be used in defense of any planet in a single system.
Factory Production facility on a given planet. Increases output of one unit of population based on the level of factory technology that has been developed.
Robotic Industry Production facility that operates without an accompanying population unit.
Basic Turn Mechanics
Spend on building ships
Spend on building facilities
Transfer population to colony transports
Form ships into fleets and break ships out of fleets (if at a star)
Spend on technology buys
Movement Mechanics
Scout ships can move independently and over unlimited distance
Unarmed ships that are not escorted may be destroyed on entry into a new system
Without hyperwave technology, fleets always continue to their destination system
Fleets never encounter each other in open space
Fleets move at the current guidance velocity for their side
Fleets are destroyed if they move beyond guidance range of all of their side’s beacons
Ships that aren’t scouts can only move as part of a fleet
Every fleet must have an admiral assigned to it
One ship with an admiral can be a fleet
When a fleet enters its destination system it ceases movement
Combat Mechanics
If fleets from different players are at the same star then combat will occur
Combat ends when a system contains only ships from one side in a system
Planets with defense platforms may be reduced by attacking and destroying those platforms or interned.
Production on planets that aren’t interned becomes available to the controlling player after some delay
The owning player may perform planetary bombardment to reduce planetary population. This eliminates one unit of population capacity for every unit of population removed. Likely only relevant if you expect the enemy to reclaim the system soon.
We’ve framed out the ‘Cluster’ game graphically (at least to a first approximation). Currently the cluster generation is handled in Unity and there are no game rules and no save games.
I’m in the process of roughing out the MySQL database structure that will hold persistent game data and convey it between players and looking at coding up the php code needed to manage this data and implement game turn logic and playing field generation.
Once the basics are sketched out, I expect to remove the generation logic from the Unity code-base and switch things over to use the layouts and turn management provided by the site based php code.
I’m expecting to see the database side layout break out into:
System Data. Things that control game operation but do not change game to game or player to player.
Player Data. Information about the players that is not related to a particular game. Name, picture or icon, other particulars.
Game Data. Information that is a base part of a particular game run but does not change turn by turn.
Turn Data. Turn and move data for the game.
System Data
Star name list
Planet types list
Configuration such as number of stars per game and other similar items.
Player Data
Player ID
Player Name
Player picture or icon
Games played
Wins/Losses
Game Data
Stars Information Table with color, location
Planets Information Table with type, properties, max pop, orbit
Turn Data
User Move Fleets from -> to. Scouts from -> to.
Resource Production Build Ship here, Build planetary resource here, Spend on research. Form and break fleets.
There have been concerns expressed about getting from a point cloud to imported animation data tied to a skeletal model.
I accept that this may not be trivial…particularly tying a set of points in a moving cloud to control points for bones in a skeletal animation.
Collada
It does appear that there are defined interchange formats (I’ll have to look and see if these are supported bu Unity and Blender) that may make this more straightforward. Being able to export the skeleton for an animation and then inhale it into a processing application seems helpful. Being able to tag points in a cloud for consumption by Unity seems even more helpful.
I looked here and got a pointer to collada which appears to be getting developed by Khronos at this point. This appears to be a general purpose, open, XML based standard for interchange of 3D information. There is also an OpenCollada code archive out there…that link appears to be dead…but it is on GitHub and a project home page.
Filmbox is a more proprietary option with information at Wikipedia, Blender, More Blender, and AutoDesk (who created it and still owns the format). The AutoDesk link connects to SDK downloads that support C++ and Python manipulation of these files.
This weekend, Malcolm and Sam came over for a day to move our various Unity investigations forward.
Malcolm made some very nice pieces of furniture and architectural bits. I think the end result has much more feeling of place and I’m moving forward from there.
The Cluster Control Room
Sam was working on his own project and looking at getting his motion working properly on Daydream with the Daydream controller.
I added some interactivity to my prototype. Attaching a ‘stick’ to the controller and hanging a small sphere with a collider attached makes it straightforward to select objects by touching them with the stick. It took a surprisingly long time to find the appropriate code to implement haptic feedback when a star is touched. I’m still looking at adding a short positional sound queue on touch as well.
The code lives on my github account here. This supports Vive only (I think) at the moment. It certainly supports Vive best. At some point I’ll likely look at making this work with DayDream and flat screens.
Some Sample Textured Spheres…
I grabbed some textures from around the house and yard and slapped them on some random spheres and capsules. Those are here and there are separate branches for DayDream, Vive and flat screen (master). The Vive version looks much better than the DayDream version and I expect that is to be expected.
I spent some more time chopping up texture tiles. Not a lot of time to clean them up though. I really need to better understand the impacts of the various extra texture functions that are available. I think there are some options missing from the default material such as displacement maps that can genuinely move vertices. Lots to learn along the way and getting there with the Vive is pretty cool.
Basement is largely ready to go. Machines are loaded with pretty much what is needed. Now I think I’ll bodge together a bit of script and scene and make sure everything is good to go with the vive headset.
