RapidFire Studio

RapidFire Studio Makes Casual, Cross-Platform Games Follow us: @rapidfirestudio and fb.me/rapidfirestudio

[cristinacordova-deactivated2019]

When I read Fred Wilson’s post this morning about the tough times consumer companies are having raising money, his second point resonated with me most:

“distribution is much harder on mobile than web and we see a lot of mobile first startups getting stuck in the transition from successful...

[soragora-blog]

The early days of mobile gaming were great for independent developers; any decent game with a little bit of luck could strike fortune for the small team of passionate developers and artists. However, as the mobile ecosystem continues to mature and billion dollar players set their sights on...

[rapidfirestudio-blog]

New Development Article in GameCareerGuide

An article we've been working on for GameCareerGuide (a sister publication to Gamasutra) is now live. The article covers using Unity (we wrote it back when we were still using Unity full time) to make a simple infinite-scrolling space game.

Here's the link: Making An Infinite-Scrolling 2D Game With Unity and Boo

[rapidfirestudio-blog]

Why We are Killing Our Game and Moving from Unity to Moai

We're killing our current game after six months of development time. We're also starting a new game. In the transition we're changing most of the processes that we've put in place including moving from Unity3D to Moai.

One of the hardest decisions you face as an entrepreneur is knowing when to kill a project (or to dump a bad client or to kill a business entirely). To do difficult things it's critical to have a "never die" attitude. But it's also critical to know when to cut losses and move on. If you're a student of entrepreneurialism, you've probably heard people talk about the fallacy of recovering "sunk costs", pivoting, "the dip", etc. The bottom line is sometimes it makes sense change your mind and start over.

We've made quite a bit of progress on "Untitled Space Game". It's gone through three major iterations. But ultimately it was too unfocused (and possibly too ambitious) for our first game. We've realized that scope should be aggressively limited in order to reduce iteration time to a bare minimum. While we could have gone for a fourth conceptualization of our current game, we decided a clean break would be the best way to go.

A clean break means throwing away a lot of hard work (and some cool art) but it also frees us up to take everything we've learned in our first six months and do things the right way (at least, to the best of our knowledge at this point). That means making a lot of decisions that I won't go into here except for our new choice of engine. One of the first things that was discussed when we threw around what we would do differently was the desire to move from Unity to Moai.

If you haven't heard about it yet, Moai is an open-source 2D (with limited support for 3D) game engine made by Zipline Games. The engine itself is minimal though it supports the major features you would expect in a game engine. It's scripted with Lua -- a very terse and performant language that has seen a lot of use in game development. Though it's focused on iOS and Android, it also runs natively on Chrome, Windows, Mac and Linux.

When you're running a business, you want to pay for things that actually matter. Moai is great in that regard. The engine itself is free. What you pay for (if you choose to) is their cloud offering, which allows you to build networked games, send push notifications, etc with a freemium, scale-as-you-go model. It's free to get started and the fees increase only as usage increases. And the prices are very competitive.

But what's really attractive about Moai is its mentality of what's important in game development. Games today need to be connected -- connected to serve ads, run analytics and performance monitoring, connected for IAP, to connect players and add social elements. Moai seems to start from this point and move outwards, not tack on these features after the fact. Unity, in contrast, doesn't include these features in its core offering. Most of the functionality mentioned has to be purchased from a 3rd party and integrated separately.

Moai also keeps the engine as simple as possible. This allows developers to squeeze as much performance out of it as possible. Mobile games today don't need eye catching graphics as much as they need to be defensive about running on a wide range of hardware. We saw this again and again developing with Unity. Even though we were following the standard rules of mobile development (low number of draw calls, low number of verts, low memory usage, simple shaders, etc) performance was constantly an issue.

We've talked a bit about why we don't like Unity. You might say that this is apples to oranges since we're comparing a 3D vs 2D engine. That's true of course but I would argue that for most studios focused on mobile there isn't a practical difference. The lack of performance and decent controls on most mobile devices makes the 3D experience lacking at best. There is very little immersion in mobile gaming and high production values in 3D art, music, sound and effects would be lost on most players. I don't think this is likely to change in the future. Processors might get faster and memory larger but screen size, controls and inconsistent sound are locked into the mobile form factor.

