Week 8
This week I built the Audio Manager. Because the game did not have many (if any) sounds, I sourced all of the sounds I presumed we would need on Sunday. This included grappling noises, jumping, various whirring sounds for other mechanical actions, footsteps, guard sounds, and music. On Monday, I built the Audio Manager from scratch. The Audio Manager that I built overloads the existing audio source structure. Using a custom sound struct as a base, I created a basic overlap/transition sound function, which is used to transition between two different music tracks. This transition is not as tight as I hoped it would be, which was frustrating. I tried three separate approaches (including using DOtween) in order to create a better method, but all of them had various issues with the way I was currently doing my AudioManager. These sounds were then linked up to the game in various ways. I implemented footstep sounds using animationevents, which solved the issues with other mechanics interacting with feet trigger colliders. I added sounds for the player attaching to the grapple, and in the process also fixed an issue with connecting to the point while in the air. When it came to adding guard noises (like a mic click to recognise enemies and footsteps) I had to rework the state logic, which now works a lot more smoothly. Checks for current and previous state now work correctly, which was helpful in several ways. Music was also a big component of my sound choices, and I chose what I considered a fitting theme for the main menu of the title. I envisioned this track as being the ‘main theme’ of the character, and because we did not manage to get the ‘mission impossible’ moment of stealing a valuable in the game, we did not get an accurate time in the level to show the music off. In the production version of the game, I would hope to pull the track apart and use elements of it in the background music, which would change and flow differently. As well as this, I also worked on finalising my level. After the lighting was redone, I playtested the level several times, fixing several graphical issues (like transparencies and their reflectivity) and AI pathing issues (guards getting stuck in random places) that were present in my scene. Preproduction Reflection The preproduction process for us resulted in a title that I am happy with, and I think that the learnings that we took from the process will help us to be a more efficient team. The first two weeks were a result of our game not having extra development not taken into account, meaning we had to rebuild systems (and create entirely new ones) in order to reach a baseline point. Our character design had to be changed as we moved quickly in a different direction, and we had issues coming up with a character that we all agreed on. We avoided these issues, rather than solving them, by just creating a character and moving on. We knew that the character had to have one arm (for the grapple hook) and went from there. Conrad’s initial sketches looked quite different from the finished 3D model, which is only moderately surprising - given the changes that occur when a piece of art transitions from 2D to 3D. The amount of time that we wasted with the grappling hook being physics-based was frustrating later in development. We spent several weeks trying to get this system working, and while we got close several times, we repeatedly encountered weird graphical issues that prevented the arm from behaving realistically. The decision to move to a hand-animated arm was one of the best decisions we made during development, as it forced the team to move on. The level development was also a point where we had a huge takeaway. Corne’s initial designs were all agreed upon, and his building the prefabs was a well-intentioned idea that we agreed on. However, the huge spaces that we created just weren’t conducive to gameplay, and we scrapped them entirely. If we had made this decision even a week earlier I believe it would have been much better for the game. Our level design as a result of probuilder has dramatically improved, as It meant that Dylan, Josh and I were able to create a scene each and combine them into one level. It made the most sense for this because we were the most experienced with the mechanics and systems, and wanted to design ‘puzzles’ rather than ‘environments. Moving forward, I think this approach is far better. I am happy with the way I developed the first area, which introduces the player to mechanics by leading them in a variety of ways, from subtle to image-based. Using the first guard as a way to teach the player about stealth was very interesting. Creating transparent windows allows the player to see the AI at the expected time that they arrive there, and the shorter walls help the player see his head. Overall, my design philosophy with this level creation system was to create the puzzle first, and then design the environment around the puzzle. This was most obvious when Josh and I created the overall level design, and we were able to clearly mark areas where we taught players mechanics. This meant that our level development went much faster than we expected, and we were mechanically done after a week of level development. A week of polishing and adding effects made the levels look visually impressive, which I was very happy with. My impression of the entire process is positive, mostly to do with how much the team as a whole learnt about design processes in developing a 3D platformer. We chose a genre and game style that is incredibly reliant on feedback and ‘feeling good’. If a platformer doesn’t have good jumping, then the game feels bad. This meant that we had to put a huge amount of effort into the controller, which paid off looking at the final product. While the controller is not perfect, the systems we have built give us the opportunity to further develop the controls and mechanics of the game. For the production segment of the game, we have laid the groundwork for the rest of the title, which bodes well for our next segment of development.
0 Comments
This week was continuing along a trend that we set the previous week. After Josh and I designed the level, we split up as a group and worked on different parts of the level. Fairly early on into development, we decided that the level would be slightly more interesting if it was set on a space station.
As i was assigned the first scene of the level, I had a few goals and tasks to achieve to teach the player the mechanics. 1. Teach movement - both walking/running around and jumping (both single and double) 2. Teach players about AI characters and how best to avoid them. 3. Teach players that good items/collectibles are located off the beaten path. I came up with the idea for a station-based level primarily based off the concern that a lot of our areas would seem too 'plain'. Adding large, transparent areas in various styles as windows made the level feel a lot more interesting. For the first part of the level, I tried to emulate a standard lobby-type area, which evolved to one under construction when it came to achieving the goals of the level. The big crate is intended to force the player to double jump. The area is designed to encourage the player to first move left before moving right. Next, the player walks down a larger hallway, and has to jump over a few small obstructions (reinforcing jumping further) Next, the player is presented with an area that allows them to analyze the situation before they attempt it. They are granted vision of a guard on a simple patrol, and are able to see both opaque and transparent objects. The scene is designed to be clumsy for the AI to navigate smoothly, which aids the player further. Off to the side is the level's first 'treasure', on top of a desk. Such treasures will be used as rewards for players to encourage moving off the normal linear path within a level. Finally, this week I also was able to work on sound. I spent several hours recording and finding appropriate sounds for the game, and will implement them all with a custom sound manager on Monday. I have also found a 'main theme' for our title that fits the tone of the game. All that is left is the mad dash for the finish! Week 6 was mostly about our programming team working on alternative projects, while the rest of the team filtered back in after the Armageddon weekend. The feedback received was mostly iterated upon, and fell into a few different categories:
The biggest change on the title that I worked on during the week was to change the action buttons for the grappling hook. When using an Xbox ONE controller, I found issues with using the right bumper to attach the grappling hook to a grapple point. I switched the button to the trigger as an alternative, and found it surprisingly comfortable. I personally prefer the press-to-connect grappling style (like Wind Waker) but I understand why others would prefer it - it adds an extra level of complexity and meaning to the gameplay. I am unsure if it is an issue with the Xbox one controller or not, but the trigger felt far better than the right bumper. I have also started work on the first level, expanding and designing the initial level based on the feedback that we received. The introduction has been redesigned to introduce mechanics slightly slower, and will transition smoothly into an expanded version of the rest of the level. Next week I will focus on this area as well, fleshing out the rest of the level until I am satisfied that it is sufficient enough. This week was all about changes, and a new design philosophy.
After last week's progression, I was feeling optimistic about Armageddon. I was happy with the level design, and ready to continue adding to the content we currently had. I spent the majority of Sunday looking into the Super Character Controller, a unique open-source character controller based in unity, that seemed to offer all of the benefits we needed. Unfortunately, I concluded that the controller would not be useful, as it interacted with physics in a way that we were incompatible with. Because the SCC lacks a rigidbody and interaction with physics, as well as issues with trigger colliders, we were unable to use it. My attention then turned to improving the character controller. After working with the SCC, i assumed that i would be able to improve it by tweaking values, rather than rewriting scripts. After finding little success, I decided to purchase and add the Complete Physics Platformer Kit, from the unity store. Once I had spent some time with the package, modifying and adding functionality from our previous controller, I was happy with the control scheme and the ease at which we could go in and modify it. I continued to mess with and adjust the grapple and movement values - in particular the friction settings. After being stuck on a large amount of box colliders, I played around with the friction levels in earlier builds. The result: frictionless material was the most effective at the player not getting stuck on geometry. I have again applied frictionless materials to objects colliding with the new controller, and have enjoyed similar success. At the same time, the entire team was struggling with the concepts of level design, so on the Thursday we made the decision to scrap the existing level and begin working on smaller, easy to navigate areas where we could teach the player mechanics in a focused area. This is primarily for Armageddon and the Vertical Slice will have a more expansive (although still mostly linear) path that is based around teaching mechanics and then letting the player show off. I was completely happy with this, as I had begun encountering frustrations with how to design levels for large open spaces - the player was spending a large amount of time in the spaces I had designed simply running around, which did not make for particularly interesting gameplay. Moving forward, we will be taking an approach where the mechanics come first - even before environments are created - where we create an actual greybox before the rooms and styles are decided upon. Then, taking the puzzles into consideration, we will design areas that players enjoy playing around in. In addition to these changes, the vast majority of things I worked on were involved in populating the level, and the interactions between elements in the scene. I created a 'damage laser', which 'shocks' the player (currently freezes them) and disconnects the grapple, before dropping them to the ground. This adds an extra inconvenience to the player, which we did not have many of before. As part of the character rebuild, I have also tweaked and altered the animations again, and we have a new jumping animation to be added in on Friday, which will be a welcome addition to the player movement. Finally, the door object script was redone to work with Corne's door, which slides up and away from the player. In a way, the door script is endemic of the issues we have been having - design the mechanic (the script) receive the assets (the door) then have to redesign the things we have created to incorporate the assets we have. I think with this new design philosophy that the team has, we will work much more efficiently than before. The fourth week for our team was mostly about refinement of mechanics, and I have started building areas of the level. After watching and reading content about level design, I decided that moving forward, the level's rooms would be tacked with a tiered approach. The design philosophy was to introduce the character to the mechanics in a simple, sequenced way. Then, gradually build on this approach. Because of the large nature of the rooms, I decided to treat each of them as an entire 'minilevel'. From the beginning to the end of the room, I would teach the player the mechanic in its entirety. The first level, a large warehouse, was intended to teach the player platforming. Starting from the bottom, the player was supposed to move around the simple, pathed ai in a way that would allow them to dodge the guards, and make their way up onto the crates. Then, the player was required to path along the crates until they reached the end of the level. This area (unlike the other two areas) does not have a keycard required to move through this area. Rather, the player moves up along the crates, then jumps onto a gantry which they can walk along. The second area was supposed to include two levels, that the player could move up and down between by jumping up at particular points. The player had to acquire a keycard and use it to open the door, before progressing to the next area. This area had initial problems, with a lack of focus being the most apparent. I chose to remove the bulk guards from the below section, once the assets were put in. I again placed two guards in the area, with one rotating from a singular vantage point. The point here is to introduce the player to static guards, who rotate. Moving forwards, I may change around the order of the warehouse and the labs, because the order of teaching these different mechanics seems out of order. It would make more sense for these rooms to be the other way around, because the rotating guard is easier for the player to deal with. The mini lab again has a similar approach, with both guards rotating. However, the rotating guard behind the door has a different position command. He breaks his rotation to take a short walk around the table containing the next key card. This shakes up the rotating guard expectation that the player has – and by creating pressure for the player their expectations are shaken up. After these initial design thoughts, I had discussions with both Josh and Corne about the level design, and their concerns. Josh was rightly concerned about the size of the level, and the time taken to travel through and between the rooms. To alleviate these issues, I placed a large walkway along the top of the scene. The idea behind this was to allow the player to understand instantly that the bottom of the scene was an accessible, but not completely necessary, place to go. The elevated position also made it easier for the player to navigate around. After Friday, the entire level was concepted out design wise, and the only requirement now is to replace the greyboxing assets with the assets for the vertical slice completion stage. This week I also worked on the door, adding better support for moving up/down as opposed to rotating, and adding better cycles of animations. Because of the addition of double Jump, I feel like we might have to adjust the jump animations somewhat later on. This week for me was mostly about building the level. After Corne gave me the level assets, I set about putting them into the prison scene. Initially, Corne gave me prebuilt components. Some of these components were slightly out, so Corne pulled them apart into sections, which allowed me to rebuild the level in sections. The only problem with this method was that the mesh colliders did not work. This is because of the way that the mesh colliders are auto generated – because there were no roof or floor components included. This caused collider boxes to be drawn over the doorways and gaps, as well as weird colliders on diagonal pieces.
As a result, I had to craft all of the box colliders by hand, creating game objects and rotating them in order to make sure that the colliders were accurate to geometry. This took me quite a while. In addition to this, I also made the Laser-Alarm panel functionality complete. The Lasers are all stored as children of the Alarm Panels, which are alerted whenever the player walks into a laser beam. The lasers also use raycasts, which in the longer term will be more efficient (however slightly) than the cylinder colliders. During the week, I also implemented two key components of the stealth system – the percentage check, and the disguise system. The percentage check is a system that allows the AI vision of the player to change depending on how much of the player is visible. If the percentage of the player visible is higher, the ‘notice meter’ fills up much faster. If only a hand or foot is visible, then the percentage change is noticeably lower. This allows us to play around with variable percentage vision, and reward players who keep mostly out of sight. The disguise system was only completed today, but the bulk of the disguise tiers theory was done in the previous week. The disguise system now includes ‘accepted disguises’, as part of an area system. In certain areas, players’ disguises will be regarded as appropriate – meaning they fit into the level. For example, if the player is wearing a jumpsuit in a guard area, they will be noticed much faster than if they are wearing a guard outfit. This ties into the disguise percentage system, adding extra complexity to how disguises work. The plan for week 4 is to hook all of these systems up to the existing Laser and Alarm system components, which will allow for a complete level playthrough by Wednesday this week. This week has been mostly about getting the basic versions of mechanics in, and iterating on them in a way that allows us to play around with them. Firstly, I iterated on the greybox, adding a boxed in area that allows players to practice jumping and moving between boxes. This will allow us to tweak attributes like jump height, force/direction, and things like distance falloff. The jump mechanic may be tweaked in the future once the proper animations and model are in, to make it more suited to the character.
Starting on Tuesday, I began creating the ActivatableObject class. This class is designed to be implemented on top of objects that the player can interact with, like alarms, switches, and other objects in the scene. This class only extends to objects that cannot move – pickups are in a different category. I attached this script to a door object (which will also be in the game) and got button-activated doors working. Doors will sometimes be opened manually (if they logically should like a bathroom door) or be triggered by a button/other system (such as a security door). This class is what all of the other systems (alarm/button etc.) will derive from. From this point, I developed an alarm system that is designed to work with the stealth plugin to attract NPCs. When the player triggers the system, it is designed to generate noise in an area, which alerts the NPCs and directs them to the location of the alarm. In order to work with this system, I had to create lasers. The laser systems in the game are capable of moving backwards and forwards, rotate, and also stay static. The lasers can be turned off by interacting with control panels (the alarm panel). The alarm panel (through the ActivatableObject class) is able to be enabled and stopped by the AI as well, as it can be called during the wait time in the stealth plugin. The alarms, when disabled by the player, disable the lasers (which are child objects). The alarms are structured this way so that we can separate certain lasers if we want to, creating puzzles where only some of the lasers are disabled. This means that the players still have to jump/dodge some of the lasers. After Implementing all of these features, I added them to a simple greybox to test them, in conjunction with Josh’s camera scripts. The camera functions well in the smaller environments, as do the lasers. Because the camera can now rotate vertically, it is much easier for the player to make sure they dodge the lasers. The lasers create an interesting environment and tool for us to play with. In the overall level designs that we follow, we will be designing around these lasers – the potential for different, interesting patterns is huge. Of particular concern right now is the movement system – more work needs to be done on making sure that the character does not feel ‘slippery’, and that the movement feels relative to the footsteps. This will be achieved and tweaked towards once we have the new character model and animations in the game, as we will be able to tune movement speed, animation speed, and other variables. The feeling of ‘skating’ should be eliminated soon. The plan for next week is fairly straightforward – make sure that movement (in all axes) feels good, then make sure that the basic iterations of the mechanics feel fun. Currently, we have both the experimental greybox and the first iteration of the tutorial level greybox in the game, and we are able to begin testing mechanics and how they will work. Our first week was mostly about the group deciding on the direction that we want to take the prototype. After changing the prototype, we were moving forward with, there was a brainstorming session. Mechanics and additions were discussed, as well as a potential narrative context for the game.
The decision was made to move away from restricting the team to a general office section, and more towards instanced environments. The initial concepts that were discussed revolved around ideas of museums, scrapyards, and the final, tutorial idea of a prison. The decision to move in a nonviolent direction - avoiding using weapons or combat altogether – means that our mechanical design discussions revolved mostly around gadgets. The goal for vertical slice is to implement a few of these gadgets, as well as creating a play space for the players to experiment with tools. In the first week, I implemented a gadget system. As part of this, I had to examine and add all of the XBOX controller bindings, which was challenging in the cases of the triggers (in determining which axes they use) and the D-Pad. Once these changes were in, I was able to create a gadget framework, which let players toggle between usable gadgets. After this, I implemented the extendo-hand, a concept for a gadget that involved ‘firing’ a hand. This hand enabled players to pick up items from a longer range, allowing them to stay out of sight of the enemies. Conceptually the extendo-hand is quite interesting, because it offers opportunities to let the player take items from out of the sight of enemy NPCs, allowing them to remain hidden while acquiring items. I really like the idea of the extendo-hand and I can see it being used both to hilarious and useful effect later on in development. Currently the hand ‘returns’ to the player if it touches an object the player cannot interact with. On the Friday I also implemented the jumping mechanic, and made sure that it felt right for the existing character. Jumping as a mechanic is something that will be quite important for our game. Because of our decision to switch to a 3D platformer style of game, jumping must ‘feel’ good. The jump functionality itself is quite simple, and the presentation of the jump will be tuned to these values to ensure that jumping feels ‘satisfying’ in the game. To go along with these jumping mechanics, I also created a small, basic environment to play around with the character. This play area will be useful in the future when we move forward with the new gadget we have decided on – the grappling hook. During the week we made the decision to focus on the robotic arm that the player character possesses, meaning that we have some restriction on the gadget tools. Rather than creating a bunch of independent gadgets (ala Ratchet and Clank) we have chosen to focus on making ‘tools’ for the arm. The grappling hook was the first result of this idea, and on Friday both Dylan and I created basic versions of the hook. In the second week we will further develop the tool and it should be finished by the end of week 2. Jumping values will have to be tweaked later on, to make sure that they feel appropriate for the new character. The character will most likely be shorter, meaning that we will have to alter jump values to an area that seems more logical for the character. |
AuthorContrary Scholars ArchivesCategories
All
|