Hello, nice to meet you! I'm Brandon and I like Birbs. Given you're reading this, you probably do too.

I'll be posting progress updates here, but feel free to leave commentary or ask questions about this stuff at any time by responding to this thread, commenting on any of the linked YouTube videos, or messaging me on Twitter (https://twitter.com/algebrandon). :)

Places where you can find me outside of itch.io:

• YouTube- Subscribe! I'll be uploading neat WIP things more often.
• Twitter - Follow! More to come here as well.
  
• GitHub - Most of my professional work isn't open source these days, but I usually manage to open a few repos a year (and I enjoy looking through repos in the followers list).

First devlog entry coming shortly.

Update 0: Groundwork and base asset building

Alright, I was in a jamming mood this weekend and found that this jam met my criteria:

• The jam had just begun -- I wanted to start working on something immediately, not wait a few days.
• Birbs!
• 2 weeks - I usually prefer planning out jam projects that wouldn't be possible to reasonably complete in a weekend. Also, having a couple of weekends in the jam schedule is important; I can't usually squeeze out a large volume of work during week nights after the day job.
• Did I mention Birbs? How does one NOT participate in a jam about Birbs?

The themes sparked interest in a few different genres for me. I immediately thought about building out a sort of side-scrolling platformer with Flappy Bird altitude controls. The mechanics would go something like: You need to fly up into the trees and chirp in order to find a mate, periodically returning to the deciduous forest floor in order to find food and manage stamina.

However, I wasn't really jiving with the idea of building a stressful mechanics-heavy game for this. The idea of gliding through a forest and casually swaying around in a more relaxing setting started to take over, and after fleshing out a few more genre maps I finally ended up choosing this one:

It's a game where you hatch and leave your nest in the morning, glide through a guided forest obstacle course with Star Fox 64-like rail shooter controls, and arrive at a new nest just as night falls, welcomed by the occupants of the new nest. The night completes and the game repeats.

From here, I started to gather reference material for the aesthetic. I haven't really done much of that hipster flatshading/small color pallet/cell shading style. It's kind of polarizing, kind of like it's the 3D version of pixel art. But I think it has a strong association with casual/relaxing games, and so it seems like a clear fit.

Below is a screenshot of some of the reference material that I quickly gathered to help inspire asset ideas (mostly sourced from Google images and Pinterest) for the look/feel. There's a few low-poly Birbs in different poses and wing anatomy references too, of course!

For the music, I liked the idea of having the melody sound kind of like a bird chirping. I got a bit sucked in and lightly mixed down about a minute worth of music.

There's ~30 more bars of very unfinished music off screen, but I might end up just cutting it and using this short loop in the interest of time. It feels like this loop could stand on its own with a little more polish and variation.

From here, I moved on to modeling the Birbs -- essential! Below is a clip of the initial modeled, rigged, and animated untextured Birb protagonist. Keeping the wings very low poly was a little bit tricky. After some mesh surgery and a couple of failed attempts at compressing the wing with 2-3 bones, I ended up with 4 carefully weighted bones branching out from the inner wing to make the wing look OK when both resting and flying.

More (hopefully) soon!

Update 1: Meet "Polly"

Seems like an appropriate name, am I right?

Today was a relatively low productivity day, but I did manage to squeeze in the remaining essential animations for our smol protagonist. Here's a sped up recording of the progress on Polly:

See you soon!

Update 2: Engine choice, importing assets, and terrain

Warning: Much rambling ahead.

Up until today I hadn't actually decided on what engine to use. I'm usually tempted to reach for Unity when attempting game jams for its no-hassle HTML5 packaging and everyone's favorite: Good ol' prefab/live object refs. You know, when you drag and drop things from the scene into inspector properties? It makes prototyping things so genuinely gross (the good kind of gross, I mean).
However, it's been a while since I've attempted a jam in UE4, and there's a lot that's been happening in the UE4 ecosystem that's been getting me a bit fired up. For one, I've always loathed the poor tooling experience around writing C++ for UE4 projects, but JetBrains has been working on a domain-specific IDE for UE4 (Rider for Unreal Engine). I tried it out a few months back, and I was pleasantly surprised at it's speed and accuracy.
To be clear, I have no hangups what-so-ever with UE4's abstractions/tools/frameworks/internals or even C++ itself -- my problem is that VS2019 + Resharper C++ intellisense in a UE4 codebases is:

• dog slow due to UE4 being a huge codebase with 100s of thousands of symbols to index, and
• poor quality due to UE4's heavy reliance on code generation (UnrealHeaderTool) and preprocessing (deeply nested C++ macros).

And codebase-wide intellisense is kind of important for productivity in UE4; I find that remembering common macros isn't much of a problem, but I do often forget where certain headers are located, and without good completion, I tend to spend a lot of time grepping the codebase or surfing docs to re-find headers.

So with a new IDE in hand, my body is ready.

I fired up UE4, exported Polly, and worked through all manner of issue with the imports. First I had multiple root bones, then I didn't have smoothing groups exported correctly, then my axis conversions for UE4 were wrong, then the animations were scaled down 100x due to a unit conversion problem, and then... the worst issue happened.

Time for a little side tangent about Blender...

In Blender, I usually just define actions for animation export. However, the "start" and "end" frames aren't actually stored with actions. And so when exporting actions, Blender automatically renders all frames between the earlest keyframe to the latest keyframe in the action. This behavior works great for non-looping animations, but scales poorly when building lots of loops (which is mostly what I do). So I finally decided to figure out how to do things "right", and defined an NLA action strip for each animation with customized start/end frames, and used the "NLA Strips" option under "Bake Animation" during FBX export. This bakes the contents of each non-muted NLA strip as a separate animation in the FBX.
Out of all the quirky UIs in blender, I've always felt that the NLA editor is among the most quirky. I typically only use Blender to author short animations and loops, and so up until now, my attempts at using the NLA editor have usually ended with me throwing my hands into the air and reverting to a less scalable authoring patterns.
At first, adding these NLA Action Strips seemed to be going smoothy (this can be seen in the timelapse I posted yesterday). It was simple enough to get the animations set up initially... or so I thought.
Once I actually got to the point where I could view animations in UE4 today, my loops were all cutting off at seemingly random spots! After a whole lot of trial and error, I realized that I was accidentally adjusting "Strip Extents" for some of the strips instead of the "Action Extents". After fixing them, it took me a while to realize that when you make changes to "Action Extents", said changes also append to the "Strip Extents". And so after correcting the "Action Extents", Blender automatically adjusted the "Strip Extents" to reflect the difference, and so correcting the "Action Extents" just propagated problems rather than solving them.

So in all, I thought that getting Polly imported would take 10 minutes, but it turned out to suck up hours. Oh well! Future models won't be this hard.

After getting the FBX import tuned right, I moved on to building the start of the terrain material.

See you next update!

Oh, and here's another timelapse of the day's work :)

Update 3: Git LFS setup, animation state machine, and water

Here's a short list of the stuff that got done today:

• Git LFS setup -- not a pain at all these days.
• Built an anim graph; Polly now has smooth state transitions between idling, liftoff, and gliding/flapping, and the transitions look great with minimal effort -- success!
• I decided to make the Bird inherit from Pawn rather than using the Character or CharacterMovementComponent gameplay framework classes, since these things are better for land creatures and human characters.
• I made a C++ Pawn for Polly and a blueprint that inherits from it to override defaults.
• Built a water material with reflection/refraction/edge foam. Here's what the material graph looks like:
  

I did run into one big issue that sucked up a couple of hours today:

After finishing up with the initial anim graph, I went ahead and bound it to the skeletal mesh in the new Bird Pawn, and was greeted with a slew of new compilation errors in the anim graph. At that moment, I immediately slumped down in my chair, realizing that I hadn't yet slain all the import dragons. It turns out that Polly's  imported skeleton asset just suddenly disappeared from existence along with most of the animations. I was able to get the skeleton to re-import and map the one remaining animation to it easily, but couldn't get the re-import to pull in the remaining missing animations. I had to resort to running the importer in a fresh directory and configuring it to only import the animations there. After getting them imported again, the editor crashed while I was trying to relocate the assets, which put the new assets into a broken state where they were no longer visible in the editor, but still existed on disk. I eventually cleared out all the new and old assets, re-imported one final time, and all was well.

