Inspiration in Its Purest Form
Dev log for Elementary from 10/2/18 to 10/16/18
Welcome to the inaugural development log for Elementary. Just as I did with Project Amethyst, these logs will focus on what I have been working on since the previous update and how I did it, what I had trouble with, and what’s to come. As this is the first post for this project, the “so far” section will be quite short. In light of this, I will be doing an extensive breakdown of my ideas and inspirations for the game in the “what’s next” section. Enjoy!
What have I been working on so far?
Short answer: not much. I started with the variable jump and tried to get a good feel for that. By the way, creating a variable jump requires manipulating just one variable on a Character class in Unreal: JumpMaxHoldTime in the class defaults. Making this number anything greater than zero will allow force to be continuously applied to the character so long as the jump button is held down, capping at the value of said variable. Combine this with tweaks to the JumpZVelocity variable on the character’s movement component and, boom, a variable jump.
Next, I turned my attention to the particles that orbit the player at all times.
Currently I have the spheres as child objects of invisible rings on which they orbit.
Originally, these rings were meant to be visible, but for the time being I have decided that the particles will orbit on invisible paths as the rings seemed too visually distracting and took up too much space. The only reason they are still attached to the player right now is that their centers act as pivots for the particles to locally orbit around. I will soon replace them with either a spline system or something like it so I can actually make the attack function as I want. This will eventually become the primary attacking mechanic (which I will explain later).
The only other thing I have done so far is a very primitive version of a mechanic I call “burst”. This allows the player to temporarily become invulnerable to enemies and will also stun them for a moment is the player passes through them. Visually, this mechanic is supposed to see (pun intended) the character explode into a ball of smoke and then reform. All I have right now is the character turning partially transparent, which I spent way too much time trying to manipulate the default material on the Unreal mannequin. Turns out masked and transparent materials are mutually exclusive; so, for now I just swap out the material for a completely different one.
What obstacles have I encountered?
Upon starting this project, I came to the realization that the problems I would face here are much different than those I frequently encountered on Amethyst. In that project, I often found myself attempting to untangle logical knots as the game was very systems heavy. This, though often taking some time and discussion, was genuinely satisfying to come across a solution. I very much enjoy hashing out systems like that and reaching (stumbling upon, more often) a solution is thrilling.
Now, with this new project, I face very different beasts. The challenge in designing a game such as mine lie in the implementation and construction of the player’s arsenal of actions. Simply finding the best way to write one of these mechanics has so far been more challenging than conjuring up back-end systems. Take my breakdown of the particle spinning mechanic above for example: right now, it looks like its supposed to, but making it function as I want is impossible based on my current rudimentary setup of the feature.
Thus, I will be putting nearly all of my attention into the player controller before even thinking about environmental mechanics or design. It will require lots of playtesting and tweaking to even get into the ballpark of where I want it.
What's next (feat. what inspired me)?
As I briefly mentioned in my announcement of this project two weeks ago, this game will be heavily influenced by three games: Super Metroid, Metroid: Samus Returns, and Ori and the Blind Forest. Both Super Metroid and Ori were games I played through specifically for research purposes (and because they are both amazing games). Before I go on and ramble on about my plans going forward, I would like to outline what elements from each of these games influenced me the most.
Starting with Super Metroid, the biggest lesson here is the way the world of Zebes is laid out from a level design perspective. SM can be broken down into two distinct halves, the first being quite linear, and the second being much more open. SM also does a fantastic job of making sure you never truly get lost and leads you so subtly to each important milestone that it feels like you are stumbling upon them yourself. The way the designers used the array of different powers and abilities to simultaneously restrict and guide the player was brilliant. If you are interested in a deeper dive into these concepts, check out this video that heavily inspired my takeaways. The thing I dislike most about SM was the way Samus controlled. Maybe it’s just because the game came out before I was born (yes, seriously), but everything felt a bit stiff and muddy. I had particular trouble with wall jumping, shine-sparking, and space jumping; each of which I frequently had to attempt multiple times before getting the desire result.
Next is Ori and the Blind Forest. Despite my raving review of the game on Twitter, there were actually a few things I didn’t like. My biggest complaint is the skill tree system. Having previous experience with only Metroid games, I felt that the skill tree was a completely unnecessary system and is honestly distracting. Having just the key abilities highlights their core uses more. Sure, damage boosts and energy efficiency upgrades are nice, but still not required. Also, and this is a problem that seems to be exclusive to the definitive edition, I found myself spending skill points to unlock upgrades for abilities I never got (even by the end of the game). Anyway, onto the things I did like about the game, first and foremost, the player controller. The way Ori controls in this game is incredible; easily one of the most fluid and well-polished controllers I’ve ever used. Period. Movement speed is great, jumping (especially double and triple) is super responsive, and wall jumping is effortless. This is in stark contrast to Super Metroid for reasons I mentioned above. Needless to say, I will be looking to Ori for guidance on how my controller should feel. I don’t realistically expect to ever get something as smooth as Ori, but that won’t stop me from trying. The other major thing I liked about the game was the world design, which I will talk more about when I get to that point in development.
Finally, we have Metroid: Samus Returns which I take the least from. The main idea here I intend to borrow is the 360° aiming. Returns had, to a healthy mix of praise and criticism, a supped-up combat system that included a melee counter and free aiming (at the cost of standing still). The melee counter partially inspired my burst mechanic and the advanced aiming is something I intend to replicate exactly. And that’s pretty much it from this one. The level design is much more linear that what I want, and things like the teleporter system don’t seem necessary at the moment. The controller at least felt better than Super Metroid’s.
Now, with that out of the way, I can move onto how all that applies to what I will be doing. First off is attacking, which will function neither like Metroid’s nor Ori’s. Here’s a really terrible sketch of the two attack choices and how the orbiting particles react:
Yes, the player character is supposed to be a black amorphous blob. Its name is Quark.
To elaborate, the particles in the standard attack will boomerang out in front of the player one at a time and inflict damage on anything they touch. Then there is the charge attack which will launch all three bits out in unison in a large sweeping attack. Both of these methods will be able to be aimed freely like in Samus Returns. The effects of these attacks can be modified by creating different atoms.
Speaking of which, I should probably explain that process, since well… it is the main mechanic of the game. So, the concept is as such: the player collects “bundles” (a trio of a proton, neutron, and electron) that they can spend to construct an atom of their chosen element. There will be 15 different elements in the game, each with their own unique effect on the player and/or the environment. The player can hold three atoms at once of any combination and, for the most part, their effects stack. They will be individually discovered much like the abilities and upgrades in Metroid and Ori.
I have also sketched out two different UI concepts, one copied from Super Metroid with a black bar at the top, and the other more of a modern adaptation of it without the bar.
I’m not super happy with either and I will likely come up with another solution by the time I get to actually creating the UI.
Ok, so that’s all I’m really concerned with for now. If you managed to make it through that entire wall of text, thanks! I’ll be back soon (hopefully) with a working attack mechanic. I’ve been a little distracted by some job-hunting related stuff but that should settle down shortly. Until next time, thanks for reading!