Jump to content
  • Advertisement

Brayden Beavis

  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Brayden Beavis

  • Rank

Personal Information


  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Brayden Beavis

    Dev Log 1

    Thanks, so excited to share it with you guys!
  2. Brayden Beavis

    Dev Log 1

    Being approached with the task to create a ‘calming’ experience for LiminalVR users was juxtaposing because at first we were absolutely not calm with our approach to research and our aggressive surveys distributed over social media (Which by the way, feel free to take part in here and here). However, a week later the team had a meeting with LiminalVR and were given access to their concentrated psychology documentation which, to say the least, was a lighthouse in the fog of endless research. The research provided to us allowed us to decide on creating the natural setting that we wanted, with factors of detail such as colour and vegetation types that allow for a calming user experience (we hope!) The terrain itself was generated with World Machine, using a low resolution to ensure its cost remain low for mobile optimisation. The terrain, when translated across into Unity, had some scaling issues and as a result, the long rolling meadows that were seen in World Machine imported much smaller. To fix this issue we doubled the size of the terrain but as a result, we discovered that we had lost a lot of our ability to create finer details when painting textures. However, as this is essentially saving cost and the painted roads will be in the distance, we decided to push forward. Itween was used to create the curve in which the lantern follows, travelling at an increasing speed as it moves further from point A towards point B. The lantern model is still underway, however this will be one of the final features that will be implemented. On feedback we changed the initial idea from dusk to dawn and to really harness the colours of an early morning sunrise, we used optimised volumetric lighting beams to simulate the sun rising in the morning. It was extremely challenging to simulate atmospheric fog inside of Unity that is mobile optimised and after research we decided to create a cylinder to surround the terrain with a low alpha material on the inside which gives a low cost effect of fog. This encompassed with Unity’s inbuilt fog feature allowed to create a believable environment. User Input is required at the start of the experience, the player simply must use their head to turn and look at one of three pieces of paper that represent most how they are feeling, this is a feature that is currently being worked on in a test scene and will be migrated over to the experience on completion. Next up we will be working on polishing, grass, textures, finalising models and audio. Stay tuned and watch this space! Sincerely, Team Tuff Knight P.S - Follow us on Twitter for regular updates! @BraydenBeavis @MohamadAlRida
  3. Brayden Beavis

    Design Prioritisation

    The design team initially proposed that we use the spaceship as the central HUB world for the player to return to after a mission’s closure, with this decision unanimous, we began to work chronologically into the game. On the contrary to regular practice and due to inexperience, we began working on the players introduction to the game and tutorial first, before turning our attention to the roguelike elements required, as per the brief. Much of the design work that the team and I worked on was based around the level design of the HUB world and the narrative that could be construed through onboarding. Due to the focus in this area, the main game suffered inattention. Systematically speaking, once the scripts were working in the HUB world, they were supposed to translate smoothly into the level generation there after. Unfortunately this did not go as planned and by the time our attentions had turned to the procedural generation, serious system issues began to highlight themselves. I believe that if we had have worked solely on the procedural generation first to meet the brief requirements and then worked backwards, creating the HUB world then the tutorial, we would have a product that is much more compatible with the brief. As I venture into other projects, this lesson learned in prioritising, I feel is the most important one that I will carry with me to ensure this issue is not repeated in future endeavors.
  4. Brayden Beavis

    Grids Pro Asset Offset

    Colony 7 relies on a grid system for assets to snap together, this is so that when an asset is in the way of the player, the player is unable to move to that space. At the beginning of the project the team were unfamiliar with Magicavoxel and how it worked, what we hadn’t originally taken into consideration is: If I create a floor piece that is one unit deep on the Y axis; Then I make a toolbox to sit atop of the floor, on importing into Unity, the tool box would be sitting one unit inside it. However, if when I created the toolbox, I had started it one unit higher to count for height of the floor, this could have been avoided. With a ‘two birds, one stone’ approach, fixing my problem and fulfilling my programming learning outcome, I created an offset script for the assets so that they would still sit correctly on the grid for functionality. Essentially the script adjusts the transform of a child in the Y axis whereas the parent object sits on the grid. This script is able to be applied to any object that needs a slight adjustment rather than having to account for the unit height of asset placement inside of Unity when building the level. This script also made changing the design of the level easier as the assets could be placed anywhere using this script, while still fitting on the grid.
  5. Brayden Beavis


    After getting the green light on the Colony 7 pitch, we entered pre production with a grand scheme that was very large in scope, but seemed achievable at the time. As production went on, hurdles were encountered with various technical aspects of the games functionality which slowed down the production itself. While technical hurdles are mostly common in all projects, it soon became a realisation that the team had not taken into consideration the potential for these hurdles to arise when defining the scope against deadlines. The effect this had on production was that with each hurdle encountered, that may have taken a day or possibly two to fix, we were losing time to implement the various other systems. In the weeks leading up to the feature complete deadline, to resolve this issue, we had to make extreme cuts to content that we had run out of time to implement. This meant that we had to cut our first level, which caused disappointment among the team. On the back of this, when weekly sprints were consistently not being met, it allowed for deflation to seep within the ranks as there was seemingly a lack of progress. Moving forward, I’ve learnt that setting an achievable scope is highly important so that the team are being given realistic goals, this not only avoids disappointment but it also avoids loss of motivation within the team. The process of making a game can be turned into one itself by setting smaller, more achievable goals for designers and programmers to hit and be rewarded with the fun and positivity we look to install in our players.
  6. Brayden Beavis

    Colour Pallets

    In the early stages of design the team failed to outline a clear and concise colour palette to work within. Essentially this allowed for each member of the design team to interpret the in game environments however they wished, it also meant that during the phase of asset creation, the assets were inconsistent and often contrasting. It was only when the assets had come together that this was realised and the team addressed it immediately, focusing on steel greys for the structure of the HUB world with touches of blue to compliment the Colonists uniform. At this point however, it meant creating new renditions of the assets that work in unison of each other. Mainly it was minor issues that were easily fixable such as panel details or table top colours, however one area in particular was quite problematic. When I designed the Volcanic environment, I had a significantly different idea to the other designers, this resulted in spending several hours editing the colour schemes instead of focusing on other work that had to be done at that time. Luckily not too much backtracking had to be done as the problem was identified early enough due to constant asset implementation and testing. Looking back at the plans whilst in pre-production, the colour palette was an obvious and high priority specification that just became lost in translation during the design prep. This particular problem has taught me how crucial it is to outline this early on to ensure designers are working towards a shared vision at all times, it also allows constant re-visitation during the project for guidelines.
  7. Brayden Beavis

    Modular Asset Kits

    Having never dived into the world of modular asset creation before, I decided to do some research into how artists and level designers work within this area. The GDC Vault has a great talk on this topic called ‘Fallout 4’s Modular Level Design’ (Linked below), it definitely helped navigate me towards the right direction, albeit there were mistakes I had to uncover for myself to truly know what the benefits of going modular were. Within the first round of assets that I had created, the problems started to highlight themselves. I had created a door asset that suggested it lead to the bridge, except the bridge was going to remain locked. When the level design was updated and we needed the bridge, it meant the doors were unusable because they needed to be able to open. Ultimately this meant redesigning the asset to animate and fit on the pro grid correctly. Original Door: Updated Door: The issue that this highlighted for my work practice, was that when layout changes were made for functionality reasons, the models I was making were inflexible, they were not singular enough to be manipulated to compliment the change and thus they quickly became redundant. At first I had to spend a considerable amount of time chasing my own tail, so to speak, correcting and editing the assets to fit into the updates. Nevertheless once they were updated and snapped together without clipping issues, it was understandable that if I had made them as singular units from the very start, I would not have wasted precious development hours. Moving forward, with asset creation and level design, I know that the more modular the assets are, the more malleable and reusable they are with unforeseen design changes. You can find the very informative GDC talk, surrounding modular level kits, by clicking this link: https://www.youtube.com/watch?v=QBAM27YbKZg
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!