Defusing Flutter Bombs

Defusing Flutter Bombs

Origins of Flutter Bombs

Flutter Bombs was originally a landscape study using Unreal Development Kit (UDK).  I had just finished a VR game jam using UDK in 2013, and wanted to better familiarize myself with the engine.  Having a background in architecture, and an interest in figuring out how to use game engines in the architecture design process, I studied UDK in the interest of developing a better sense of engine capability, and where the two fields may have some overlap. 

How the landscape study evolved

The first part of the landscape study was mostly about learning how layer blends worked with landscape materials and terrain sculpting.  There was an opportunity to dive into Speed Tree to better understand the import/export process for custom foliage. The study of water surfaces in real-time CG also became of interest.  Last but not least, I also developed a cave formation to catch up with the latest UVW unwrapping tools at the time, and also understand how graphics engines handled transitions between interior and exterior environments.

Bringing the environment to life

To add more life to the environment, I tested different shader effects for water surfaces, dove into UDK’s particle editor Cascade for waterfalls and fire pits, and started working with simple skeletal meshes to create critters for the environment, the first of which was a butterfly.

Violence is natural (but it’s still insane)

In the process of working with the butterfly asset, I looked at a few different ways to add life to this actor.  Some methods involved matinee scripting, other methods looked at pawn movement components that could work with AI controllers, and the last method looked at using physics in conjunction with player-controlled actor testing.  This last method, physics, worked really well when testing how to get this delicate butterfly actor to float around the environment in a fun and challenging way. The beginnings of a game was starting to form. 

In the process of studying the physics system integrated into UDK, I had also come across the existing api for weapons and projectiles that were designed for Unreal Tournament.   It was fairly intuitive to integrate a weapons system into the butterfly, which was a bit of a joke at first, but turned into this little game of target practice with a player controlling a butterfly shooting projectiles.  The thought had occurred to me that this concept would be really fun to play on console. So I continued to build out the demo environment, complete with nectar ammo flowers for players to collect so they could shoot nectar projectiles, and drop nectar bombs.  The project was henceforth named Flutter Bombs. 

The concept of weaponizing a butterfly was fun as a game, but I also saw an opportunity to create something that made a statement about violence.  I have been a gamer most of my life, and games are constantly being criticized about their violent content, but i think the theater of the absurd plays a big role here.  Juxtaposing protagonists inspired by nature with concepts founded in the advanced weaponry developed by mankind creates a sense of absurdity (and i think lots of games make this point really well).   Violence is natural, and part of the natural everyday world, but the tools mankind has developed as part of this ‘natural’ process, are both awe-stricken and absolutely insane. To quote Sam Cohen, the inventor of the Neutron bomb, (Neutron is also one of the characters in Flutter Bombs), “It’s not about logic, and it’s not about rationality, it’s not even about sanity.”

Transitioning from UDK to Unreal Engine 4 

Sometime in the middle of developing the demo level for Flutter Bombs, Unreal Engine 4 was announced.  I was extremely excited to hop into UE4 because it was an opportunity to see how C++ communicated with the game engine.  In UDK, I had learned the unreal engine proprietary language UnrealScript, which has a sort of java-like dot notation, so learning C++ was pretty challenging.  UE4 also had blueprints which was V2 of Kismet from UDK, but reached much deeper into the game engine than Kismet. Shortly after UE4 was released, I began porting from UDK, which basically meant rebuilding everything from the ground up, but pulling from the same content assets for the most part.

Multi-Platform

When developing Flutter Bombs, part of the study involved getting an understanding of how the various features of the game would synergize on multiple platforms.  So part of building Flutter Bombs also meant exploring multi-platform game design using many of the same mechanical elements. This process involved studying how each platform ergonomically influenced the natural way we interact with the software program based on intuition associated with software input capability.  On console, the 6 degree of freedom physics based shooter was a comfortable play style. For the VR platform, I had developed a variant of the console version, but re-designed specifically based on VR best practices. And on mobile platforms, a twin stick shooter had emerged. 

