Wednesday, 17 August 2016

Drawing with Metal - links

Ray Wenderlich have a 3 part tutorial for this:

1. Getting Started
2. Moving to 3D
3. Adding Texture

Worth noting: Apple provide a nice template for Metal games

Saturday, 13 August 2016

Metal Compute: Resources for getting started

A few resources to get started with Metal compute.

Saturday, 30 April 2016

GCC 5.2 in XCode 7.3 under OS-X 10.11

You may not need command line tools.

For sake, you can download the command line tools via XCode > OpenDeveloper Tool > More developer tools. But, although sources suggest that this can help with installing GCC, in my experience it is unclear whether that actually works.

You probably need an XCode plugin

There are two plugins at hmazhar/xcode-gcc on Github. I choose the 5.2 plugin and copy to the designated location.

You want GCC 5.2

I used to install GCC via home-brew, which provides the perfect excuse to go for a two hours walk in the park. But you know what? At the time of writing (April 2016) this doesn't work anymore.

Note: the following steps are likely to erase/override any previous GCC install.

  • Used a tarball 
  • ditto to copy the tarball to usr/local (DO NOT copy via Finder as it will trash your /usr folder - Probably an obscure terminal command would have saved me the hassle, eh)
  • Renamed gcc to gcc-5 as  hinted by XCode's response to the build command.
Config for C++11
  • Under Other C++ Flags you may need to add a flag for C++ 11 support.



Wednesday, 27 April 2016

Compile Code Online.

What if you wanted to quickly compile a little bit of C++ or Java? Yes, there are online services for that, for example:

Where this should get handy is producing online samples that are proven to work, or sometimes (for educational purposes) not work. What I was really after was an online tool that would cross compile my code on GCC, VS and Clang. Haven't found this yet.

If you're looking for a quick scratchpad, CodingGround works well. Saving and sharing projects? No luck.

Wednesday, 6 April 2016

Share Assets between Unity projects on OS-X

Unity's packaging system doesn't help much with keeping copies of the same assets in sync across projects. Over time this becomes a productivity killer which encourages copy-pasting assets everywhere. Fortunately, OS-X and Windows both allow using low level shared folders.

This article deals with sharing assets on OS-X to use across Unity projects. Using this stratagem, we make up for Unity's shocking lack of a class path, what were they even thinking.

First create a new git repository. Then, add the files that you want to share. Don't put unity projects in there, only assets.

We now share this to a Unity Assets folder using a symlink. A symlink is not an alias. Use Terminal to define a symlink, like this:

ln -s path/to/original path/to/Assets/name_of_original

where:

  • path/to/original is the root folder for your shared assets.
  • path/to/Assets/name_of_original is the 'alias' giving access to shared files.


Repeat the same for all projects where you want to share this. This can be tedious; fortunately there is a trick: although a symlink is not an alias, symlinks can be duplicated and renamed in the Finder!

What happens in Unity?

Unity will display a warning when detecting the sym-linked folder. It's telling us that issues may arise if projects using inconsistent Unity versions use the same asset.
Better than not being able to use them at all.

How does version control view a symlink?

