Skip to main content

Game-state Management and Aframe Systems



Most of this past week involved implementing the data management systems that control the current state of the game for the Builder and the Finder.  The basic skeleton of the systems, as well as the components they used, were implemented at the beginning of the week leading up to the Beta milestone (~10 hours), and the rest of the week was spent expanding and polishing these systems (~3-4 hours).  The two systems I focuses on were the Builder system, which which manages the game state of the Builder player, and the Finder system, which does the same for the Finder player.

The Builder system keeps track of which piece of furniture is being built, what step the Builder is on in the build process, as well as how many steps there are to complete the furniture.  Every time a piece is successfully snapped an event is emitted by the scene element and the Builder system picks this up, increments the current step, checks if the furniture is complete, and emits a Socket.io event that informs the Finder what the next piece is or that the furniture is complete.  This system also listens for a Socket.io 'shipping' event from the Finder and uses the data passed to create the new piece in the Builder's environment. 

A table leg appearing in the living room after being shipped by the Finder.  The builder clicks on the box, and the table leg appears.

The Finder system works in conjunction with a 'shipping' component attached to the shipping platform seen in the picture below.  When a furniture piece collides with the shipping platform the shipping component checks with the Finder system whether it is the correct piece; if it is the Finder component then emits a Socket,io event containing the piece id.  The Builder system listens for this event and creates the piece from the id, as stated above.  

The placeholder shipping platform and a table leg in the warehouse.  The Finder drops the table leg on the platform and if it is the correct piece it gets 'shipped'.

The code below demonstrates the process shipping component uses to determine whether the collided piece needs to be shipped or not.

el.addEventListener('hitstart', function (event)
{
    for (var i = 0; i < event.detail.intersectedEls.length; i++)
    {
        let targetEl = event.detail.intersectedEls[i];

        if (targetEl.classList.contains(system.data.requiredPiece))
        {
            // If the dropped piece is the one we are looking for, remove this instance
            // and emit the sendPiece event for the Builder.
            el.sceneEl.removeChild(targetEl);
            socket.emit('sendPiece', { pieceId: system.data.requiredPiece, });
        }
        else
        {
            // If not, launch the piece back at the player.
            targetEl.body.velocity.set(-5, 6, 0);
        }
    }
});

At the moment the values for the number of steps and the pieces required for each step are still hard coded, one job for this next week is to implement a process that allows the systems to pull this information from a database depending on the furniture selected, and I will be working with Priscilla to complete this.  I would also like get game controller supported.

Comments

Popular posts from this blog

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 = ...

[WEEK 6] Back from Reading Week

We got back from Reading Week and reviewed what each of us accomplished. Expected deliverables for this week include: moodboards for the Living Room and the Warehouse, basic recolouring for the Living Room, a completed final Warehouse environment, and a working spawning objects prototype.

JavaScript Libraries and Flow Charts

This sprint we focused on the laying the groundwork for the project and writing the design document.   For the design document, I outlined the Technical Requirements, Technical Features, Interaction Features, and created a user experience flow chart (~4-5 hours).   The rest of the sprint was spent testing the JavaScript packages we plan to, or are interested in, implementing in the project (~4-6 hours).    Creating the user experience flow chart took a few iterations as we weren’t certain of the final gameplay.   The current version is fairly linear, but the gameplay is straight forward to make it easy to pick up and play.    A part of the final user experience flow chart. The packages I tested for our project were aframe-extras , aframe-physics , and aframe-click-drag-component .   ‘Extras’, as the name suggests, adds some extra functionality to A-Frame, including controller support, ‘Physics’ adds a physics system, while ‘C...