To sum up our decision to switch:

Unity good:

Most of the time it just works across platforms. 

Large community. 

Royalty-free.

Good built in physics and particle systems.

Decent editor that makes prototyping somewhat fast.

Unity bad:

Closed source (for most users).

Overpriced for its target market (indies, new studios, small studios) with regular paid upgrades.

Lacks many core features (you have to buy community-supplied add-ons or write them yourself).

Analytics, performance tracking, monetization not included.

Performance still lacking for mobile devices.

Very bad code editor (at least on Mac).

Verbose language choices (except for Boo, which is good but lacks documentation and tutorials)

Unpleasant and hard to reach sales and management teams.

Moai good:

Free and open source.

The paid side of Moai (their cloud services) have a freemium, scale-as-you-go model.

Analytics, performance tracking, monetization part of the core offering.

Device "hosts" are easily customized.

Responsive forums hosted and moderated by the creators.

Moai bad:

New and unstable.

Documentation and tutorials still somewhat limited.

Not geared towards the inexperienced.

Very limited 3D support.

Admittedly hard to use particle engine.

"Unpleasant and hard to reach" should be explained, but I'm not going to take the time. Personally I've had mostly unpleasant interaction with the Unity team (in person, over email, etc) but that's a very small part of why we decided to switch. Having said that, I absolutely do not recommend Unity for mobile development unless you have a very compelling set of reasons why you should use it. It may be popular but it simply is not a good fit.

So now we're moving on into this bright new future. Our new game will be simple but fun. There's not much to talk about now as most of the game will be decided as we validate our starting assumptions. Ultimately, it feels (down deep in the entrepreneurial gut) like the right move as does going with Moai.

Stay tuned!

[rapidfirestudio-blog]

(Untitled Game) Mega Screenshot Update

I haven't put out any information about our upcoming game since we finalized the (new, updated) concept. We're in heavy development now and are still planning on having this game in testing by the end of the month.

The following screenshots outline a lot of the basic gameplay. Combat is getting finalized now, so there are only a few shots of combat available. Most importantly, combat will include physics-engine driven homing missiles, flare countermeasures and other interesting bits flying around the screen.

What is this game? To save a dying civilization, you have to cross the known galaxy. I want to call it a space-trekking game. Space is a big element in the game. You need to find resources (and other goodies) without being found -- or at least being found as little as possible. There are no RPG elements here. Combat does not increase your abilities or weapon capabilities. Like in the real world, combat uses up valuable ammunition and gets your ship damaged. There are only a few places in the known galaxy to get your ship repaired and supplies replenished, so avoiding combat is just as important as getting good at it. There's a heavy simulation element to the game. It asks the question: what would happen if I needed to warp across a hostile galaxy with a single ship, limited resources and virtually no allies.

Some images below:

Menu screen -- still no title yet

High-level galaxy map -- destination on top

Local star systems and warp range

Loading remote scan info about system

Shot of warp cutscene (looks more interesting in motion)

Arrived at new system

Firing engines

Arming auto-cannons

Sensor map -- some enemies in sensor range

Matching course

Intercept

Enemies inbound

Auto-cannons firing (they fire fast, hard to get a good shot of them)

Enemies coming apart

Threat eliminated

[rapidfirestudio-blog]

The Name Change

GameSmith is now RapidFire Studio.

And now, an explanation:

RapidFire is my third company. I've been an entrepreneur since my mid-20s and have never had a company I started fail. I've had my share of individual projects fail but never a company that I had committed to.

My first company was bricks and mortar (a PR agency). We carried heavy staffing requirements and had an 18-month sales cycle (seriously). We were also majority foreign owned and therefore could not qualify for bank financing. It was a grind to say the least. Still, I didn't give up on it and when I left the company (in the hands of my partners) to follow further dreams it was an established company turning a healthy profit. It still is today.