Both Git and Mercurial view our symlinked-folder as a file that can be either ignored or checked in. I opted for checking the files in (because Unity creates meta for these and meta are, for the better and especially for the worse, the wet dirt that holds Unity projects together.

Overall this works pretty much as we want it to - we're managing shared assets separately from the project we are linking from.

Sunday, 20 March 2016

Rebase - Why merge pulls when you can commit lies and rewrite history

When I introduced a client to rebasing, they asked me: would it avoid our coders breaking wood?

Erm... not exactly. neither rebasing nor merging avoid conflicts. Conflicts arise from people changing the same file roughly at the same time. 

Both merge and rebase involve taking the bull by the horns; The more often you do this, the smaller the trouble.

The chief way to avoid "broken branches" (so to speak) is programmers don't commit files more than necessary and keep them (files) reasonably small.

Digression: one reason I like SourceTree is giving me a convenient interface to review and cancel (before committing) edits which I'd rather not push - log-fu, red herrings, blunders.

Interactive rebase is a popular way to pull changes from master while working on something. I suspect it's popular because it's also a swiss-army-knife letting you do semi-useful stuff like trash the inept commit you did 5 minutes ago, reword PG-rated commits and combine 25 puny commits into the 2001 Space Odyssey monolith.

WHAT IS it?

So, while Nono was fixing this and that on his branch Sassy has been committing wildly on master. What rebase does is, it rebuilds Nono's changes on top of master.
It is cleaner and morally satisfying in that:
- Keeps one's private changes in a sequence.
- Changes appear in the history in the order that they got committed to master.

A fun (huh) example

On Sassy's branch

14:00 Sassy: check garden
14:15 Sassy: investigate living room
14:30 Sassy: look in the bathroom
14:45 Sassy: report no intruders

Meanwhile

13:55 Nono: break into garden.
14:10 Nono: 'borrow' Sassy's Gameboy
14:29 Nono: hide in the bathroom.

What a merge would do:

13:55 Nono: break into the garden.
14:00 Sassy: check garden
14:10 Nono: 'borrow' Sassy's Gameboy
14:15 Sassy: investigate living room
14:29 Nono: hides in the bathroom.
14:30 Sassy: look in the bathroom
14:45 Sassy: report no intruders

Wacky eh. Now the rebase:

14:00 Sassy: check garden
14:15 Sassy: investigate living room
14:30 Sassy: look in the bathroom
14:45 Sassy: report no intruders
13:55 Nono: break into the garden.
14:10 Nono: 'borrow' Sassy's Gameboy
14:29 Nono: hides in the bathroom.

And you know what? it all makes sense because local branches are private, parallel universes. What was happening on Nono's branch indeed was perfectly hidden from Sassy until Nono committed to master.

I'm not expecting anybody to love it until they used it like, 4-5 times. It does have detractors after all. Still, it's massively popular.

In my humble opinion history rewriting (including rebase) is fundamentally wrong and I'll be happy to get rid of git... when something better comes along. In the meantime it offers great convenience at low cost (statistically) so it's a neat compromise.

TAKE ME TO THE DARK SIDE

Before we start.
Assuming you're not vimdictive the following git-fu needs the text editor setup I describe at the top of my cheat sheet.

1. commit

git commit -m "fix something" # commit changes locally, on your branch, first

2. pull master changes from remote

git checkout master # landed on master branch!
git pull # now master is up to date.

3. rebase

git checkout nono # get back to your branch
git rebase master -i # "i" for interactive.

Up, pops your text editor. Do read what it says in here truly fascinating - so many parlour tricks/substitutes for git-fu that no sane coder will ever remember.
Well. You can edit this file (hence interactive) to do nice touch-ups. Like fix a garbage comment slandering the web administrator, merge commits or forever delete spoof commits.
Now Save and Quit the Text Editor to continue the rebase. At which point, if conflicts are detected, the rebase will stall and...

git status # shows conflicted files among other things

4. Fix conflicts before continue

Just do it!

git add --all # when you solved ALL the conflicts

5. Rebase on and on

git rebase --continue

6. Push to your remote branch

git push -f # DANGEROUS don't ever -f(orce) except while doing this. But necessary if you already committed to your remote branch

7. If you change your mind

Too much for you to handle? Witchcraft afoot?

 # instead of rebase --continue
rebase --abort

INTERLUDE

I encourage everybody - even project owners - to work on their own branch (unless of course you are using feature branches but... ...alright, not today)

THE FINAL ACT

Once again without comments. First the non-screwy rebase:

git commit -m "fix something"
git checkout master
git pull
git checkout noha2
git rebase master -i
git push -f

Then the screwy rebase (notice the font change?)

git commit -m "fix something"
git checkout master
git pull
git checkout noha2
git rebase master -i
git status
git add --all
git rebase --continue
git push -f

Thursday, 17 March 2016

GameSparks micro-tutorial: leaderboards and analytics for Unity games

GameSparks is an attractive BaaS (back-end-as-a-service) option. Their docs are a bit stuffy though, so I created this quick-start document and a convenient wrapper so you can get started with 4-5 lines of code.
GameSparks provide a variety of back end services including cloud storage, cloud code... The basic integration exposed here illustrates authentication, leaderboards and analytics.

The integration and sample code are designed to work with Unity 3D.

Setup

I take you through the steps for a simple setup using anonymous authentication.
"Anonymous" means that the device ID will be sent to the back-end service instead of a user name and password).
  1. Register and create a game on their portal; fetch the API key and secret under configurator > overview
  2. Download the GameSparks Unity SDK (it's a package, like in the Asset Store)
  3. Import the package (warning: moving the GameSparks folder could break something)
  4. Also import JSONObject from the Unity Asset Store, this is needed to parse some of their responses.
  5. Notice the added GameSparks menu. Now, enter your API key and secret via GameSparks > Edit Settings.
  6. Create an empty game object, you might call it GameSparksManager.
  7. Add the GameSparksUnity script to the manager. This is part of the downloaded SDK
  8. Add my quick integration script
  9. Press play!
This is how the inspector for GameSparksManager will look like:



If you've done everything correctly you should see console messages indicating a successful login. You are now ready to do the following:
  • Fetch and submit scores
  • Display leaderboards
  • Submit analytics requests.
Leaderboards and scores

For this I will defer to their lengthy introduction here but you can pretty much skip anything related to Unity and use my sample integration to get you started.

If you use HIGH_SCORE as leaderboard id (GameSparks refer to ids as "short codes") and SCORE as attribute and SUBMIT_SCORE as log event short code, you can leave the above fields (in GameSparksManager inspector, see picture) as is.

The utility I wrote, GameSparksApi, provides the following functions:

  • SubmitScore(int) to send a score to the server.
  • SubmitDisplayName(string) to submit the user's nickname displayed in leaderboards.
  • FetchPlayerRankAndScore() to fetch the rank and score; this will be assigned to playerRank and playerScore so you can have a text component display this (it will take a while to update after you call the request).
  • FetchLeaderboard()
    to likewise get an updated leaderboard with a formatted result available (after a while) in formattedLeaderboard

Customise the source if you're not happy with leaderboards format or want to handle callbacks yourself.

Analytics

So called analytics requests allow you to log user actions. A typical use of this is finding how far players got into your game: Did they complete the tutorial? Did the game even load correctly? Can they go past level 1... ? And so forth.

This doesn't require back-end setup, just call the Analytics(string) function on GameSparksApi. The string indicates what user action you're logging.

Results are displayed (in your admin screens on the GameSparks website) under Configurator > Analytics > Custom

Caveat: Analytics update appear to take one hour or more to go live in admin screens.