Sorry For the Delay on this one! Crunchtime can make it hard to find time to write these dang entries.
Anyway I wanted to detail another major mechanic of A Belly of the Beast: Bullets! Or rather Antibodies. A core part of the game is the usage of the first person movement mechanics to avoid and contend with a large number of onscreen dangers at once. In order to highlight and make the most of the high-agility nature of the movement system, which is by far the most polished and best feeling part of the game. The second reason the team settled on this for our combat system, was because we dont have a classically trained programmer on board the team. In fact our team is made up of just 2 game design majors and 2 game art majors. Since I was the member of the team with the most programming experience, and best working knowledge of the engine, I’ve been pulling double duty as both designer and programmer for the game. Because of that, I wanted to make sure The system I designed was also something I could realistically Implement given the scope of the project and structure of the team. So instead of having a small variety of “intelligent” reactive enemies, I thought that using a large number of very simple enemies could also be challenging and exciting. I looked to bullet hell games, and their use of complex patterns. Now, I’m very bad at bullet hell games, and I didn’t want to emulate the frustrating difficulty. I wanted the player to feel incredibly empowered, but frantic. This led to, as you’ve probably guessed if you, the turret system. But the Turrets needed to fire bullets. And that led to the bullet class. The bullet class is probably the worst coded piece of the game. I should have buckled down and build a manager class, among other things, but by the time I started realizing my mistakes, the project was to far along so I had to hack together a solution, and make each individual bullet as streamlined as I possibly could, while guarenteeing garbage collection wouldn’t miss them. My results were, mixed, to say the least, but overall I’m pleased that I managed to squeeze as many possible frames out of it as i could in the time.
There are two main types of “bullets” homing ones, that have been demonstrated previously, and linear bullets, or bullets that just fly in one direction untill they hit a thing. I got them both working, and If it wasnt almost 10:20 I’d upload some gifs of them but I cant right now so mayber laterr.
So this last sprint was crazy. I’d been noticing for a few sprints now that our art simply just wasnt where I believed it should be given the state of our game. Everytime I’d come into work on the project it felt like there’d been no changes or additions to the art of the game. So I decided, after contacting the rest of the art team, to do some quick overhauls of materials in order to make the game look more presentable.
After Clearing my intended changes with the art team, the first thing I did was implement Subsurface Scattering to all the materials that were made of, um, “flesh” and –since this is a game about being stuck inside a giant, planet sized space whale– that ended up being a lot. What this ended up doing was adding a lot more depth to the flesh of the walls and interiors of the spaces. That is part of the benifit of having an art style thats made up of gradient patterns; it creates an interesting clash between our low-poly, gradient artstyle and the more accurate lighting. Its almost comic-booky, or at least very stylized. Its one of my favorite parts of shader work, if you let the material do the work for you, you can ease up on some of the texturing side. (Actually this leads me to a side note where one of the art-styles I floated as a possibility was writing a custom fragment shader that would quantize shadows based off of a supplied LUT creating crosshatched shadowing on materials. This plan fell through when I realized that Unreal doesnt expose light vectors in its material editor– that and I didn’t know how to convert my GLSL knowledge to HLSL code)
Actually that picture brings me to the other big material-side change I implemented: Emmissives! I freaking love emmissives, they can add so much to a scene. The idea was that I would add pulsing emmissives on the mushroom spots and lighter parts of the “plant”. There was a bit of an issue: I didnt want the mushrooms all glowing in phase with each other; but both types of mushrooms shared a single texture. So I booted up photoshop and masked out each of the spots on the mushrooms to their own channels. from there I multiplied each of them by their own original spot color, times an emmissive Max. I then lerped in between those two values based off of the sine of current game time, giving us two different glowing mushrooms off of the same texturesheet, that pulse intermittently.
I also took advantage of the new subsurface scattering by adding in an area light to give the walls of the level a bit more of an ominous fleshy glow.
I also made a vfx for when the player Air-Slams (a move that knocks away most projectiles and launches physics objects). It was a pretty fun problem to solve. I knew I wanted a sort of ripple effect away from the player, so there had to be a refraction shader involved. What I ended up doing was taking a very low poly sphere, inverting the normals of the mesh to turn it inside out, and then built a refraction shader that could be manipulated with dynamic parameters. The result is pretty nifty:
I also did some standard coding stuff, fixes, and improved implementations but that’s not as fun to talk about
So, This week I had to catch up on my other classes. Last week I spent a considerable amount of time working on this project in order to get mechanics to a testable state. That left this week for me to take a lighter workload.
I didn’t really add much; the biggest thing was a fix that stopped bullets ignoring collisons and basically becoming unkillable monsters that just floated around the level for ever. It also handily stopped them from clump up on each other making a single deadly Murderball. I also did some minor health adjustments based on feedback.
Oh yeah. And I refined the turrets so they allow for more variation. I added a series of new projectile types, there are both homing projectiles and linear projectiles now; as well as variations that are immune to airslamming and explosions. In addition designers can now customise the order and timing of the spawning of the projectiles. I intend to add a bit more to this, and since I’ve basically entered mechanics freeze.
I’m going to sleep early tonight so I’m not going to elaborate much further this week. It was essentially a recovery and adjustment week for me. I had to revise a few things based on Team Feedback. Maybe I’ll upload a video or gifs later.
The combat system I’ve designed and started implementing for Belly of the Beast has its inspiration in bullet hell shoot-em ups. I like the idea of avoiding a huge number of projectiles that are moving in interesting ways being the focus of combat. The benefits of this design decision are several; It cuts back on the amount of AI coding I have to do in favor of more script-able “patterns”. The Focus on projectile avoidance plays into the existing movement mechanics as well, teleport dashing, and double jumping are helpful in avoiding these projectiles. Additionally Airslam now propels projectiles away from you.
As I was testing this new iteration I found that the grenade only exploding on impact made it very hard to deal with the sometimes worrisome number of bullets the turrets were spawning at me. So I built a mine function; left clicking now launches a remotely detonate-able bomb. Right now its just the same damage numbers as the regular grenade function.
Actually on the topic of Grenades, I finally got around to creating a grenade swapping system and better handling the Grenades in an easily extendable way; so new development will
On top of that I also began figuring how I was going to limit the players considerable firepower. In other words, a reloading system. Although technically its not really a loading system at all; its a charge system. Not charge as in Samus Charge beam (though that might be worth investigating); basically you have a certain amount of energy, and each grenade consumes a certain amount of that. You very slowly gain charge back naturally, but it also has a chance to spawn when you get hit and are below 50% health. If you are at absolute 0 you can reload one grenades worth of energy by slamming, as long as you currently have less than enough ammo to fire a grenade. This isn’t fully implemented yet, I hope to get it in this next sprint.
There are several significant bugs and the room that I set up for testing was poorly laid out; but despite these things the test went moderately well.
Thats it for this weeks update. Sorry It was so late
Since its October, and apparently #Blocktober, I wanna share a bit about how we’re designing levels for Belly Of The Beast (working title)
For This Showpiece Level, We started at the concept for the game: A First Person Metroidvania-like game set inside a giant space whale We Brainstormed how we should grey box this in a way that could also help convey the form of “inside an alien creature”
I’m absolutely in love with the concept art. Its fun and cartoony and dynamic and visually interesting and the color scheme is great. We took these images as inspiration for how to design our levels.
I created a metrics document to ensure that the rest of the design team were all building levels to the same specifications. (Boost Jump Height is 10 meters, Dash Distance is 7.5 meters, the minimum width for a standing platform is 6 meters, etc). From there the design team sketches out a overview of the level and diagram out the basic flow. (I Wish I took a picture of the whiteboard to show that bit of the process). After we all agree on the basic events and beats to a level, I begin primary blocking out. This time I had work to do for other classes which meant that my Level Designer, Ian Cotner completed the second half of the block out. When he was finished I reviewed the level and gave him notes, suggestions on how to improve the flow of the level and add more dynamic gameplay.
As this is our first time putting this level pipeline into practice, and as this is the very first level we’ve created for the game; it obviously has a lot of rough edges and is far more simple than what we have planned for the final product. But For a proof of concept I’m rather pleased to have it in the state that its in. The next phase is to have our enviroment artist, Tim Chartier do an art pass on it.
Next Devlog is going to be on the big question haunting this project since it was first greenlit.
Its not even 4 days into the new sprint and I’ve already implemented a bunch of changes to the way you jump. Mainly I added a mechanic called “perfect Jump”. Because this game is supposed to have a degree of skill involved in it, I added as system where, if the player times their double jump so that it’s right near the apex of their jump, the double jump launches them in the direction they’re currently moving, changing direction on a dime. On top of this it also boosts the amount of air control they have to its maximum.
I consider Perfect Jump to be like, getting a headshot, but for jumps. A sort of “Critical Hit” but for jumping. It’s by no means required for the player to complete the game, but its an advanced skill that adds a degree of skill to jumping.
This is all well and good in theory, but currently there’s sometimes a weird hiccup where sometimes, the player looses all motion and I havent quite been able to figure out why yet. But I’m convinced I’ll figure it out tomorrow. Probably.
These sprints have continued to be more and more productive from a sheer code and implementation standpoint. Honestly being able to implement all of the mechanics and develop the core feel of the movement is going to be extremely useful if this project continues on for further development.
Current Emotional State, In Gif Form
I’m quite busy working on turning the movement tech demo that I’ve developed into a full prototype for the purposes of passing the challenge. I’ll list what I implemented below:
refined movment based off of qa feedback
implemented controller support
added a death state
added health pickups
refined placeholder effects
minor tweaks to debuggrenade
And Here’s a gif of a build that took in the middle of this sprint (sprint #3)
So I really love Unreal 4’s Particle Editor and their whole Particle Workflow in general, because it lets me do stuff like this:
(Placeholder) Visual Indicator for the Forward Teleport-Dashing Mechanic.
The yellow flash in the viewport below isn’t its own sprite or emitter. I’m manipulating the emissive color values in that single emitter’s material flowchart.
(A snapshot of the material flowchart and the basic layout of the Particle Emitter.)
I’d been getting a lot of feedback from people, including members of the team that; partially because of the sameness of the dev enviroment ( the basic grid material sorta blends together after a while), and partially because of the particular input for how I’m prototyping the mechanic (Currently you double tap in the direction you want to teleport, in case you were curious); it was really difficult for people (even those playing) its sometimes easy to not notice when the play has teleport-dashed.
To combat this I wanted there to be basically a frame or two where the players vision is mostly obscured, but otherwise unintrusive, something that would show the player: “Hey, you just did this thing” in a way that isnt just printing words to the screen.
So I decided to rig up a particle system to play a rough version of the sort of effect I was detailing when I was concepting this mechanic. A sorta “Shards of reality breaking apart as you tear a hole in space time” sort of thing (Minus the obvious post processing shaders I’d need to write to get the proper “Broken Glass” effect I’m imagining). I used a Dynamic Parameter to set a scalar value thats multiplied by a texture map to amplify the emmisive values. I then manipulated this value at runtime using the Dynamic module in the Cascade Particle Editor’s curve tool. The resulting effect ramps down in a span of only 2 frames from 10000x the base color to just under 5x the base color.
I only really briefly looked into Dynamic Parameters, but from how I understand it you could concievably use it to alter things like individual particle’s position via a blueprint, which could lead to some pretty awesome effects, like bugs that actually cluster near light. (by setting the World Position Offset of the particles to a vector distance from the nearest light, which is calculated in a blueprint).
I don’t really have anything else to say, so instead here’s my favorite visual effect I’ve ever created in Unreal Engine 4:
(The GPU Sprites Typedata is so much fun to play with)
I’m always bad at figuring out how to structure these sorts of posts. I guess I should just start writing.
The difficulty with these kinds of projects– the kind you have to do as a class– is always scope. You really need to consider scope. It puts a damper on creativity, having to think “Do I have the resources and time and skills available to pull this thing off?” ever time a new idea enters your head. I ended up with a list of 10 ideas to contribute to my teams brainstorming session. I considered everything from a janitorial RTS to a VR melding of “Keep Calm and Nobody Explodes” and “Steel Battalion” Above all of those, my favorite idea that I pitched was of the “Highly Agile FPS” In its initial concept it was a Multiplayer Couch Competitive FPS with an emphasis on fast paced and vertical movement, and the inclusion of only splash-damage based weaponry. Players would take damage in the form of “Launch Percentage” Much the same way that damage in Super Smash Brothers works. The more damage you take, the higher and farther you fly. You would score points by knocking people off the floating arena you would fight in. Obviously this idea would need to evolve as the team iterated through the design process. I was fairly certain this particular idea would be picked by the team. It also helped that I came to the planning meeting with a limited prototype already underway to showcase to the rest of the team.
(Inital Prototype Brought to Planning Meeting)
This prototype had a series of issues and poorly implemented features but it was strong enough to impress the rest of the team and I was given the go ahead to iterate on what I had brought to the meetings as one of three ideas that the team was going to prototype for this first goal.
As of the end of this sprint I’ve managed to firm up the controls to a point I’m honestly really proud of. But the biggest achievement was definitely getting the grenades to affect the Player Character. Because the CharacterMover component fakes its own physics interactions, I had to build my own impulse vector, which turned out to be a lot harder than I expected.
Eventually I’d like to document exactly how I went accessing the CharacterMover’s add impulse node, as well as the math that went into the solution, but its almost 11PM and I want to get some sleep.
So thats where I stand with the prototype as of the beginning of this new sprint:
(The current state of the prototype at the end of the first sprint)