Next I started a software company that took a couple of years to really gain any traction. That isn't because tech is slow -- it was the fact that I had to start from scratch. I had to learn how to program, for one. My girlfriend (now wife) and I moved into a studio apartment to cut our expenses and I vowed I wouldn't leave it until I had built a successful software company. I worked 16 hours a day for nearly two years until I could build my own software and also understood the market enough to sell it. To cap that period off we got married and moved into a spacious luxury condo about a year ago. Tough times followed by happy times.

So, back to failure:

One of the most powerful skills an entrepreneur can develop is knowing when to quit. It's critical to be able to push though something no matter what. It's also critical to know when to abandon things.

We recently talked about re-writing RapidFire's first game on this blog. Since then we've actually rewritten that rewrite. Why? I don't expect us to take over the world with our first game but I do expect that game to be fun. And I made the decision in our first six months here (will be six next month) that delays at the beginning are acceptable if the results are worth it.

Why add risk to risk by rewriting a game? Because the feedback on the first versions wasn't strong enough. People thought it was interesting and some of the physics-based action was pretty cool, but I could tell there was no real click.

So we decided to rewrite it again. The new idea, which we'll start talking about pretty soon, I feel is the right one. The people that I've discussed it with think it's a fun idea. Most importantly, I think it's a fun idea. It has that strange quality of being a new idea -- going in a direction we hadn't considered before -- but feeling like the idea we were supposed to be making all along. Development is moving rapidly now and we're still trying to get it out by mid-year. I'm confident we'll make that target.

What does this have to do with our new name? 

I felt the same way about our name as I did about early versions of our first game. People would respond "ah, ok". I got lots of "ah, ok's". And as much as I wanted to stick with GameSmith for the sake of consistency and not giving up on something, I decided to pivot with our name as well. 

I think it's a sane choice. This company is very young, we're barely known yet, and sorting out hiccups early on will give us a better foundation in the years to follow.

So there it is: a new name, a new (re-)revised game and our absolute determination to accomplish what we've set out to do.

We'll have updates on the game soon.

[rapidfirestudio-blog]

Here's our new company logo.

[rapidfirestudio-blog]

The Game Change

When I started GameSmith I decided that we would build the company around a few simple ideas: quality, fun and originality. The first two are expected. If you want to make successful games they absolutely have to be fun and if you're not ripping off your customers they should be made to high standards. The third idea is somewhat optional in game development.

The game industry seems to echo the film industry when it comes to originality. Original creations appear and often find financial success, but a large percentage of the industry focuses on the creation of sequels, clones and makeovers of tried and true concepts. 

Creating something that's original is risky. You don't have a solid roadmap to follow. Knowing if your idea has legs is hundreds or thousands of hours of development time (and money) away. We learned this the hard way when our original idea (a simplified, almost tower-defense like RTS game) reached baroque levels of complication trying to make it fun. In order to keep scope reasonable we tried to build a very simple RTS game. In the process we threw out most of the elements that make an RTS game fun.

We then had two choices: increase scope and add more RTS elements or change the main gameplay to something else. We knew we didn't want to make an already growing project larger so we decided to pivot.

The most manageable game style we could come up with that allowed to keep our original story was that of a lone fighter crossing the galaxy. It would be top-scrolling and have very simple controls. We also thought a space shooter would be fun provided we could give it enough unique elements as well as keep the original depth of story we had planned.

We're now a couple of months into this new idea and it is taking shape. A few highlights are:

1. Simple, arcade style controls. Four-button platformers were fun so why don't we keep our touchscreen controls simple? Too many otherwise attractive games fail miserably when it comes to virtualized controls.

2. Interactive dialog. Relationships matter (especially with your co-pilot). Character matters. Who you are does effect the outcome. 

3. No DLC, IAP or other bait-and-switch crap.

