Notes on daydream setup for unity

Using notes provided by Sam and Malcolm as a springboard…

Download the ADB drivers from clockworkmod.

Grab the GoogleVRForUnity package.

More instructions that I’ve grabbed from a short document that my friends created and shared…I’ll post details if they’re ok with that.

Currently building and will try to launch in Daydream once that is complete.

I may also try the vive as a target if this goes well. The nascent game isn’t really that exciting, but I’d like to get things basically working in all three environments if I can.

Looks as if my Android SDK location is a problem…it is in my users area and the path has a space in it. I’m trying to get android studio to relocate the SDK…currently it is in a hole and not coming out.

Some notes on the unity API(s)

This is largely notes to myself around the Unity API set. I’m at the point where I want to get some significant code written. I’ve got enough assets in hand to get started on the sample game I’m putting together. I know what needs to get done. Now I need to better understand how to fit that into the frameworks that are currently in place.

Looking at the Unity documentation online, the manual and the API docs. I found some procedural generation links here and here and here that I’ll have to read through in more detail.

Hmm…best practices guide…that looks interesting too. Took a quick look and these are more advanced topics than I’m looking for.

CLuster now has stars

Just a disk of random stars with few additional details, but a nice start. I’ve overpopulated them to make the disk more dramatic at the moment. Just load up stars.unity from the Cluster-1 off of GitHub and you’ll see them.

A view from afar…
Closer in looking across the disk…

Now to generate planetary systems for each star based on its color and add in a skybox to provide the black of deep space as a background. Note to self…don’t select eight thousand stars by mistake while trying to grab a screen clip…

It would be nice to surround them with coronal particle systems and texture them with sun-spots, but that will (perhaps) come. For now I’m more interested in building out the mechanics.

Unity, Daydream, VIVE and some more VR

Spent some time after hours doing some work with unity and blender with my friends Sam and Malcolm. We’re all trying to become more proficient in putting together virtual spaces and using these tools to build more interesting assets.

I’ve got a daydream headset now to complement my HTC Vive. I really want to reach the point where I can build things that work on flat PC screens and both the vive and daydream (cardboard might be nice as well, but it is less interesting as its control capabilities are quite limited).

Malcolm and Sam are focusing on the daydream for now. We’re all going after different sorts of content. I’m aiming for a computer mediated, turn based, multi-player game inspired by some of the old board wargames I played in high school and college.

Malcolm and Sam helped me get my phone and computer loaded with the daydream development tools and mostly running (I left my daydream headset at home so I’ll have to fill in the remaining details later). I still have quite a bit of coding to do in order to get a working initial environment for my game going. I’m also going to have to work to keep the graphical intensity at a level that the phones can handle…I expect the PC and vive will want a different sort of assets for practical purposes.

Once the base game is working, I’ll need to put together a PHP/MySQL back-end to connect the game-board implementation to other players. Details here remain to be worked out, but I expect the initial version will be hosted here with some hand coded PHP managing the back-end. I am still split on how to partition up the game rules logic. Ideally the local copy of the game would only handle display and rendering while the server side code would handle random number generation and rules logic. Placing that much complexity in the PHP code may not be an ideal solution…I’ll have to play with things more in order to be sure.

Fun with Jackson Serialization

Spending some quality time this weekend walking through the deeper layers of Jackson JSON serialization. I’ve used the library casually in the past, but never for anything of any great complexity. It has recently come up as a target for some more complicated (harder to map directly into JSON) data structures. I’m spending a few hours this weekend putting together some sample code to ring the changes on things I might want Jackson to do.

Initial sample code bits are just walking through the basics and making sure I remember what is needed there. I am noticing a few things:

  • It doesn’t care about serializable at all. I expect that it uses reflection to walk the object tree and find property accessors directly.
  • It demands getters and setters for all properties to be serialized. A constructor with the appropriate arguments is not an option. This means that immutable-ish objects are not supported. You must be able to read and write object properties individually to make Jackson work.
  • It does respect transient so it is easy enough to mark internal implementation details for exclusion from processing.
  • The object mapper does not like objects with more than one single argument setter, even if one setter exactly matches the type being loaded into the de-serialized object.

Next step is going to be creating a map of string to custom object.

So far I’ve done the easy stuff. Some evening soon I’ll try to find time to add in the more complicated bits. Code is here.

And now custom object that is a proper map key (implements hashCode and Equals) to custom object.

Unity Next Steps

I’m realizing that once I have my star-field created, I need to figure out how best to run the mouse with a conventional mouse pointer and do hit-testing in the scene. I want to let the user click on a star and then quickly zoom in to a close-up of the star that shows its planets in some detail and any vessels that are in the system.

I’m hoping this is easy to do. It is a bit at odds with most action games, but crucial to any sort of interactive user interface created for the user.

I also hope to put up text floating near the graphical elements to add more information about them. This will include the number of ships of a given type in system, the relevant attributes of each planet and any items located on the planet. I’d like to use floating text with a transparent background and a contrasting outer edge (to ensure visibility even if something unexpected is in the background).

Looking at building a simple game with unity

