DEVLOG 9

In an earlier devlog, I mentioned that I wanted “BLOOD” to simultaneously act as currency, health, and possibly ability points. I also wanted peak blood to play a role as not just a leaderboard stat, but as something important to gameplay. With that in mind, I drafted the following systems: REBIRTH and REVENGE.

• REBIRTH: When your BLOOD reaches 0, or you end the run early (preserving blood and peak blood) to buy upgrades. Upgrades cost both BLOOD and PEAK BLOOD, so you can either continue using blood to keep the run going (acting as a larger health and ability pool, and having a chance to get blood / peak blood even higher), or end it earlier to spend it on upgrades.

• REVENGE: Available upon DEATH. Requires PEAK BLOOD to be greater than 100. Continue the run by setting your BLOOD to PEAK BLOOD. BLOOD and PEAK BLOOD will drain to 100 in 30 seconds, but the duration is extended or lowered from BLOOD gain and loss. In exchange, the player has enhanced stats for the duration of REVENGE. 

~

In this sense, the player is forced to gamble their resources at all times, at stake to skill but unbeknownst of future obstacles. I believe this will make for a very engaging gameplay loop, but playtesting needs to be done to ensure it’s not frustrating or too punishing. However, I don’t know of any loops similar to this. If it’s the first, I am very excited for it.

~

For Devlog 9, I added buttons that appear on death for REBIRTH and REVENGE, where the former will reset the map and revenge will keep the game going. I also implemented tooltips with these buttons for more in-depth explanation when necessary. However, I recognize that this can eventually make the game text-heavy, so an in-game tutorial will be in the works.

~

And of course, these buttons will have custom assets! As a reminder, although some code is AI-generated, ALL OF THE ARTWORK, SPRITES, 3D MODELS, AND MUSIC ARE AND WILL BE COMPLETELY HUMANMADE.

~

Stick around for future updates :)

DEVLOG 8
There is DANGER…

• The enemies are actually real instead of menacing vocaloid pears!!
• The first type I introduced is a zombie, which can…
  — Run toward the player
  — Jump over obstacles (with a varying height according to how high the obstacle actually is)
  — Kill.
• I’m actually pretty proud of the jumping solution (though maybe a professional wouldn’t like it…)
  — First, the zombie casts a raycast in front of itself, from its feet. The length of this raycast depends on how fast it’s going, so that higher speeds don’t make the zombie bump into the obstacle before actually getting over it.
  — Then, the zombie casts a raycast from the sky and descends until it hits the top of the obstacle. From the feet to the top, this gives obstacle height from which necessary jump strength can be calculated from a kinematics formula. (Yay AP Physics or something)
• There’s going to be more enemy variations in the future, but it takes a while… here are some plausible ideas though:
  — An enemy that physically blocks the player
  — An enemy that shoots projectiles
  — An enemy that explodes on death and therefore must be avoided instead of killed
• Aside from enemy variations, I’m going to keep working on things like a lose/restart screen and an upgrade menu. Stay tuned?

DEVLOG 7

• I’m getting excited for how this is gonna turn out. With an actual prototype on hand, I can handle the fun side of the gameplay loop, the others being a respawn and upgrade system.
• I added procedural generation in order to create the map, which assigns the player a random seed from which a map is created. This makes for a unique but consistent map, and will hopefully reinforce the idea of the player learning from their mistakes because every run will be a chance to correct them.
• So far, in this map generation, there is a house, trash can, and tree, managed with the ScriptableObjects feature in Unity (which lets me store data for each prop more efficiently). These objects are assigned weights to affect the probability of each appearing on an object spawn. Although I knew probability weights existed, learning it conceptually and applying it was a little weird because I didn’t learn this in my statistics class.
• The house is tall and solid, but I added a grab feature to jump when approaching high ledges. This should make vertically scaling sections of the map more realistic in the future.
• The trash cans are also solid but can be knocked over.
• The tree can be walked through because it’s a background prop, but there will probably be variations that act as obstacles.
• Next on the list is adding enemy AIs, so the player can lose health to a secondary lose condition and that attacking is just as important as running.

DEVLOG 6
Since this is supposed to be a side scroller, the lose condition is a horde of enemies that comes in from the left side and drains the player’s health. I did a lot of experimenting and reading documentation with Unity’s Mathf class, using it for things like exponential health drain (Pow, FloorToInt, Clamp). In the video is a placeholder sprite… but you can totally see the terror of the monsters… right?

DEVLOG 5
I added a mechanic that acts as both health and currency: blood. The idea is that killing enemies gives blood, getting hit loses blood, and saving blood can be used for upgrades. Balancing it this way will require a lot of thinking about game theory, but hopefully it’ll make gameplay more risk-intense while still being engaging and rewarding. I designed this UI block based on old Flash games and I’m going to try to lean toward that aesthetic.

DEVLOG 4
Another main mechanic: attacking, and enemies that can die. After a few more critical mechanics are added, such as player health and enemy behaviors, I’ll finally be able to make this more unique.

DEVLOG 3
REAL SPRITES!! Kind of… I drew out a bunch of prototype sprites on Clip Studio Paint and used an online website to generate a sprite sheet. Afterward, I sliced that sprite sheet into individual frames that could be selected in groups for each animation. Then, I had to use an Animation Controller to control when each animations played under certain conditions. I think I’ve said it in another devlog, but it’s way harder than it looks for the first time around. I have years of experience in Scratch but this is the complexity that comes with professional tools (Unity). Also, if you’re curious, I attached reference art for the character; lore coming soon? (It might relate to future gameplay mechanics…)

DEVLOG 2
I added jumping, but it took way longer than I thought. The plan was to make this high-action, so a simple up and down jump, like in many traditional platformers, would’ve been “restrictive” by putting the player a predefined amount of time in the air. Instead, I implemented variable jumping, where if you release the jump button early, you fall earlier. I drew inspiration from Hollow Knight (a metroidvania), but this was popularized by Super Mario Bros.

Next on my priority list would either be coyote time (giving the player a small window to jump when off the platform) or working on attack hitboxes for the main gameplay loop.

I’ll add actual sprites soon!! I have some concept art, they just need to be animation-ready and blend into the game.

DEVLOG 1

My first proof-of-concept for this game: horizontal movement. It doesn’t look like much for an hour of work, but it turns out Unity can be very hard to learn…

But anyways, it exists and that means it can continue to improve.

I’ll also explain why the game is called ‘unwanted traffic’ in a future devlog. The player character does have a backstory.

The opinions of our customers are very important. Especially if it includes raw, unfiltered rage. You are now able to give feedback through the Github Issues page.

made an openable and closable app icon

1-Hour prototype– The window on the right is draggable and closable.