6 DoF Flying Shooter for PC/Console

The concept of Flutter Bombs was essentially derived from this variant.  Bringing a butterfly to life with physics, and then weaponizing it as an act of sensationalism in line with many of its archetypical predecessors created an interesting style of play.  Players had to master the mechanic of getting the butterfly to float in a relatively stable fashion while engaging air and ground combatants. This was challenging, but the game was designed so ground combatants would be limited in mobility, and bombs would be a ‘close enough’ shot true to their abhorrent nature.  Air combatants would engage the player with more dog-fight like routines. Nectar was low to the ground, and players were forced to practically ground themselves to re-supply their nectar ammo. Many parts of the environment were also destructible to achieve that sense of ‘Rampage’ style of play from back on NES.

A Closer Look: 6 DoF Flying Shooter in VR

When attempting to build this game in VR, game design in VR was still very much in the ‘wild west’ of development.  Developers, including myself, were trying all different kinds of tests to determine ways to create user interfaces in VR and instigate game response to new input types like positional head tracking and acceleration. 

Player movement in Flutter Bombs was originally an oscillating movement to the frequency of player input.  So for example, when the player pulled the right trigger on the gamepad, the butterfly would lift. If the player let go of the trigger, the gravity would take over and the butterfly would float toward the ground again.  When a player mastered the controls of the butterfly, the butterfly would practically glide most places with very little oscillation.  Outside of VR, this was a fun concept like many physics puzzle games. However, in VR, this control mastery was difficult to achieve, and new players would have been punished by the effects of mentally jarring VR.  Players that eventually mastered the flight controls did have noticeably better aim and target practice success in the VR version of the game. It was for that reason we ended up building an ‘on rails’ version of the game that progressed slowly through different path environments for our continued demonstrations at various festivals. 

Twin-Stick Shooter on Mobile

The concept for the twin stick shooter was primarily the result of a rough hypothesis along the lines of ‘what happens to a shmup when another plane of combat occurs in world space rather than parallax space ’.  Most of the shmups I had played in the old arcade days always had an insta-hit with projectiles at perceived multiple z-spaces, and this made sense for bullet-hells. However, I hadn’t really seen too many examples where time was accounted for when traveling from player flying z-height down to ground z-height.  So, I built a little concept that used the same protagonists as the console and VR development to create a 3D shmup with two planes of combat interacting. Players would fly their wing-set at sky height fighting off airborne enemies, while wingsets could also drop bombs on spiders below.

Festivals, Meetups & Feedback

“Gamescape” is a part of a festival in Baltimore, MD (United States) called Artscape.  Artscape is an enormous festival filled with exhibits, vendors, performers and a massive crowd gathered to celebrate art.  Gamescape is the portion of this festival that focuses on the art of game development. We had the opportunity to present Flutter Bombs at Gamescape a couple times and had a great time when doing so.  We were able to get hands-on feedback for each build type. Going to festivals like this were really helpful in shaping gameplay primarily through observation and studying how everyone interacted with the control scheme or environment design.  Or even studying natural tendencies during the flight control learning process.

SAAM Arcade

The Smithsonian American Art Museum (SAAM) Arcade event is a yearly event that fills their building atrium with thousands of museum goers, independent game developers, and retro arcade games courtesy of MAGFest.  We had the opportunity to present our multi-platform study at one of these events. At this event, people had a chance to play the 6 DoF version of the game with a gamepad while waiting in line to play the game variant in VR.  Observational studies were conducted here as well with regards to how players first hopped into VR, or where they first were inclined to start flying based on the environment cues in the level design. The concept of prepping someone on one platform before entering another, potentially more complex, platform worked well.  Players had the opportunity to familiarize themselves with the basic concept and controls of the game before diving into VR where they could experience the cross-comparison of how different gaming is in VR. 

