Commit c197ab91 authored by Sam Hebditch's avatar Sam Hebditch
Browse files

Tidying up some little bits so that



automation can work.

Signed-off-by: default avatarSam Hebditch <samhebditch@redweb.com>
parent 89755e0e
Loading
Loading
Loading
Loading
+4 −4
Original line number Diff line number Diff line
@@ -5,12 +5,12 @@ The aim of this page is to cover, outline and describe the design decisions take

As mentioned above, one of the key goals for this project is to produce something that is modular, and easy to drop in for a developer, with little to no input required or needed from them. Accessibility shouldn't just be in the form of making games and projects accessible, but making the tools to do so easy to implement and an easy process that encourages people to factor in accessibility. 

1. Raycasting
Raycasting
-------------

Raycasting is currently the only method we use for determining objects in a scene, it was chosen, as it's part of the standard Unity engine (as part of the physics system), it's also got little to no performance impact. Whilst not tested, I also believe that Unity is able to handle mutiple rays, meaning that it's a solution that could integrate easily into excisting games that use Raycasting as part of their object collision/detection/physics systems. 

1.1 Raycast source
Raycast source
~~~~~~~~~~~~~~~~~~

 Initially, I experimented with using rays fired from the camera in the scene, however I found that using some augmented reality platforms don't quite work. This led me to creating the :code:`Casting Cube` component, which when enabled and set up, will follow/mirror the direction of the main camera. From here, we cast the ray in a foward direction, using :code:`transform.forward`.
@@ -19,14 +19,14 @@ Raycasting is currently the only method we use for determining objects in a scen

 We do assume that the Camera is going to be paired up and configured to match the devices   rotation and movement, since we've focused on Augmented Reality so far, this typically makes perfect sense and has been the case in all of our tests so far. 

1.2 Raycast setup 
Raycast setup 
~~~~~~~~~~~~~~~~~

 In the setup script, we again, make a few assumptions to allow things to work somewhat seamlessly, regardless of the set up that the developer has in place. We use tags to identify object, and rely on some pre-existing tags in Unity. Primarily, we rely on the :code:`MainCamera` tag initially to determine the camera in the scene, and place all of the components required for raycasting as children of it. 

 It is worth noting though, that whilst we initially rely on the :code:`MainCamera` tag, we do shift it over to a :code:`ScnCamera` tag that gets set up, and referenced throughout the scripts that have been created. 

2. Script Modularity 
Script Modularity 
--------------------

Initially, the scripts and code for this project was all handled within a singular script, there was no communication between scripts, and things became very messy and hard to debug and modify without fear of breaking something else. Below is an example of how this behaved: