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:

Comments

Post a Comment

Popular posts from this blog

Sprint 5 - Finishing the Furniture

This week, I completed modelling (4hrs) and texturing (7hrs) the furniture that will be used in the scene. It took longer than I expected because I had difficulty nailing down an art style while also working with new techniques in Substance Painter that I wasn't familiar with. A big challenge was finding a style that I really liked and understanding how to achieve that. My experience is more in realistic modelling and texturing where it's easy to see where things don't look right. However, with stylized pieces, it's up to my own interpretation. I'm also working with a very base, low-resolution mesh because I want to avoid creating too much detail through normal or height maps. The simpler, the better, but, the simpler, the less there is to work with. The grand solution in nailing down a flexible art style was through the use of ambient occlusion. By baking the same model over itself, I get an AO map, which already improves the look dramatically as it removes ...
Post a Comment
Read more

Aframe Systems and Networked-Aframe

This week saw less direct contribution to the project, and had a greater testing and learning component to it.  Most of my time in the past week was devoted to a different Aframe project that involved a multi-user interaction with a cooperative and competitive component.  I used this project as a guinea pig to test out Networked-Aframe and some more 'advanced' Aframe design patterns (~25 hours). Networked-Aframe is a framework built on top of Aframe that integrates WebSockets and component syncing to streamline the process of creating multi-user Aframe projects.  The main feature of Networked-Aframe we are interested in was the voice chat support, as we feel it could be a great feature to have for playing the game with friends remotely.  However, I also set out to see if there are other features in the framework that could be useful in developing our project.  An element I did find useful was component syncing, which uses HTML <template/> tags to create ...
Post a Comment
Read more

[WEEK 3] Illustrations and Alpha Prototype

This week, we need to complete the user interaction specification document, which contains many graphical components that need to be created. This includes the storyboard/wireframes, design compositions, and the architectural flow of our game. Additionally, the Alpha prototype is due next Friday! This is a huge priority and at this point, we will be relying on Mitchell to work on coding majority of the functional elements. Primitive environments have been prepared by Maxime, but they need to be tested in a VR environment (i.e. for scale). Priscilla will be putting together all the parts of the proposal document and supporting both Mitchell and Maxime with their tasks.
Post a Comment
Read more