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.

Production Analysis: Methodologies:

I have been using and will continue to use a couple of methods and development processes for my graduate project.

Top down approach:

I have been using a top down approach, starting broad looking at a range of possibilities. Then assessing their benefits and limitations to find the best possible route to take. Then repeating this process on the next level until you reach the bottom level and have a finished product. An example of this process was when choosing my development environment and coding language, I found my options and researched their benefits and limitations. After weighing them up I decided upon the path to take, this time being to code in JavaScript and develop for the browser. On the next level I started by researching the libraries available for JavaScript and weighed their benefits and limitation to decide the best option to take. This process will be repeated until the project is finished.

Spiral Approach:

Along side the top down approach I will be using the spiral approach for my development process. Starting by defining all of the areas I need to develop, ordering them in importance, start developing said, area testing it to see how well it works and if it accomplishes my aims. Then repeating this process, assessing my defined areas, adding to or subtracting from that list and choosing a new area to develop.

Production Analysis: Idea:

A detailed description of my idea:

You control an unknown ‘alien’ entity on its journey of growth and destruction. A full fledged game would begin at microscopic level and end at a cosmic level. Controlling the avatar with your own hand through the LeapMotion. As you roam around you can devour other objects in the scene which are smaller than you, the more you consume the more energy points you gain and larger you get, thus the more objects that are available to consume. While navigating the level you will be required to avoid objects larger than you for they would decrease your energy points making you smaller on collision, you would also be required to figure out what to consume and when in order to progress. An example of this is within the solar system level there are orbiting planets which are relatively smaller than their hosts, you are required to devour the orbiting planets/comets before you have the capacity to consume their hosts and move on to the next stage. The end of each levels sees your avatar consuming the largest object in the scene enabling you to move to the next level, where you would  again be the smallest object in the scene working your way to  devouring everything. Eventually ending in your avatar being the only thing left and conquering the cosmos.

Language choice:

After some deliberation, I decided upon using JavaScript as my primary language. Its benefits outweigh the benefits of the other options. Although I am going to have to learn a lot of JavaScript and multiple libraries in order to succeed with this project I feel that I would be happiest with myself at the end. In addition to this, coding in the browser will make my project accessible by anyone with a computer and an internet connection and increase my target audience tenfold compared to a standalone app either created in unity or C++.