Floor Plans and Forges

What an absolute monster of a sprint, with a damp squib of an ending.  The majority of my focus on the sprint was to wrap up character controller improvements and implement later-stage changes to the game design document. Over the course of Sprint 3, we realized that our game didn't have enough compared to both other people's projects and in terms of a unique movement mechanic. This was problematic, and we set out to make new cards in order to remedy this issue. We decided to slowly drop the idea of a fruit-based golf game and instead focus on what testers actually enjoyed; jumping and moving around freely. As it turns out, players don't like arbitrary limits that strangle their ability to play the game how they want.  Freedom! Over the course of sprint 3, and into sprint 4, we worked on providing more options to the players, allowing people to make a more precise jump using the ground slam ability, creating a charge arrow to indicate direction, and adding keybinds to chang

 What a playtest! This sprint was a big come-to-jesus moment for the team; essentially, the focus was on tightening what we wanted from the game and develop towards something meaningful. We acknowledged what wasn't working and what was too vague and attempted to remedy it. We met three days in a row, drafting new cards, figuring out what we needed, and focused on strict prioritization. Everything we needed for the playtest was given its own separate category and prioritized first as a 'mini-sprint'. All of these were completed in time, and it paid off.    The mini sprint label we used to tasks that needed to get done before the playtest. My focus for this sprint was to further tighten up the controls, revamping everything so that the player felt good to control. I made it so that the fruit always moved in the direction of where the camera pointed, making it feel more organic. I set up the camera to pan in and out when the player was ready to jump. I also added a 'slam&#

I hope the next time my team lead sees me programming some esoteric bullshit, she tazes me in the neck. Not to start this sprint recap off with negativity, of course. I feel as if the amount of cards I had to complete were completely disrupted by my need to completely overengineer a solution to a problem that didn't exist. This is entirely on me and something I should've brought up beforehand. When I started discussing this problem with my groupmates, I realized how ridiculous it all sounded in my head, and now I feel like I have a clearer idea of what I need to do. So let's go into it. I put myself in charge of me getting a robust physics objects system in the game. This meant, for me, a need to create an elaborate and robust object spawning system, where designers could put values in a spreadsheet and have them instantly transfer over to the game on runtime, with a GPU-friendly batch spawning system that. . . Yeah, you can see the problems here, can you? We can count the

      Unity confuses and terrifies me. I like languages without memory management, modern conveniences, garbage collection, and robust libraries exclusively for Game Development. I know; I picked a wonderful major. Chances are I'll never have the need to build a game engine from scratch using C, even if I'd love to walk the path of John Carmack, so, better cope with it and get used to what Unity offers.     My role for this sprint was primarily setup. Everything has to be a good foundation for the designers; I am taking the responsibility to make sure they don't have to touch a single line of code, and have the capability to change values in a way that's easy to understand and gives them the most flexibility possible. This divides my job into three important tasks:     - Create legible Inspector code (using headers)     - Provide console feedback whenever something happens (or goes wrong) for the sake of easily debugging it.     - Always keeping the code in a runnable s

 Hate to say it, but this entire thing needs an overhaul. Especially if I want it to meet the required playtime. I definitely need a strong platforming section, especially to demonstrate the player slowly ascending to the top of the tower. There's an entire narrative I can fit in that's just not described at all within the project as a whole, it's a blatant rush job that makes no sense. Fortunately, there's worthwhile bones that have the space for extending and modifying. Narrative zones to provide context and hints are an easy addition, very low opportunity cost for the value they bring. The level itself needs to be massively extended, two more teleportation zones, likely including one more indoor area followed by an outdoor section should very easily meet the playtime. Current boss is unsatisfying and needs more hit points in order to feel substantial. Scaling it was a bad choice due to the issues that creates with the hitbox, but that's something that can be fixe

  We can fix it a little. Probably.       First thing that had to go was the invisible borders. Completely uncompelling, made for unclear boundaries, and it was a major issue aligning it with the prebuilt plane geometry (which was also a bad idea, since backface culling creates major holes in the environment thanks to the free floating camera). As it turns out, aligning invisible walls is a major pain, and fixing slight corrections becomes a major chore, since the outline gizmo is thick enough to create slight cracks when it looks aligned.        You tried. A blatant crack in the wall.     So, absolutely none of that. Replaced them all with normal, functional, boxes. The dull boxes to create boundaries could be improved upon in multiple ways. They are functional albeit thoroughly uncompelling. The addition of trees does not change the fact that they are angular, poorly aligned, and uninteresting. More functional than interesting. We can move beyond whiteboxing by manually adjusting the