At a subsequent event which was more of an interactive art exhibit also located at the SAAM, we had the opportunity to present our VR on-rails experience where viewers would casually fly behind the butterfly through a visually stimulating path to the score of classical music while hunting for nectar.

Meetups (Coders & Keggers, BMoreVR, UE4 User Group)

Another type of gathering that was extremely helpful in the shaping and study of Flutter Bombs were meetups courtesy of Meetup.com.  We participated in several different groups including CDK:Coder/Designer Kegger, BMoreVR, and Unreal Engine 4 Meetups. 

For CDK, we were able to present our on-rails VR experience before and after a panel discussion where we discussed multi-platform development, and what it was like developing for VR at the time.  An intellectual property law firm offered their lobby/event room to provide as a venue for the event, so we were also briefed on some nice perspectives regarding IP law.

BMoreVR is named for Baltimore, MD’s virtual reality scene.  We would meet every couple of months to set up and present our various creations in VR and AR accompanied with food and drinks.  Because these meetups were also somewhat heavier in the developer attendance side (or at least they were at the time), I tended to present more experimental variants of the Flutter Bombs VR study that tested new camera movements, optimization methods to keep things running at 90fps, and several design considerations regarding an archetypical flying shooter type game.  

The last type of meetup we participated in was the Unreal Engine 4 Meetup group for the Baltimore/DC area.  We volunteered to host these every few months, and would hunt for restaurants or event spaces to meet somewhere halfway between Baltimore and D.C.  Each meetup we had a presenter showing their project and talking about their experience developing with Unreal Engine, after which everyone would chat about their various projects.  These meetups were helpful to learn more about engine-specific technicalities and common issues or challenges in developing with engines in addition to seeing some great process work for local game developers. 

Disruptive VR : A Brief Hiatus in Flutter Bombs development

While developing the three variants of Flutter Bombs, (mobile, console, VR), the technology for VR development was really taking off.  Flutter Bombs essentially started in UDK and around the time when the Oculus DK1 was sent to kickstarter backers. The VR version of this project went through several versions of this hardware including the Oculus DK2, and eventually the Oculus Rift as well.  It was when technology started transitioning to HTC Vive & Oculus Touch when I was disrupted by Motion Controllers in VR. This technology changed the potential for game design in so many ways, I put Flutter Bombs on the back burner for a little bit to explore designing/building a crafting and exploration game in VR to better understand room-scale movement in virtual environments.

The focus of this dev blog is about Flutter Bombs so I won’t go into the room-scale VR development, but for the purposes of this briefing, when returning to work on Flutter Bombs, it’s good to note that technology continued to advance quite a bit outside of VR as well, with phone processing power improvements, game engine efficiencies/quality-of-life, and gaming ecosystems that were becoming more and more accessible cross-platform.  

A Fresh Perspective

Hopping back into the development of Flutter Bombs provided some interesting challenges.  I had learned a lot about game design through both research, and trial & error. I also had a couple different code base variants for different platforms from the earlier studies. I wanted to get a more formalized version of this nature themed aerial combat game out onto the market.  

My first instinct was to focus on the VR build.  In my VR research I was able to get a general sense of the market.  After building a version that was on-rails to accommodate user comfort, the flow of the game changed dramatically.  Things needed to be slower to give users the opportunity to observe everything around them and interact as needed. Slowing the game also improved comfort in VR, but Flutter Bombs didn’t really seem like the right fit for that type of game any more.  All combat would have needed to be removed, and the game would have solely become one of puzzles, or environment instigation to solve puzzles, while carefully navigating this physics-based butterfly around the scene. I enjoy this concept, and enjoy playing games like this as well, but I wanted to maintain the ‘theater of the absurd’ statement this game was making.  So, combat had to stay.