I’m looking at building a game similar to stellar conquest (without borrowing any copyrighted content) using unity and then setting up a multiplayer capability through an internet connection (likely my hosting with some PHP persisting moves to a MySQL database).

I’ve got the basics figured out for laying out the playing surface and it looks as if prefabs work for creating stars, planets and ships. I can see how the player interface would work in VR (either room scale or three axis) but I’m going to have to dig in to work out hit-testing for on-screen mouse activity.

I’m going to be thinking about how to handle star generation. The game that is providing the inspiration used a fixed map with the star located at mostly symmetrical positions. I’m inclined to have my game place the stars using a random number generator but with a defined distribution of star types to ensure some level of balance.

I’m going to do the same sort of thing for planets…not cards from a deck as with the board game but again, randomized with appropriate probabilities to yield the right sorts of planet mix.

I think the next step is probably to build the star cluster and scatter some colored lights about through space…I’m really tempted to go with a three dimensional star cluster for the final version if VR is the main target.

Playing with Python

I was playing with Python a bit more over the weekend. It is a serviceable language but I am persistently amused/irritated by a few things.

The python 2/3 breaking incompatibility split seems to be persistent, entrenched and troubling. It appears that the .NET and java ports (jython and iron python) have still not made the transition to python 3. The cython baseline and web site are now confidently stating that python 3 is the present and python 2 is the past, yet I’d expect that if that were really true, the other python implementations would at least support python 3 and ideally would have the same position with regards to python 2.

I was watching a video discussing some python features and they mocked the curly brace languages for having religious wars about where to put the braces. I have a general aversion to using white space (a very poorly conserved type of text) for block scoping as far too many tools consider spaces and tabs to be adjustable and interchangeable. The thing I find amusing here is that I’ve seen far more friction in the python community between use of spaces or tabs and how many spaces per indent level than I’ve ever seen around the placement of curly braces.

I do expect to replace perl with python for various places and the OpenCV support looks quite interesting. I think that in time the style issues will feel less foreign and I very much hope that the 2/3 split will be dealt with in the overall community as JVM and CLR versions of the engine that implement a non-obsolete version of the language would be very nice to have.

More adventures with C++/CLI

I’ve been working with C++/CLI to get access to native API functionality from C# some more lately. I’ve been running into cases where something compiles flawlessly when I create the project but then fails miserably when pulled from GIT clean and rebuilt. I’m looking at various build issues that might be contributing to this and will hopefully find the right recipe soon.

Some notes here related to parts that matter and APIs that I’m looking to use…half of this for my own reference as I mess with solutions to see what works:

Marshaling strings the (relatively) easy way:

 #include <msclr/marshal.h>

System::String^ myPath = "ABC";
std::wstring path = msclr::interop::marshal_as(myPath);

File information:

typedef struct _FILE_ID_INFO {
ULONGLONG VolumeSerialNumber;
FILE_ID_128 FileId;
} FILE_ID_INFO, *PFILE_ID_INFO;

FILE_ID_INFO info;

BOOL ok = GetFileInformationByHandleEx(myHandle, FileIdInfo, &info, sizeof(info));

Alternate string marshaling:

inline void MarshalString(String ^ s, std::wstring& os) {
using namespace Runtime::InteropServices;
const wchar_t* chars =
(const wchar_t)Marshal::StringToHGlobalUni(s)).ToPointer();
os = chars;
Marshal::FreeHGlobal(IntPtr((void)chars));
}

Volume information:

BOOL ok = GetVolumeInformationW(path.c_str(),
volumeNameBuffer, MAX_PATH + 1,
&serial,
&pathLength,
&flags,
filesSystemName, MAX_PATH + 1);

File attributes (can be used on c:\ to find things like volume creation time stamp)

WIN32_FILE_ATTRIBUTE_DATA info;     
BOOL ok(GetFileAttributesExW(path.c_str(),
  GetFileExInfoStandard,
static_cast<void *>(&info)));

creationDate = gcnew System::DateTime((long long)(info.ftCreationTime.dwLowDateTime) | ((long long)(info.ftCreationTime.dwHighDateTime) << 32));

Additional volume information:

    wchar_t volumeName[1024];     wchar_t fsName[1024];     DWORD vsn;     DWORD fsflags;     BOOL ok(GetVolumeInformationW(path.c_str(),         volumeName, 1024,         &vsn,         nullptr,         &fsflags,         fsName, 1024));

and

    ULARGE_INTEGER free;     ULARGE_INTEGER total;     ULARGE_INTEGER totalfree;     BOOL ok(GetDiskFreeSpaceExW(path.c_str(), &free, &total, &totalfree));

and basic info

FILE_BASIC_INFO info;
BOOL ok(GetFileInformationByHandleEx(handle, FileBasicInfo, static_cast(&info), sizeof(info)));

Busy week and weekend

…of work related C# and java code. Things stay busy and old projects need additional work as changes happen.

Spent a good chunk of the weekend and several nights last week making sure that work priorities were attended to.

Less fun than messing with sandbox projects, but work does generally come first at the end of the day. Toy projects can slip schedules almost indefinitely…

Engineering execution and creativity mixed for the best results…