User testing:

Throughout my project I conducted various user testing, I had my peers use my project and view my textures and game elements. A couple of the most important changes I made from these tests were:

firstly my avatar shader, once I had all of my planet and comet textures in my scene, these tests made it apparent that the avatar graphic no longer fitted within my scene. So I created a new shader for my avatar that fit the scene a whole lot more:

Image

Another aspect that was improved by my user testing was the starting movement speed the value started at 0.01 but with an increase to 0.015 it was much easier for new users to start off enjoying my game straight away. The comments said that even though it still wasn’t so easy to get used to the controls it was more fun because it wasn’t for lack of movement that it was hard, it was the more the users skill that held them back.

Here comes the fun bit, Physics engines:

With the controls working and a avatar in place its time to figure out how I’m going to tackle the problem of physics.

I’ve done some research into my options and I have concluded that my options are to either create my own ray casting colliders and functions or use a pre-existing engine.

Use a pre-existing engine option is the obvious choice. But now I have more decisions, which engine to use.

Avatar graphics:

If I want my avatar to look like anything special I’m going to have to go above and beyond and figure out the world of webGL shaders. I had previously attempted a few other ideas I had for my avatar however none where very successful. I believe due to my inexperience with three.js (e.g. with the example below, when adding the camera as a child object of the avatar, the camera perspective went crazy and movement seemed to be restricted to the relative space of the parent.), I could possibly have persisted and got it working.

Image

After some consideration I realised that on collision with other objects it was going to look strange if they were to vanish into thin air and not merge with the avatar object (which is barely possible within three.js).

So on I go to figure out the world of shaders.

Three.js:

After much deliberation, I have decided to use three.js as my JavaScript 3D library. There are a few predominant reasons, these being:

Three.js has the largest collection of examples, allhosted online with their source code available on github.

Three.js also seems to be a large following online, having regular questions posted and answered on stack overflow and as well as still having active collaborators on the GitHub page.

There is also a large collection of documentation, however a fair amount of it is incomplete.

The community following that three.js has was my main reason for choosing this library; being a complete novice I may run into some trouble down the line. This may prove problematic seeing as my lecturers haven’t had any experience with coding 3d with JavaScript or subsequent libraries. If I become completely stuck there will likely be someone who may be able to help me if I create a codePen or similar and post a question on stackoverflow.

JavaScript libraries:

After deciding to code solely in JavaScript and for the browser my next step was to choose which 3D library I want to use.

There are a few options available, to name a few:

Three.js an open source library hosted on GitHub with examples and fairly good documentation.

O3D created by Google with not a lot of documentation or examples.

CopperLicht has fairly well documented site with a few example but you are required to download CopperCube (being the development area) which you have to pay for after 14 days.

Finally StormEngineC which has various examples and some decent documentation.

Market:

Producing a game/experience for the leap motion will limit my target audience considerably, however developing for the browser increases that target audience to its maximum capacity.

Being cross platform compatible and allowing anybody who has an internet connection to experience my project. My project will appeal to all ages, once the user learns the simple controls they will be able to interact at their own pace. There are lots of experimental projects already available on the internet, for example HERE + Leap (http://here.com/leap) or Hex GL (http://hexgl.bkcore.com/) which are available for free to use. There is a section on the leap motion store called airspace specifically for web links to projects as well as unofficial blogs that link to less cooperate projects (http://leap.quitebeyond.de/). On completion of my project I will be able to submit it to these sites in order to increase its audience.

Although my game is primarily built for the Leap Motion if there is time once the core features have been developed I may create subsequent controls for none leap users with the keyboard and mouse, thus increasing my target audience hugely to anyone with a computer and internet connection.