The console version of the game had actually come a long way before the hiatus into VR.  I had built the game with 15 levels total. There were five themes, and each theme (which was also a chapter of the story) were composed of three sublevels: a seek & destroy level type, a racing level type, and a boss mode level type.  I had also built in some split screen and online multiplayer combat with five multiplayer maps based on the level theme. Multiplayer essentially followed the gaming archetype of helicopter combat. Helicopter combat tends to end up with players spiraling upward and downward creating pretty amazing patterns of particles in the sky, but gameplay wise didn’t seem very appealing for longer periods of time.  This made me reconsider removing multiplayer as an option for this version of the game. When reviewing the campaign mode, and continuing to build out the levels for 6 DoF gameplay, it started to sink in with me that the joy of the physics based flight was the core of the game, and combat was funny, but not necessary with this control scheme either. This led me back to reviewing the twin stick game I had built, and felt that it was the most appropriate format or game type to present the concept of Flutter Bombs.

Moving Forward with Twin-Stick

Shoot-em-ups (shmups) are a fantastic genre of game to study.  Minor variations in gameplay balance make a huge difference, they push hardware to the limits, they offer exciting fast paced action, and in many ways, the ancestry of the ‘shmup’ shaped the foundations of what gaming is today.  For anyone that is interested, Dr. Luke McMillan wrote a fantastic article which I believe was part of his dissertation about shmups: 

http://www.gamasutra.com/blogs/LukeMcMillan/20130206/186184/The_Origin_of_The_Shmup_Genre_A_Historical_Study.php

Taking the twin-stick concept that was built on mobile over to console provided lots of opportunity for innovation.  While twin-sticks on mobile platforms are fun, ergonomically I found it more comfortable to play a twin stick with a gamepad.  More importantly, the environment in which the game is played makes a difference, and consoles are great for local coop games. Adding local coop to the base code was fairly easy to implement with Unreal Engine, but becomes much more challenging to design for in terms of gameplay balance, engine optimization, and UI design.  

Challenges of a Depth Biased Shmup with Local Coop

Bringing four players into the twin-stick concept meant reevaluating gameplay camera control, scoring, and gameplay strategy.  Timing had to be adjusted on nectar re-spawn to make sure four players had competitive access to nectar ammo.

Camera control could no longer follow a single player, but instead need to sit somewhere in the average position of all players.  Because the proc-gen arena was larger than the camera’s frame bounds, the camera needed to dynamically adjust based on player location.  When players were close together, the camera could be closer to all players, but when players are far apart, the camera needs to be pulled out to a distance so all players were still in the field of view.  Creating this mechanic caused gameplay strategy to shift mid-game. Players are rewarded when spreading out by seeing an overview of the map, but they will be weaker when far apart since enemies scale based on player count.  However, when players are close together, they need to communicate to isolate nectar shots, and delegate nectar pickups when needed. 

With up to four players on the board, nectar was also consumed much faster, so nectar respawn time needed to be reduced since the actual nectar spawn location count would be the same in a multiplayer game. The byproduct of this decision created some great friendly-conflict play during multiplayer testing as groups of players would race to grab the nearest nectar denying their friends of much needed nectar.

Lessons Learned & Looking Ahead

Writing a ‘lessons learned’ section in this type of blog is a bit redundant because the whole process is a ‘lesson learned’ with the art, science and business of game design & development.  Reshaping similar content into different variations of ‘game’ for different platforms was enlightening and a nice way to self-teach along with community resources.

Market segmentation was really noticeable during cross-platform testing, and I think that had an impact on how Flutter Bombs developed.  

Online feedback from game communities vs. in-person feedback was very different.  People providing feedback online were typically more honest, but people providing feedback in person provided much better ‘intuitive observational’ data meaning there’s value in understanding a person’s first inclination to make a decision or choice in a game which could drive gameplay moving forward.  

Testing a concept out on multiple platforms was a great way to discover synergistic relationships in game features.  Navigating a physics object in the form of a butterfly around an environment was fun. Equipping said physics object with a gun was amusing, but deterred from core gameplay.  What was discovered in the process was this concept of the shmup with another Z-plane to work with. Moving forward, it may be interesting to study even a third Z-plane in the skies above.