|
Patch 16 was Fallout 76's holiday update for 2019, bringing about all sorts of new goodies, bugfixes, and an event to boot. However, a bug was found rather quickly that required Bethesda to roll back one such bugfix. With Patch 16 came a bugfix for the infamous +250DR while reloading legendary attribute, which hadn't been working for quite some time. However, this bugfix made it so that reloading weapons nullified the legendary effects on your armor, until said armor was re-equipped. So, I decided to run some tests to attempt to figure out what exactly might be happening. My build and how it helps the tests Some of the following information won’t be relevant to the experiments themselves, but including it for clarity. I run a bloodied/bolstering build, which I feel will be helpful in testing out what is going on after a reload since my stats will change drastically, both on my armor and on my weapon. Both legendary types have to be calculated/scaled according to my current HP and applied both when you equip the gear, making it easy to see huge changes. The lower my HP, the higher both of these values are. Especially damage, since Adrenal Reaction and Bloodied increase damage as HP decreases. Mutations: ADRENAL REACTION and SPEED DEMON Relevant Perks: Evasive Rank 2 (15 AGI for +30 DR), and +30% Damage from three rank 1 Gunslinger perks Relevant Current Gear Stats: All equipment is repaired and equipped. The following stats were modified to reflect my HP, which is 28/200. This table does not include SPECIAL increases since I don’t feel they’re relevant at all to the tests. Further, I am not well fed or well hydrated (nor am I in real life... for consistency's sake of course). Further, I was going to include the Bloodied 10mm SMG since it has a secondary attribute that increases reload speed, but I didn't test it before Bethesda rolled back the update.  BLOODIED BLACK POWDER PISTOL I chose this one since the window for the animation is large, and it’s easy to see when, during the reload animation, the stats are modified. Firing the gun and seeing that Bloodied is actually removed and reapplied during the reload animation. However, the clip’s ammo seems to be restored at the very end of the animation, so I see they’re not tied together. At least, not at the same keyframe. Also, I noticed an interesting bug I hadn’t noticed before. In the bottom right of the pip-boy, my damage reads 599, an incorrect, outdated value (it was 599 before I adjusted my HP back to 28/200). After reload, it’s refreshed to almost the correct value, but is one unit off. Not super relevant, but figured I’d point out the UI updating/rounding bug anyhow.  Here, we see the Bloodied effect of the weapon be removed and reapplied.  Here, we see that my armor is giving my character the incorrect DR because the Bolstering effect has been nullified. THE DRAGON I chose this one since the window for the animation is large too, but I also wanted to see if non-legendary weapons had an effect on the armor. I assumed not, because my hypothesis was that only legendaries were given a special reload callback/event to get the 250DR legendary effect to work by granting them a set of stats, which was cleared at the end of the reload animation. I also hypothesized that’s why legendary effects were removed on reload; I wondered if this “stat set” being removed is taking the legendary effects with it. I was wrong about it being on legendaries only. I wonder if the aforementioned process is experiencing a run-time error, requiring the gear still needs to be equipped to reapply the stats.  Non-legendaries are also removing legendary effects on reload. TWO SHOT RIFLE, +250DR FLAMER Wanted to see how other legendary weapon effects were handled when reloading. To my understanding, two shot damage is reflected in the damage of the weapon when looking at its stats in the Pip-Boy. I saw no difference when reloading like I did when examining Bloodied, where the effect was removed and reapplied. In the flamer's case, I believe Bethesda when they say they fixed this attribute. Since I saw no change reflected in the Pip-Boy when examining my DR, I feel this supports my claim for a run-time error. Such an error would prevent me from seeing if the 250DR attribute is working, but would explain why Bethesda felt it worked on their end before pushing the fix. ConCLUSION What did I gather from this? Well, the following is probably a hot take, but is my best guess.
Without being able to look “under the hood”, I believe there’s a run-time error occurring when checking/calculating a player’s DR, and that this check is happening EVERY reload. This run-time error is likely scrapping the primary legendary effect of the armor, and preserving those of the primary weapon.
1 Comment
It was time to start building: I was happy with my movement and had quite a few level chunks to work with, so I started building one of three planned areas: The Catacombs. They're planned to be exactly as we know them: cramped, mysterious, and maze-like. These characteristics were considered heavily in my design. The Catacombs are not the player's first experience with the game. However, since the game is planned to be open-world, it's possible the player has not yet been exposed to certain concepts, like breaking wooden walls. So, I wanted to have a dramatic entrance that illustrates this (note that I have not yet built the lighting):  Here's an applied and tweaked version of the chunk you might have seen in the previous post. Here, the player is forced to learn about wall jumping if they haven't already (this will be useful if I release The Catacombs as a standalone demo). If they don't wall jump correctly, then they'll learn about the water (which pushes them back). I have plans for players to be able to use the water to their advantage in other areas.  Here's an overhead view of the "turbine" section you might have also seen in my last post. The player enters through the duct at the top, and must navigate counter-clockwise until they can get to the duct on the right.  So in my previous post, I mentioned that I could begin prototyping movement and start designing level "chunks". I'm just calling small bits of a level that involve a particular idea or challenge that. Part of why I started working on this project was to work on my level design skills (I usually focus more on the programming side of things). So, I grabbed a stack of index cards and started scribbling. Here are a few:  These by no means represent what actual gameplay will be like, but are merely ideas.
I admit that coming up with a huge world composed of level chunks using only the mechanics I had in place from prototyping (wall riding and jumping, bounce pads) had proven difficult. So, I added some more easy-to-implement mechanics such as flowing water and platforms that topple, and designed more chunks. I've made sure not to get too carried away with this, since I don't want too massive of a world or create a larger demand for graphical elements, since this is a solo project and I have other projects already underway. Keeping it detailed just enough to get everything that's happening in the chunk was the goal for these. I wanted to leave room for change and only illustrate a basic idea of what type of "gameplay moment" the player would be experiencing. Marbelous at its current stage is set to be a collect-a-thon platformer that rewards players for exploring and thinking outside the box. It's heavily inspired by the old Marble Blast games and Banjo-Kazooie. I wanted movement in Marbelous to be a little bit more stiff than in games like Marble Blast, only because I wanted players to be very deliberate with their movement. As a result, I predicted that players wouldn't be holding down the W key all the time, and instead holding it down only when they wanted to gain a lot of speed (uncapped speed was another feature I wanted). However, aside from this deliberate "stiffness" I also wanted movement to be fun and expressive, which brings me to another feature I was dead-set on having: wall jumping! I also added the ability to brake, allowing players to slow their momentum at high speeds. With the previous in mind, I started to prototype movement in Unity3D (where I would build the rest of the project). Getting a ball to move and jump how I wanted was easy. However, what I wanted was to be able to jump based on collision normals instead of just the ground, or even just one wall/normal. My goal was for the player's jumps to be divided among each collision normal for that frame. So, I needed to keep track of every collision the player is experiencing before it jumps. I couldn't do this by getting each normal when it jumps, since separate collision events aren't easy to read from outside of the collision event methods. So, every time the player has a new collision, I'm storing the new normal in a list from inside OnCollisionEnter() (as long as it's not a duplicate) and clearing it at the end of FixedUpdate(). Doing this would also solve the issue of jumping twice off of one surface, if that surface was comprised of two different colliders. An issue I ran into with this, however, is that floats aren't extremely accurate since they lack the precision that doubles have, so in the code I'm rounding off my calculations before checking for duplicates.   This isn't very pretty, but I'm not concerned with pre-optimizing the code in the prototyping phase. This allowed me to begin perfecting my movement and ensure that movement feels great before continuing on. Afterwards, I could start prototyping what I'm calling level "chunks"—small, low-effort parts of a level that revolve around a particular idea or exercise.  With our new team developing Gaia, we have made quite a bit of progress in the last month. First, we scrapped whatever semblance of level design we started with and brought on someone to do our level designs. Here's what our (nearly finished) forest level looks like:  Note that the first level is simple and serves to teach the player how to use basic movement mechanics and to collect the shards (which will give the player their first set of combat abilities). It also introduces the player to simple enemies (denoted by the orange cylinders) which will be implemented shortly. Up near the top, you can see placeholders for vines that the player can climb up. We may remove these altogether and replace them with ladders that the player can climb, since these are the only two positions vines are to be used that we have planned so far. Thank you for being interested in the development of Gaia! Please check back periodically for updates! The following updates were made to HyperType on 2/4/18:
Thank you for being interested in the game's development! Check the Projects tab for downloads, pictures, and other fun info if you haven't already. I know I haven't been maintaining the blog here, but now would be a good time to start outlining the development process of some of my projects, starting with my submission to VandyHacks IV. The devpost submission can be found here.
My team and I (three people in total) were responsible for coming up with a hack in thirty-six hours. We knew going in that we wanted to develop a game since it was our first hackathon and given our team's familiarity with game development. We wanted to do something that most of the other teams weren't doing, so we decided to use Microsoft's Mixer API (details on this can be found at dev.mixer.com). The Forest: A Mixer Interactive Game was born. It wasn't easy though. We hadn't finished a game in 3D before, so object manipulation in 3D space was a bit new to us. However, most of the issues we ran into involved the Mixer service. Let me start by saying Mixer's API is a dream to get started with. It was easy to get our project interactive on mixer, and mixer's website provides a nice interface for building controls for viewers. Interfacing with the API wasn't difficult, it was using the service as a developer that was a bit of a pain. Getting out instance of the game connected involved the following steps (in loose order):
After these, launching the game should let all allowed Mixer users interact with the controls built on Mixer's website. That wasn't always the case. And we could never figure out why. Sometimes it would work, and the viewer would get controls. Other times, it wouldn't work, and we hadn't changed anything from when it did work. No one else was having this problem on the internet that we could find. With little to no information on developing for Mixer, we just had to press the play button and hope. Aside from that, another barrier we faced was our lack of sleep. I only got three hours of sleep the whole weekend. That's the nature of the beast when it comes to Hackathons. This part of my portfolio is under construction. It will showcase various games I am working on and the challenges I run into while developing them!
Stay tuned! |
BY MONTH
December 2019
BY GAME |
RSS Feed
