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.

Labels

Labels:

Comments

Post a Comment

Popular posts from this blog

[FINAL] - Where to find our game

Hello future builders, we're 3 programmer-artists that make up the Seismic Octopus team: Mitchell Koch - lead programmer, game tester, researcher  Priscilla Lo - project manager, sound design, lead 2D artist, programmer, documentation  Maxime Vincent - lead 3D artist, lighting designer, game tester We finished this course in May 2020 with a final release of Build-a-Furniture available on GitHub: https://github.com/Areizza/Build-a-Furniture Although this semester was full of hardships and unprecedented times near the end, we got through it together and are proud to present our simple web-VR game. Check it out and let us know what you think! :)
Post a Comment
Read more

Sprint 10 - Adding more boxes and lots of scripting

As the final submission draws near, lots of work has yet to be done. Due to time constraints and the lack of resources in light of recent events, we made the decision to cut down our scope by removing VR functionality entirely and focus on desktop-to-desktop connection fully. With new goals in mind, I spent the beginning of the week by adding all the boxes for spawning furniture components. To do so, I started by replacing the blue boxes we used previously with stylised boxes that match the environment better. To tell the player what each box contains, an image of the rendered component is placed on each side. The challenge here was that I wanted to avoid creating a GLTF for every single box because it would have slowed down the page drastically. The solution was to instead use a single, universal GLTF for every box and placed images on each side of the box as explained previously (~6hrs). New Warehouse Area - Added new boxes Close up of updated box - Bright colours and side ...
Post a Comment
Read more

Making Instructions

This week, I worked on creating all the instructions images for both the Warehouse and the Living Room. Although this was not a very difficult task, it was tedious to work on and took around 3hrs to complete. It was a challenge to adjust to our new schedules given the current circumstances and allot appropriate time to spend on each of our classes. The instructions in the Living Room show the current required furniture pieces and their quantities, which the Builder will need to communicate to the Finder in the Warehouse. See below for an example of pieces required for a table. On the other hand, the instructions in the Warehouse would show the symbols on the different furniture pieces that should touch in order to be combined, which the Finder will need to communicate to the Builder in the Living Room. See below for an example where the green heart marking should be made to touch the green circle marking. I will be putting the source link for these instructions into arr...
Post a Comment
Read more