The Philadelphia Inquirer, Pennsylvania, September 24, 1899
TVSTRANGERTHINGS
todays bird
h

No title available
YOU ARE THE REASON

shark vs the universe

ellievsbear
Mike Driver
No title available

JBB: An Artblog!
Monterey Bay Aquarium

izzy's playlists!

PR's Tumblrdome

Kaledo Art
🪼
almost home
Sade Olutola
i don't do bad sauce passes
taylor price
Aqua Utopia|海の底で記憶を紡ぐ
seen from Germany

seen from Germany
seen from United States

seen from United States
seen from Germany
seen from Germany
seen from South Africa

seen from Türkiye
seen from Mexico
seen from United States
seen from United States
seen from Israel

seen from Italy
seen from Germany

seen from Germany

seen from United States
seen from T1

seen from Türkiye
seen from United States

seen from Hungary
@pianodropgames
The Philadelphia Inquirer, Pennsylvania, September 24, 1899
Level mock-up made with foam core, hot glue, and a lot of Xacto blades
photos by @graciebellemagic I'm not great at spatial thinking, so creating spaces from scratch in the boundless sandbox of a game engine has been tough. To try and get better, I've taken inspiration from Adam Savage's youtube channel I think it has been worth while. My paper prototype, by nature, is more grounded and real feeling than my direct to engine attempts. The simple gimmick of circling a mountain has created something I'm much more excited about playing than previous linear paths It has also been a welcome diversion from seemingly endless hours in front of a screen. The tangible nature of the work is helping my brain think more spatially too. Perhaps the most fun part of this project is that as I got further up the mountain, a change took place. At first, it was a pure exercise in blocking out a playable space in a physical medium. But as it went on, the project took on aspects of model making. In particular I had endless fun adding all the haphazard struts, tubes, and little bits of detail called “greeblies”. I was filled with a sense of the type of people who built the path, and what life was like for them. It was the first time I ever touched the storytelling aspect of level design.
The beautiful photography makes the mountain feel like an ethereal playground, and will serve as an invaluable reference when attempting to realize the level digitally.
I’m already anticipating that some things will have to change. After all, level design is iterative, and foam core and hot glue don’t want to be iterated on. Unlike digital media, which invite constant adjustment.
A slow-mo video demonstrating how I let the player choose (kinda) which rail to snap to. In my first iteration, the character always snapped to the nearest rail. But it didn't feel right. I wanted to snap to where I felt I was indicating with my controller
The blue line represents the vector indicated by the player input, and the green line is drawn from that point to the nearest snappable point With that simple change, it's second nature to subconsciously pick a rail mid air with the joystick
A jumpy flappy zoomy odyssey about a mouse who wants to be a bat
Latest build!
A demonstration of the time-honored "coyote time" in Fleder
Coyote time is a technique to make gaps more forgiving by allowing the player to jump a few frames after they've technically gone over an edge and begun falling
Without coyote time, platformers feel unfair
I was feeling very proud of my ground clamping, but was nagged by the odd feel it created when skating. When just walking, the character controller should hug the ground tightly. But when skating, it felt like it should be more prone to hopping, like in Jet Set Radio
I created a surface type called "stompbox" which causes the character controller to stop re-orienting its movement velocity while skating. But on other surface types, the movement re-orientation is preserved so it doesn't awkwardly bunny-hop down long slopes.
This process really got me asking about my programming habits, and where my threshold is for giving up on a procedural solution to a problem and just authoring data. I spent a long time trying to make the character controller smart enough to just infer when it should hop
In the end, the decision to just create a special surface type for the behavior I wanted is something I'm at peace with. Making a character controller that can switch at any time between JSR skate feel and Crash Bandicoot walking feel means that there will have to be compromises
(The jitter in the second half of the gif came from instagiffer and I don’t know why)
I added this trail renderer to test some motion smoothing and ended up playing with it for like an hour
Here’s a video demonstrating the terrain hugging
To help illustrate how it work, I’m using two debug lines; the red debug line represents how the character controller reads the angle of the terrain, and the blue line is the character's reoriented velocity
Months. Months it’s taken me. But I finally have it. Rails pointing in arbitrary directions. I’m so relieved I’m don’t even care that I forgot to fullscreen for the video. My solution is too ugly to speak of but it’s good enough for prototyping
Inspirations
Another Fleder video. Uploading this because it nicely shows off some of the newer sounds and mechanics as well as the dynamic music.
Playing around with fonts and colors today, trying to capture the game's character
A complete playthrough of a recent prototype level
I’ve been experimenting with some new effects, such as sparks when skating, gibs when objects shatter, and a little puff of dust when Fleder lands.
I have also taken the deep deep plunge into spaghetti land to turn the complete clusterflap at the heart of the controller into a finite state machine. After a day or two of cleaning up edge cases, it controls so much better and even runs at a higher framerate. And speaking of framrate, nobody told me how expensive Updates() can be. You know those lovely up-and-down-bobbing little beacon parts there are hundreds of in every level? Each was using their own update. I refactored it so that they all have their position set by a single Update on a manager object, but I want to make that more extensible so I can get down to even fewer. One of the things I’d like to try is getting the character controller down to a single update. At the moment, it uses a total of six. It will probably mean changing some dependencies because right now the execution order of the scripts on the character controller is interwoven with other scripts in order to make sure everything moves in sync.
For #screenshotsaturday, a before and after of when I took the complete clusterflap at the heart of my character controller and refactored it into a finite state machine cue handling and deserving at such and such etc.
I spent the last two days really trying to optimize the movement code. Ordinarily I think optimizing a prototype would be ill-advised but in this case, the effort has been worth it for the more immediate feel to the movement.
After finally going through the drudgery of detangling the spaghetti (well, most of it anyways) and implementing a finite state machine, everything is cleaner, it works better, and in many places it’s simpler to change and easier to understand.
And as a side-benefit, the frame rate is higher too. I’m finally at the point where most of the frame time is spent waiting for the target FPS, where before I was lucky to hit 30 fps in the build with all other programs shut down, I’m now hitting 60 in the editor while I binge watch Nailed It on netflix.
After a sleepless night of clumsy vector math, I can make Fleder snap to rails with a button press, almost a Tony Hawk kind of feel.