Another issue I noticed was that, despite my careful and deliberate attention to getting the axis conversions right during both the Blender export to FBX and the import to UE4, Polly was actually facing in the Y direction, not the +X direction... (UE4's forward direction). After some trial end error, I noticed that an option akin to "Force +X as forward direction" was unchecked on the importer dialog. Flipping that on got it working as I'd hoped.

I feel like it's starting to look kinda neat with that water in place! There's still a lot I'd like to try with the terrain shading, but I should probably focus on building some rocks and trees to use as obstacles soon.

See you next time!

Update 4: Playing around with cinematic tools

Today I was incredibly tired after work, so I decided to just do a little of what UE4 does best and cobbled together a simple cinematic to render out:

See you next update.

Update 5: Title display and spline track

Today I decided to incorporate the cinematic I did yesterday as a sort of intro/title screen. I spent a little too much time making a text shader that makes the text wiggle a bit and look like it ha caustics overlaying it. Here's what it looks like right after the bird flies by before fading out:

The contrast isn't really high enough yet and the typeface needs work (just default roboto right now).

Aside from that, I started working on the flight track system, and I definitely that authoring the track with a USplineComponent directly was the right choice. It turned out to already have all the built in editor data visualizers I was planning on throw together myself. In particular, I was pleasantly surprised by the inclusion of a "thickness" radial area visualizer around the spline based on the spline point scale and a constant multiplier.

The plan from the beginning was to to scale the movement speed, restrict the movement area, and adjust the camera's FOV based on some additional value per spline point, and so I was already planning to build some kind of editor-only visualization that does exactly the same sort of thing. Using the spline point scale values as a track size multiplier immediately allots extra conveniences too: For example, I can just use the scaling gizmo to make in-editor adjustments to the track size rather than having to tweak properties -- I couldn't ask for a better level authoring setup!
Real talk: The only serious improvement opportunity for spline authoring I can think of in UE4's editor is having it read my mind so that I can will the spline points into place. Get on it, Epic Games,  chop chop!

Here's what the spline looks like for a quick test track I authored:

See you next update!

Update 6: Flight track

The camera still needs work, and this test track has a lot of nutty turns. I'd say the movement is getting close enough for now. I plan to move on to obstacles/knockback over the next day since I'm running out of time after a relatively unproductive couple of days.

Here's a preview of the track riding and movement along with a little showing off of the authoring flow. :)

Update 7: Oh noes!

Hey! I didn't finish on time. I unfortunately ran into some packaging issues with UE 4.25 today, and I spent most of the hour before jam close trying to package the game and deal with import problems and toolchain differences. Between you and me, it's actually been years since I've last packaged UE4 for distribution!

I had a moment where I contemplated publishing a placeholder entry and upload the binaries after submitting the game, but that didn't feel like the right thing to do. In general, the game is also still in a very unfinished state, much less finished than I'd hoped -- the only difference between last update and now is that I built a simple adaptive soundscape (authored using FMOD) into the demo level.

I like how this project is turning out way more than I anticipated, so I plan to continue working on it a bit alongside my other projects during my spare time. If anyone still wants to somehow link to this game or reference it from the planned site that's mentioned in the submission form, I'm cool with whatever. After all, it's all about the journey, and you were right here with me all the way! :)

In summery, I had a big productivity hit during most of this week, but today was especially messy for a few reasons (most of which is really my fault, not the software I'm using):

1. Packaging problems -- I should have been testing production builds all along, rather than leaving it as an unknown until the last hour.
2. The biggest blunder was definitely setting up FMOD on the last day -- I should've done it on day one. I know better than this. I wanted to bang out a quick soundscape, but it turned out that the FMOD team hadn't updated the UE4 plugin to support UE 4.25, which totally makes sense since it's been out for only ~1 month and we're living in strange times. I decided that adaptive audio was important enough to bite my lip and spend a couple of hours patching the FMOD plugin and properly configure the sound bank imports. There was some big *sigh* energy today as I pummeled through missing headers and random segfault after random segfault. I love FMOD, so I'm still stoked that I have it working fine now.
3. miro.com had downtime today, and that's where all my project notes are stored! I tried to remember and rewrite the plan I had for today in another document, which took a bit of time.

Retrospective

Here's the rolling retro I've been keeping throughout this jam:

What went right?

• Some of my best learning happens during game jams:
  • I Managed to learn a lot of important things about UE4:
    • You can easily expose public fields for scene authoring in the editor by using EditAnywhere. I can't believe this fact eluded me for more than 3 years of off and on UE4 use! (Well, more off than on I guess)
    • UE4's cinematic tools surprised me in terms of how pleasant they are to use! For example, the Cine Camera seems to have pretty accurate and predictable real-world camera emulation parameters like f-stop (to adjust aperture size on a hyperbolic curve) and the distance of the focus plane. No need to manually adjust FOV or blur/distance curves to get realistic looking camera behavior. For example, when I turned down the f-stop and pulled the focus plane close, I was pleasantly surprised to see an accurate-looking bokeh effect, where splotches of color formed that appeared to take the shape of an actual aperture stop for angles with higher light volume, rather than all color just being evenly blurred together. You can even adjust the shape by changing the number of blades on the aperture stop mechanism using the "Diaphragm Blade Count" parameter. I'm obsessed with this virtual camera.
    • Authoring the track using a USplineComponent offered many conveniences that saved time.
• Blender is always a win. Thanks to muscle memory built over the years, I can usually model, map UVs, texture, and rig what I need pretty quickly. I am a bit slower with animating than I'd like to be, though!
• UE4's C++ hot reloading went above and beyond the call of duty. Last time I used UE4, I pretty much had to restart the editor every time I made any constructor changes. It looks like they somehow managed to fix most of the state desync problems and crashes.

What went wrong?

• Blender's workflow of converting Actions to NLA Action tracks is funky and finicky. I made a lot of mistakes here and had to backtrack and waste time. It'll serve me in the future to look into the UI's behavior more deeply and develop a consistent workflow around it.
• Importing Blender-authored 3D assets into UE4 was difficult to get right, and I ran into several compounding UE4 bugs that caught me off guard and caused some lost work. For example, I was trying to work around a bug where not all of the animations were getting imported from the FBX, but UE4's editor crashed a couple of times when I tried to move a fresh import of the animation assets to another directory, which seemed to leave some of the assets in a corrupt state on disk and no longer visible in-editor. I have some ideas about what happened here that I won't get into, but I eventually just cleared everything out and re-imported things.
• UE4's toolchain out of the box doesn't have some modern C++ features enabled that I like, such as designated initializers for structs.
• I ended up only getting to audio on the last day, and I had to patch problems in the FMOD UE 4.24 plugin in order to get it building against 4.25.
• Packaging for production during the last hour did not go smoothly. :o

Takeaways

• Working with UE4 blew my expectations out of the water this time around, and I absolutely will be reaching for it again in the near future. Over the past couple of years, I've been working off and on reducing my friction with UE4. In addition to optimizing my hardware for much faster build iteration, I can say that I wholly endorse Rider for Unreal Engine -- it's hands down the best IDE experience I've had with UE4 by a long shot. With other IDEs, I've sometimes had to resort to shutting off intellisense due to the extreme performance issues and my low tolerance for IDE lag. Not so with Rider, it's fast and accurate. In all, there has never been a better time to try starting a UE4 project than today. I'm so glad I decided to work with it.
• Participating in this jam was a perfect opportunity to use new tools and improve my existing workflows with more tools. For example, I had some good organizational gains with Blender in terms of animation authoring. I've learned more during this jam than I have during any other for sure!
• Keeping a dev log is always a fun thing for me. I hope you enjoyed it too, thanks for checking it out!
• I like birbs -- if there's another birbjam in the future and you remember me, reach out and let me know, I might miss it!

Feel free to reach out if you have any thoughts, questions, comments. Oh and see you soon in another jam. :)

Places you can find me: YouTube, Twitter (@algebrandon), GitHub (bdero)

Brandon