From the entertainment industry powerhouses to international medical device corporations, we have made games for clients in several verticals. Each industry is different, and each company starts the conversation with different expectations. Some have a solid idea or concept that we help them flesh out and bring to life. Others want to work closely with us on several iterations of a design doc. Still, other organizations request that we create a submission for an RFP (Request for Proposal).
We understand that for many companies this might be their first experience in the video game world, and we are happy to go through whatever discovery process helps them make an educated and strategically beneficial decision. Through many conversations like these, we have gathered a set of criteria which represent the “best practices” to ensure that you – and we – are getting the necessary information for a successful partnership.
Although the topic of timing and controls is generally reserved for fighting game conversations, we had some unique behind the scenes adjustments lately that we wanted to create a resource for.
We are porting some of our NES games with a partner to distribute on the App Store & Google Play. Rather than having the games recreated and mobile-optimized, we’re using a custom emulator that, when complete, will allow us a near drag and drop solution for releasing them through these digital storefronts in the future.
This might look familiar to some of you!
For those of you that have played Log Jammers, you know it’s a fast-paced arcade sports game where timing and precise controls are critical for success. Looking at the image above, you’ll see that this game includes local co-op play, something we thought would be fun for mobile as well. After some iteration and community testing on timing, inputs, and an increase in the total area that you can touch and interact with, we had one final adjustment to make: simultaneous button press timing.
In many games, two face button presses are required. In Almost Hero, as an example, A+B is what unlocks the jump kick, which is arguably the most important single move in the game.
By default, the custom emulator we were using does allow an A+B press, the timing just required exacting precision that created a mediocre gameplay experience. Mobile games should have an additional eye towards accessibility, and this type of frustrating control requirement without a reward won’t be leaving anyone in mobile's general addressable audience feeling excited.
Simultaneous inputs are possible without making any modifications to the emulator but are extremely difficult with touch controls. The strict timing is particularly noticeable because pressing the fingers down evenly lacks the physical feedback of button switches, which greatly helps in achieving truly simultaneous inputs.
Buffering can be used to simulate this physical feedback by adding a delay for singular A/B presses (e.g, 50ms) and waiting for the other to be pressed. If the other is pressed at any point within the 50ms buffer window, they are both immediately submitted to the emulator at the same time. If the other button is not pressed within the buffer, just the one that was pressed is sent to the emulator.
Software-level buffering like this is common, especially in fighting games, but even a very slight additional delay on top of the existing native delay from the emulator may have been too much.
Without physical buttons or the use of a buffering solution, the difficulty of true simultaneous inputs, therefore, depends on the game's frame rate. The game has to receive both touches on the same frame for it to be registered as a true simultaneous input. If one button is even 1 frame off from another, it means the input systems will receive one button first and start acting upon that, causing it to not use the next button on the next frame (assuming another in-game action was started by the first button). This is assuming the emulated game code itself does not use a buffering solution on the inputs it receives, in which case a buffer at the emulator layer would not do any good.
A phone I was testing on was somewhat laggy, running at about 30 FPS, which means 1000ms per sec / 30 frames per sec = 33.3 ms (per frame) window for simultaneous inputs. I can get simultaneous inputs around 50-75% reliably at that frame rate. If someone was running the game smoothly at 60fps, they would have a 16.67ms window to perform a simultaneous input, which is unreasonable and makes getting a valid simultaneous input impractical.
To improve upon this foundation, we added an optional input buffering system into the emulator. This buffering system is easily customizable on a per-game basis (including whether it's used at all). Any games which depend on a lot of simultaneous inputs would have it turned on and tuned to a value that feels like a good compromise, and games with no simultaneous inputs would have it disabled.
If there’s one genre that’s taken the world of indie games by storm in the last few years, it’s the rogue-lite. Or, perhaps, the roguelike-like? While the specifics of what to call these games is often argued, most of them are addictive, replayable, and challenging thanks to the magic of procedural generation.
Procedural generation is a technique that game developers employ to create content that generates its own unique challenges. This means it can reduce development times and costs, and thanks to its unpredictable nature, sometimes surprise both players and developers.
What Is Procedural Generation?
Simply put, data of any sort is procedurally generated when a mathematical algorithm is responsible for its creation. In the world of gaming, a wide assortment of things can be procedurally generated. For instance, a developer could create level assets like pits, enemies, obstacles, story elements, and power-ups and then, using procedural generation, set these things to appear at somewhat random locations throughout a level.
The advantage of using this method is that potentially thousands of unique levels could be created without human intervention. This drives endless replayability. A procedurally generated game could be enjoyed for ages longer than a game with traditionally generated levels thanks to players enjoying “new” levels years after the game’s development has ended.
Where Is Procedural Generation?
As mentioned earlier, the procedural generation has its place in a level generation. However, good procedural generation is more complex than our illustration may lead one to believe. When used to fill out a video game level with obstacles, for instance, parameters still need to be determined in advance to keep the game both fair and fun. What if a poorly coded procedural generation algorithm threw an abnormally large number of enemies at the player in the first level? It’d certainly make the game more challenging, but it’d also make the game less fun for new players. A game can’t enjoy longevity if it has no early life to speak of!
One deservedly well-loved rogue-lite that balances procedurally generated content with pre-determined elements is FTL: Faster Than Light in which players guide a ship through a galaxy full of hazards to deliver a message to the far side of the galaxy more or less in one piece - and then to defeat a massive, incredibly powerful enemy ship. While FTL can itself be beaten in a couple of hours (technically), the overwhelming majority of playthroughs end in death. Yet, players come back to the game over and over again, thanks to its use of procedural generation. There aren’t an amazing number of enemy types or items, the game’s story is neither lore dense nor dialogue-heavy, and yet it’s a game that keeps people hooked.
Every new run in FTL presents new possibilities. It’s a bit like gambling, really: you could be blown out of the sky in the first sector or, thanks to random chance and skill acquired through playing, you could make it all the way. The random elements in FTL keep it challenging and replayable. However, they’re not the only reason why the game works - it’s also well balanced, carefully crafted, and manages to be challenging in other dimensions without being unfair and frustrating.
Putting It to Work
For our own game, Bite the Bullet, we recognized the value of procedural generation and, early on in the development cycle, put it to work. Bite the Bullet is a run-and-gun platformer with RPG eating elements. Choose a class based on your diet (like the vegetarian Slaughter of the Soil or the carnivorous and blood-soaked Gorivore), eat your enemies to turn them into XP, and unlock powerful abilities (like Appetite for Destruction, which lets you eat incoming enemy projectiles). This set-up opened the door for some procedurally generated systems.
For example, there are plenty of side quests, bonus modes, and hidden areas in Bite the Bullet, but getting to them is a quest in itself. See, in BTB, side quest locations are randomized, so where you found that rideable hamster at a certain level isn’t where you’re going to find it the next time. Although the core of each level is designed by hand, this procedurally generated content keeps the gameplay fresh and engaging.
One of the most exciting possibilities that procedural generation offers is in terms of equipment that becomes available to the player. In FTL, you’ll occasionally receive weapons and ship upgrades, each with their own pros and cons - each new combination of items opens up fresh gameplay possibilities. In Bite the Bullet, we take things a step further: weapons can be combined with mods in order to change their effects. Love your missile launcher? Well, you can combine it with a mod that allows you to shoot multiple missiles simultaneously. Not enough for you? That’s alright, it wasn’t enough for us either - you can find an incendiary element that sets fire to your foes.
Worth It?
We knew that for Bite the Bullet, procedural generation offered a lot of advantages, but it also came with some risks. The technology is brilliant, but it does have its limits. For instance, procedural generation is not well suited to creating strong puzzles. That’s why Image & Form, after having used procedurally generated levels in Steamworld Dig ditched them in the sequel, in order to create puzzles that procedural generation wouldn’t.
Similarly, we were concerned about how procedural generation would impact the core mechanics of Bite the Bullet. We wanted levels that showcased all of the player’s abilities - jumping, dashing, and (of course) EATING. For example, the game’s calorie meter is drained for significant player actions, encouraging the player to keep gorging himself on his foes. If the procgen system didn’t sprinkle enough tasty enemy treats throughout, players would be a starving, weakened mess. This was another reason to design the levels by hand.
Game design is undoubtedly a tricky business. What on the surface looks like a small decision can, with poor management, turn into an imbalanced and precarious catastrophe. Creating video games is as much an art as it is a science. Procedurally generated elements, exciting as they are, do not come without the ever-present element of risk.
And yet, we are driven to include them. The magical spark of possibility that they open up to players is too powerful to ignore. At Mega Cat, we’re taking the risk, and we’re putting in the work on Bite the Bullet to create a game that you’ll love for a long time.
Ready to chow down? Wish list Bite the Bullet on Steam! You can also step into the kitchen and help test the game by joining our Discord!
