Thank you to everyone who gave Bbreaker a shot during the voting period! We learned a hell of a lot from the feedback that was provided; and given that it's pacosmartini's first game and submission, as well as my first game jam submission worth being rated for, we wanted to share what went into developing our LD submission and why we'd like to keep improving on it.
If you'd like to give it a try, you can find the itch.io page here.
Dev Process
Brainstorming (1 Hour)
Once the theme had been announced, we used a brainstorming prototype tool I developed a while back to help get the ball rolling (shameless plug).
We used the tool (Conception) by combining the LD39 theme "Running Out Of Power" with other random topics like "Airborne" or "Time Travel", allowing us to play with the main theme in unusual and interesting ways. After choosing 10 random topics, everyone on the team gave their unfiltered ideas for each combo. Once everyone had their say and a list of ideas were conceptualized, we each distributed votes to our personal favorites and finally narrowing them down to a single idea.
Admittedly, the coin flip ended in favor to the Ghostbusters-like idea, but we both felt that the engine-breaking mechanic had more potential for fantastic game feel, as well as earning the category results we wanted most. So we went with the latter instead!
The Conception process is usually used for every game jam I participate in, for a few reasons:
- * _Moving away from the norm._ * When working with a game jam theme, the ideas that us game devs come up with are usually one-track. In other words, since the theme was "Running Out Of Power", chances are pretty high that it'll have something to do with electricity or batteries. Going with these initial perceptions of "running out of power" makes it incredibly likely that we'll make something that someone else is making, and the last thing we want to do is to do what everyone else might be doing.
- * _Save time whenever possible._ * Similarly, it's really easy to get stuck in that one-track mindset without additional sources of inspiration. Doing some research into what "power" can be and what constitutes running away from power helps with that aspect of brainstorming, but sometimes you want to expedite that process if the theme isn't enough to go on. In game jams, though, having extra time is invaluable-- so if you can make the brainstorming stage go faster and with less hassle, do so.
- * _Everyone on the team is invested in the pitch._ * This can be the most difficult aspect of brainstorming, and anyone who's worked on a team can probably vouch for this. One person can love an idea, while someone else hates it. But by brainstorming in a way that combines the theme with other potential topics, anyone can give unfiltered input without the team investing in any one idea heavily. Once everyone gives their personal votes and a final decision is made, the team is much more likely to have some emotional investment in the project. (I've found that 10 rounds of random theme+topic combos is a solid number for generating a list of ideas to work with. In addition, if there's more ideas to choose from, people tend to give less emotional restraint when providing constructive criticism, which is much preferred.)
On a final note: when first working with game ideas, it's incredibly tempting to go with an idea that sprouts from a narrative or atmosphere. When starting out in game dev, a lot of my ideas were like that, and I've continued to see my peers do the same. This can be a dangerous habit to have! Here's an example.
ex. a game where a boy discovers light
By prioritizing world-building before game mechanics, you're building the game around a narrative rather than gameplay. While this works great in other creative media like comics, film and novels, it can be detrimental in game development. Mentioning the idea above, how do we know what the gameplay is like? What does the player do? What's the end goal? At least one of those questions should be answered, and its also great practice for creating pitches if you want to find a publisher in the future (whether its this project or any other).
If you're pitching an idea, try framing it this way:
- A game where you collect light by jumping in the air to catch small bits of light
- A game where, upon discovering and obtaining light, you run away from enemies attracted to it
- A game where you use light-based objects to solve puzzles
Always using "a game where you..." is pretty generic, but its a good starting point. When starting the brainstorming process, Pacosmartini had the same world-building habit as I did before-- luckily he's gotten better at it though!
Art (5 Hours)
Going into development, I initially wanted to try the Pico-8 aesthetic but was also torn between the classic GameBoy color palette.
With the initial sprites using the bright Pico-8 style, it felt off but I couldn't really figure out why. My initial guess was that with Pico-8 typically using a small resolution, the color palette fits very well for small sprites; but when the sprites are as zoomed out as Bbreaker is, and the size of the obstacles in comparison, the composition didn't feel right. So in hindsight, it didn't matter what palette I used-- the proportions of everything had everything feeling a little off.
Prior to working on Bbreaker, I had also used the GameBoy palette for the GameMaker's Toolkit Jam. But unlike this jam, the GMTK Jam prototype wasn't finished in time (post-Indie Megashow and road trip left me with 5 hours to build something) and it ended up being scrapped. With only getting the art assets done, I wanted to give the GameBoy palette a second chance, which ended up being LD39! (GMTK Jam art assets show below)
In the end, the final visual aesthetic for Bbreaker turned out alright! We liked the explosion a good bit; I wanted to make more, but creating 8 sprites for that one animation was a deal-breaker if we wanted to make more of them. The enemies/obstacles could use some work, but more on that later.
Audio (3 Hours)
The audio was done in the last few Monday hours of the game jam. At first I wanted to compose music of my own, but seeing how I hadn't made music in Famitracker for a loooong time, Creative Commons looked like the best way to go. I found a few good tracks and one of them fit the game really well, so that was placed in there. As for sound effects, they were generated using BFXR. The engine SFX was the most difficult to get right, but I'm definitely happy with the result!
Code (>30 Hours) and Design (∞)
The hours for this aspect is a little difficult to count-- but quality, not quantity, yeah?? Idk, but here's a rough guess for the programming part.
- Friday: 0 Hours
- Saturday: ~10 Hours
- Sunday: ~14 Hours
- Monday: ~6 Hours
Despite having a busy weekend, we were able to trade off programming responsibility a fair bit! While this was pacosmartini's first game dev project using Unity, he's a much better programmer than I am and could handle the steep learning curve after a little guidance in the Unity engine. After brainstorming, he spent Friday night going through the basic Unity tutorials to get a grasp of things.
As for Saturday, I had work in the morning and he had an event in the evening. Once I got back from work, I focused on art assets while he started on a prototype and asking me for advice occasionally. After he left for the event, I shifted focus to programming for a little refactoring and design tweaking to get the airplane feeling better to control. We weren't able to get the camera-follow to work correctly, as it had a nauseating jitter effect and we spent way too long trying to fix it, so a still camera is what we chose to design around.
Once Sunday hit, we were on a bit of a time crunch and still needed to implement a form of progression: enemies and an altimeter to track progress. Initially the enemies were meant to have AI and shoot bullets at the player, but with the deadline closing in we were sure we wouldn't be able to make any robust AI. Luckily, most of the enemy art assets were made to look like debris, so having them fall from above was the best-case scenario to go forward with.
Since we were working with a still camera, we faked the altimeter a bit. The altimeter is based on a timer for how long the player has been alive, and the enemy spawns would be more difficult to deal with over time-- spawn rates and fall speed increased as altitude increased. The difficulty curve wasn't implemented until after the submission while we were tweaking values for re-balancing, however.
On Monday, we didn't have enough time to add a Main Menu; but we were able to add a Game Over screen and Restart keybind. And then... release!
Review Period
Polish (1-2 Weeks)
After the game was released we did some bug clean-up, as well as some game feel enhancements a la screenshake and UI flashing. But based on the feedback we received over the course of the review period, we needed to make some re-balancing changes as well.
- The first build didn't increase difficulty, so that was fixed.
- Fixed UI bugs
- Fixed screen resolution and bordering bugs
- Updated UX to provide better feedback as to what was going on
- Added a victory condition. But the most difficult issue we had to deal with was...
- Gun balancing
Based on the feedback we were getting, it was possible to beat the game by staying still in one area, seldom breaking the engine and not shooting at all. We didn't want this at all >:(
To compensate, we increased the debris values to be more challenging and forcing the player to use the gun, and in turn using their engine more often. We later learned that the gun imbalance was due to the gun being an artifact of a design that was never implemented: enemy AI. If the enemies weren't focused directly on the player, enemies didn't need to be swiftly death with and the gun essentially had no purpose. So unless we had enemy AI tracking, the gun would be forever broken. We should've taken out the gun, but didn't.
Feedback Analysis
Once this build was released, we submitted the game to Youtubers and Twitch streamers to see player's reactions live. (Much thanks to Elysia and Jupiter!)
https://www.youtube.com/watch?v=LqYPjUYhuXo
Consensus: we made it too difficult. Or a better way to put it: we didn't give players a safe space to learn, nor were we clear enough as to how the game was intended to be played.
We should've anticipated this, but players tend to conserve any resources they have. With the game's primary mechanic focused around giving up control of the plane at the most opportune time, we wanted players to see engine-breaking as a great time to heal up and regain control of the situation when fixing their engine mid-air. Instead, players would avoid breaking the engine entirely before death. Or even more so, players couldn't understand what to do when the engine DID break and what benefits it provided. This resulted in frustration due to lack of feedback as to what they're doing wrong. It felt unfair.
Final Notes
Results
As happy as we are with the results, I'm personally a little bittersweet about it. Self-care is important, but being responsible for the game design, the fault in player frustration lies with me.
Being top 15-20% is fantastic, and as our first game to be given legitimate feedback, a 6.6/10 (averaging everything up manually) and a 7.2/10 (overall rating) is not bad at all! We received a better-than-average score across the board, and the pitch and art aesthetic attracted a lot of great feedback, so that's definitely something to be proud of. But there's definitely room for improvement, and we intend to do so!
Next Steps
Personally, I'd like to finish projects more often. Bbreaker is one of the few games where the intended design made it into a game jam prototype in time, so admittedly there's some personal attachment to it; even more so for Pacosmartini.
We'll be overhauling the enemy and level design, as well as improving the initial gameplay so players have a better grasp as to how to best use the engine-break mechanic. As for what platform to release on, we're pretty close to figuring out but aren't quite sure yet.
Thank you all so much for reading! It's long as hell, so it's much appreciated if you stuck through it :) Congrats to everyone who made it to the end of the game jam~!
Here's one more piece of media for you lovely people. It only took 3 days to beat our own game.
I:
https://ldjam.com/events/ludum-dare/39/bulbinos-quest
https://ldjam.com/events/ludum-dare/39/blood-in-the-stars 
LD is almost over and we wanted to make a conclusion.
(early screenshot of the post-jam version, and it's different now !! Graphics are being reworked to look better - see bellow - and there is new features and interactions already implemented - and other to come)
(% based on rating vs total compo submissions - higher is better)
(% based on rating vs calculated compo submissions - higher is better)
(% based on rating vs total ratings by category - compo submissions - higher is better)
My three-year-old and I thank you.
Here was 
Have a nice day!
https://ldjam.com/events/ludum-dare/39/punchey-vr-only
We didn't reach TOP100 with our game unfortunately https://ldjam.com/events/ludum-dare/39/unlit , but still it was a good experience.
