Skip to main content

The Alpha Prototype

This week began with adding some finishing touches to the project design document, (~2 hours) , coming up with a plan for implementing the alpha prototype (~5 hours), and then the rest of the week was spent starting to implement that plan (~3 hours).


We decided that the biggest hurdle for this project is going to be creating pieces of furniture that can snap together to create a single piece of furniture, so this is what we want to have completed for the alpha prototype.  There are a couple approaches that could be made to achieve this effect, and most of the planning was spent trying to determine what worked best for us in terms of effort, functionality, and modularity.   

The first option was to try and use some existing functionality from an existing component, but the best existing library we found is the aframe-snapto-component, which doesn't quite have the functionality we are looking for in that the snapping can cause performance hits if performed continuously, and the documentation seems to imply that the snapping cannot be turned on and off or triggered by events.  I have not had a chance to fully test this component yet, so we may find that we can make it work in the end.

Another option is a custom implementation of a snapping component that is not constantly searching for a snap point and instead only snaps in response to certain triggers.  This implementation would rely on invisible spherical or hemispherical collision objects placed on the surfaces of objects at points where a snap can occur.  When two snap points collide they will trigger an event that has handlers that check whether the two 'colliding' objects are compatible (probably by comparing two identifying properties on the snap point entities), and, if they are compatible, this will trigger the snap, otherwise nothing will happen.  This implementation is likely to draw from the existing aframe-snapto-component if there is a lot of transferable code.  

However, before any of the snapping could really be investigate I had to create an A-Frame environment that supported testing this kind of functionality, and that turned out to be a lot more work than expected.  This environment needed to include a few things:
  1. A simple physics system
  2. Grabbing and moving objects with a mouse (and eventually a controller)
  3. Free camera movement and rotation
All three of these functionalities have to work concurrently and getting two of these features at once was doable, but adding a third always broke something.  For instance, the default implementation of grabbing objects requires holding down left mouse button, but the default method of rotating the camera also requires holding down the left mouse.  After much trial and error, I eventually got everything working by creating the camera entity shown below. 

<a-entity camera
            wasd-controls
            look-controls="pointerLockEnabled:true"
            position="0 1.2 1.5"
            capture-mouse
            raycaster="objects: .grabbable" cursor="rayOrigin:mouse"
            static-body="shape: sphere; sphereRadius: 0.001"
            super-hands="colliderEvent: raycaster-intersection;
                    colliderEventProperty: els;
                    colliderEndEvent:raycaster-intersection-cleared;
                    colliderEndEventProperty: clearedEls;">
</a-entity>

There are a few important element to this camera entity, but the biggest problem solver was the look-controls component with the "pointerLockEnabled" property set to true as this allows the window to lock the mouse cursor to the window which enables the camera to be moved with mouse movement rather than clicking and dragging. The super-hands component is from the aframe-super-hands-component package and it is a relatively powerful, but complex implementation of grabbing objects in A-Frame.

With the environment complete and the modularity functionality begun we are well on track for completing our alpha prototype.

Comments

Popular posts from this blog

Controllers and Game-state Management

The two issues I worked on this past week were getting game-pad controllers working with our project (~6 hours), and general work on the game-state systems to iron out some of the kinks and add some more functionality (~3-4 hours).  Unfortunately neither of these tasks proved 100% successful due to some set backs. The game-pad controllers are so close to working, movement and look controls are fully functional, but I cannot get the Super Hands components to pick up the button events from aframe-extras.  The easiest way to see this is by looking at some code: <!-- Camera --> <a -entity id= "rig" movement-controls position= "0 0 0" > <a -entity id= "camera" camera wasd-controls= "acceleration: 125" look-controls= "pointerLockEnabled:true" position= "0 1.6 0" capture-mouse st...

Sprint 2 - 3D Modelling the Environments

This week's focus has mainly been on writing the design document and preparing for the alpha prototype (~2hrs). A great majority of the written sections in our proposal is complete while a large chunk of graphics remains to be developed in the coming week. The sooner the design document is complete, the better of an idea we have in how the project will turn out in the end.  On my end, I am responsible for 3D modelling the environments that will be used in the alpha demo. These are also necessary for producing design comps. The environments will be very low poly environments using primitive shapes and basic forms to form the rooms, nothing too extravagant. Below are a few screenshots of the environments in their current state: Living Room (~3hrs) that will be played in VR and the Warehouse (~4hrs) on desktop; all modelled in Maya. Warehouse Back Side Warehouse Front Gate Warehouse Top-Down View Living Room Back View Living Room Front View Living Roo...

Building the Shelf and Chairs

With the final submission looming closer, most of my effort was directed at replacing some hard-coded game-play functionality with dynamic data from the Builder and Finder systems (~3 hours), assisting my team with issues they encountered (~2-3 hours), and getting the shelf and chair ready to be built by the players (~8 hours). The Builder and Finder systems still had a few hard-coded values from the Beta build of the project that were specific to constructing the table, so I worked on replacing those with the data that is contained in the instructions arrays that Priscilla and Maxime created this week.  I was initially have problems accessing this array before I discovered that JavaScript arrays can be accessed by string, which simplified it a lot.  Below is an example of the before and after of this process. // Before socket . on ( 'setFurn' , function ( data ) { this . current = data . id ; // Where data.id was always "table" this . step = ...