Archive for December, 2016

Notes from a machine learning unconference

December 5, 2016

Here are a few dot points I took from a machine learning unconference I went to recently.

  • The STAN programming language.  You can declare variables without giving them values and then use them in calculations.  Outcomes are determined probabilistically.
  • Andrew Gellman at NYU apparently knows things about multi level models (beyond Bayesianism).
  • GAN (generative adversarial networks/models) are powerful.  Tension between minimising one thing and maximising another.  Made me think about Akaike information for the ‘max’ of an algorithm and Fisher information for the ‘min’.  Might be able to render these stable that way.
  • Kicad electronics CAD tool for microcircuits
  • Ionic transfer desalination
  • Super resolution is amazing (more GAN)
  • InfoGAN
  • LIME GAN super-resolution local to global (a model explaining a model).  See https://github.com/marcotcr/lime .  Might be the next step for this sort of thing (testing machine learning models)
  • Electronic frontiers Australia, citizen 4
  • Simulation to generate data, unreal CV, unity3d to train machines
  • Parseymcparseface and inception Google pretrained models
  • Imagenet
Advertisements

Udemy courses and a procedural generator SDK

December 1, 2016

I’ve recently taken advantage of the latest ‘black Friday’ sale on Udemy, and consequently have been taking a few courses on client-server interaction with Unity (using digitalOcean for the server), as well as database manipulation (using the MAMP stack – MacOS, Apache, MySQL, PhP).  I’ve found these courses edifying and useful.

The same fellow who has authored these courses also authored a course on procedural generation, which I am taking currently.

My hope is that I might be able to take ideas from the procedural generation course, combine these with ideas from the multiplatform runtime level editor plugin for Unity, and be able to thereby procedurally generate content from within a running game.  But in terms of the absolute bare minimum for an MVP, I guess I would be after:

  • The ability to toggle between player and DM.
  • A single view for the client, containing just a flat featureless plane.
  • An asset to drag into the scene for the DM (say, a tree).
  • The ability to extract the metadata of the scene containing the scene with the one additional asset and send it via php to a server on digitalOcean.
  • The ability to transmit from the server on receipt of a message from a client flagged as a ‘DM’ to all clients.
  • All non DMs should see their scenes update to see the tree.

This should not be too hard.  I think I have all of the necessary pieces to do this now.  After this, for MVP 2, I’d like to extend things in the following way:

MVP2 (transmission of procedurally generated scene metadata):

  • In the DM view, the ability to procedurally generate a town.
  • It should then be no harder to extract the scene metadata and transmit that to the server.
  • The non-DM views should then see their scenes update to see the town.

MVP3 (modifying assets procedurally):

  • The ability to procedurally generate terrain.  This is modifying an asset (being the terrain).
  • Transmission of the modified asset over the wire.
  • The non-DMs views should eventually update to see the modified asset.

MVP4 (limitation of privilege and additional view):

  • The DM should now have two views: the edit view, and the same view that the non-DMs see.
  • The non-DMs might also be able to see the edit view, but have limited privileges to change things therein.

Consequent to this, I’d like to see if I could create some sort of ‘procedural generator SDK’ for allowing developers to easily generate procedural generators.  The idea is that these would take several sets of assets, split into several tags (some perhaps having multiple tags per asset).  It would also customise some sort of algorithm for how these tags should be manipulated relative to each other.  Finally, I’d want to have within the SDK a way for the developer to expose a simple UI to a user.

For this next stage of the project, an MVP would simply be an SDK that created a procedure for two tags, and a ‘Go’ button.

MVP2:

  • Multiple tags, with possibly multiple tags per asset, and a ‘Go’ button.

MVP3:

  • Now with a more complex and configurable UI for the procedural generator created by the script created using the SDK.

MVP4:

  • A procedural generator marketplace exposed within the game.