4. High price. No, really. Games are expensive to make. We want to make games that are not compromised by monetization strategies (see #3 above). That means we have to charge. We're probably talking under US $10, but certainly not "freemium" or $0.99.

Some of the new art and gameplay in screens here.

Update (August 27, 2012):

This post was written a while ago but had been sticking in my brain. Items #3 and #4 above were wrong. DLC and IAP (and F2P) are not "bait-and-switch crap", they're effective ways to get games in front of as many players as possible while generating revenue. Ongoing monetization via unlockable features and content are an excellent way to generate revenue without running ads (not that there is anything wrong with ads either, though they often do have an aesthetic impact).

[rapidfirestudio-blog]

Screens from the game's combat sequence.

[rapidfirestudio-blog]

We registered at http://thumbarcade.com to get our games on this killer new mobile and online gaming site. If you're a game development studio - get over there now! If you are one of our fans, then register to be in on the launch of something amazing.

[rapidfirestudio-blog]

The Role of Path in Tower Defense Games

If you're making iOS and Android games it's hard to overlook the success of Tower Defense games on these platforms. It's not hard to understand why. TD games offer focused, puzzle-like strategy with very easy to learn controls and mechanics. They fit well with mobile devices' awkward input and the short attention span of mobile play. They're strategic, but stripped down versions of their RTS big brothers. I like to call them "RTS games on rails." The rail of course being the path.

Most TD games have a path. The path can be fixed or user-defined. The path can be series or parallel. There can be one or many in a level. Fixed paths are most often curving and looping corridors that stretch from one side of the screen to another. Player-defined paths emerge from tower placement combined with enemy AI. Paths are varied but their roles are constant: to define attack range and attack time for the player. Most importantly they define your enemies' goal, the consequence of the player's defensive failures and the loss condition for the game.

I think that's a large part of the reason TD games fare so well as casual games. The player has immediate feedback on the consequences of bad strategy. Don't shoot the bad guys enough times and they happily enter your little doorway of demise. Conversely winning is also clearly defined. Shoot the bad guys enough times and they're no longer a threat. Enemies getting harder to kill? Add more guns or upgrade the ones you already have.

The best TD games allow path to define gameplay. I think geoDefense is one of the best examples. Different weapons are more effective based on where they are placed in relation to path. Lasers are most efficient when placed adjacent to long straight path segments (they can shoot through long rows of enemies). Machine guns are most efficient in curves or loops (limited range but very high rate of fire).

Image courtesy Critical Thought Games

The weaker TD games (like TowerDefense) have an ill defined relationship between path and weapons. Gun tower or sniper tower? Just buy the one with the cooler animation.

Games misuse path at the expense of gameplay. The hit Plants vs Zombies is a good example. While a parallel path is innovative, it breaks the relationship between path and weapons strategy. Which weapons to choose? Where to place them? Doesn't really matter - just make sure every path has something in it.

The game my company is currently working is forcing us to think very critically about the role of path. We want to innovate and while keeping the well defined, focused gameplay of a rigid-path TD game, we want to -- gasp -- eliminate the path entirely. Why be so foolish? We want the focus without the aesthetics. We want our game to feel like a space RTS or even shooter, but we want to keep the on-rails gameplay of TD.

The development of this core mechanic is running in parallel with most of the other development. In an ideal world we would have settled on this first, but sorting out this aspect of gameplay is hard as well as time consuming. We've pushed ahead developing as much of the game as we can safely knowing the game as a whole is still in flux.

But we've recently had a breakthrough. This whole time we've been searching for a way to stick an invisible path in a game that doesn't have room for one. But then it occurred to us that a path that can be understood as space can also be understood as time. Like a micro-Einstein moment we realized we could swap time for space and create -- ta da -- a dimension-less path.

The trick of course is to now represent time as clearly as a path does. We have some ideas on this that'll we'll be testing in the next few days. We do have graphical ways for representing time clearly - pie graphs, clock animations, even numbered countdown timers. We're thinking that we can apply these elements to represent the amount of time before an enemy does damage.

A path is a way to visualize the time you have to eliminate an enemy before it hurts you. But you could take the enemy out of the path and give it a clock. These are equivalent. Making that mechanic clear and fitting it into overall gameplay (aesthetically and mechanically) is certainly a challenge, but what we believe is a worthwhile one. We'll see how it goes. We're feeling pretty Zen tackling the path-less path. We're hoping that it gives the sort of focus to our game that makes TD games so compelling as casual games.

[rapidfirestudio-blog]

And we're done... Added some dummy titles and threw in a little post processing. Really love what our illustrator came up with.

[rapidfirestudio-blog]

The final draft of our first game’s promo art. Just a couple more tweaks...

[rapidfirestudio-blog]

Why We Switched to Unity3d

When we started GameSmith I talked briefly about writing a game engine. To summarize, it's rarely a good idea to do so. When you're a small / bootstrapping / indie company you should constantly be searching for leverage in the tools and resources available to you, not creating more work for yourselves. Using a game engine was a straightforward decision for us, but we did spend quite a bit of time deciding what game engine to use. We originally thought Unity3D was too resource hungry (as our primary platform is iOS) and wanted something closer to the metal. After some preliminary work, we changed our mind. I'll outline why below.

I won't go into all of the engines we looked at since I don't want to do a comparison (at this time). After quite a bit of research and testing things out we zeroed in on Unity. I want to outline our thoughts on that to help anyone one else evaluating the platform.

Our decision making in general:

Within reason, price should not be a factor. Or, there's no such thing as free. Any engine requires an enormous investment in time (which of course is money).

Following that, open source / free is not free and not necessarily the best community dynamic for tools used in commercial products. Open source in general is awesome and necessary and we support it 100%, but for tools used to make commercial products, a for-profit, customer driven company will often be a better fit for a for-profit, product driven company.

It's easier for a 3D engine to do 2D than vice versa. By investing in a 3D engine, we would keep our options open.

For 2.5D (the middle road case) you're either baking your 3D models beforehand (with a 2D engine) or rendering them dynamically with a fixed camera position. Either way you can use the same models, though using a 3D engine provides a much more efficient pipeline. A good example would be changing the perspective of your camera. With a 3D engine, this is instantaneous and free. With a 2D engine, you have to re-render every model in the scene.

Cross platform might be a bad decision if you're primarily focused on one device market and it comes with too many compromises. However, if you can get away with it, investing in something that is cross platform greatly increases the future potential of your project.

We spent about a month with Unity before committing to it. We've since put in a couple of months with it. I'll outline our initial observations below:

Unity3D pro:

3D engine (positives outlined above).

Good, centralized documentation. 

Commercial (they have more responsibility to their stakeholders) though not terribly expensive.

Strong 3rd party plugins and other resources available in the Unity Asset Store and on the web.

True cross platform. While designing for different platforms is never straightforward, getting a game to run on multiple platforms with Unity (almost) is.

Unity3D con:

Sales team doesn't answer emails. (They also don't show up for appointments in person but that's another story.)

Pro license required to disable Unity splash screen. That means paying an additional $1500 USD. If you need other pro features, that's not that big of a deal. In our case though we are only considering pro to get rid of the nag screen. That makes it an expensive decision.

No realistic built-in UI toolkit. In order to put a UI in a finished product, that UI needs to be optimized (by reducing it to a single draw call) and work across multiple platforms. I assume they're not pushing this obvious issue forward because there are several successful 3rd party add ons that do this properly. We've had success with UIToolkit.

Weak touch support for touch enabled devices. 

No real support for 2D. This might seem silly given that it's a 3D engine, but since 3D can easily handle 2D it should be looked at more seriously by the team. However, there have been successful 2D games built on Unity and there are several 3rd party add ons that aid in development.

In summary we're pretty happy with Unity so far. It's not perfect but we haven't yet seen an alternative that fits our needs better.

We're just getting started with it and we hope to have the time to talk more about out experiences with it, the solutions we've found to its problems and hopefully be able to share some tutorials / code here for others to use.

[rapidfirestudio-blog]

A color test of our first game's promo art. Still some tweaking to go but it's getting there.

[rapidfirestudio-blog]

This is preliminary sketch for our first game's promo/splash/menu art. The title is fake (the font, color and wording will likely change). It's just there to get the feel of it. We like. A colored version is coming next.

[rapidfirestudio-blog]

This is very early development work for my company's first game. This is the first video made after moving to the Unity 3D game engine. This shows the mockup UI and a few of the early ship models from our 3D girl. (The largest model was downloaded without restriction from a 3D model website and won't appear in the final game.) It also shows background rendered by one of Allegorithmic's substances (dynamic textures). Background music courtesy miii - jamendo.com/en/artist/miii