Galactic Colonies – Accessibility Update

Since I announced that it will still be a little longer to get the accessible version of Galactic Colonies out, I thought I could at least keep everyone updated on the progress. 

First things first – no, I don’t have a release date for the accessibility yet. But the game is coming along great, and a lot of things have been done in the last two weeks. I wanted to give you a little update on what I’ve been working on, and share a short video.

Same UI, but different

I’m trying hard to make the accessible version of the game use the exact same UI as the game has when accessibility is turned off. That is not only consistent, but it makes it a lot easier to maintain the game, too.

But this doesn’t always provide the same game experience to sighted and non-sighted players. Sometimes a small change in how the UI works can make the game more enjoyable for players that rely on a screen reader.
Let me give you an example. 

To construct a building on a planet, a sighted player first selects the building from a list in the build menu. Then he can see the price and time it costs at the top of the menu. If he has enough money, he’ll hit the button labeled “Build” at the bottom of the menu to start construction. 

Sounds simple? Now do it blind!

Image doing the same task when you are navigating the construction menu with a screen reader, and traverse all buttons one by one.

Selecting a building is easy enough. But then you’d have to navigate back to the beginning of the page to read the price and the construction time. And this is assuming that you even know that you have to do that in the first place. Then, if you want to build it, you have to get to the very bottom of the page where the build button is, traversing through each and every building button on the way. The information and functionality that is instantly available for a sighted player is hard to get to for non-sighted players.

So instead, when accessibility mode is on, the price and construction time of a building is read out immediately along with the building name. And if the player wants to start construction, he can double tap while the building is selected, and that will automatically start the build process. No need to navigate to the build button at all. In fact, the button won’t even be shown if accessibility mode is turned on.

Side by side comparison of the construction menu in Galactic Colonies.

Left shows sighted mode menu, right shows the accessibility version

The code of the user interface had to be partially rewritten to support this change, but I think in return the construction menu is now really usable. You can see and hear this in action in the video at the end of this post as well.

Selling Stuff

To sell product from a warehouse, sighted player can use sliders. While they drag the sliders to the right to sell more and more of the product, other part of the UI will change to display how much product will remain and how much money will be earned if the player lets go of the slider at that point.

This is not practical for screen readers at all.

We took a lesson we learned from Crafting Kingdom and replaced the sliders with buttons. One button to sell all, one button to sell half, and one button to sell a single unit of the product in the warehouse.

Here’s screenshot of the warehouse menu for sighted and for accessibility mode next to each other.

Side by side comparison of the sell menu in Galactic Colonies.

Left side shows the slider based sighted version, and the right side the accessible version which uses buttons instead

In this instance, the UI had to be replaced by completely different UI which is only active when accessibility more is on. This change required both new code and a new user interface setup, so it took a little longer. 

Got something to show?

After the last post only included an audio demo I’ll include a short video in this one. Please keep in mind that this is still all extremely work in progress and by no means ready for release yet.

Thank you to everyone who’s commented and thank you for all the patience.

Galactic Colonies – Accessibility Sneak Preview

Galactic Colonies is on track to be fully accessible. Soon-ish.
Actually, it’s coming along quite nicely. I made a recording of the first 4 minutes of gameplay. If you’re interested in a sneak preview, here it is:

If your screen reader has issues with the sound cloud player, here’s a direct download link: Galactic Colonies Accessibility Audio Demo

Sounds like it’s almost done, when can I play?

In the demo, things sound a little further along than they actually are. In reality there is still a metric ton of work to be done.

I’m sorry to say, I have no release date for the accessibility patch yet. But it will more than likely be a few more weeks.

Different from all other games I’ve made accessible in the past, this game has a lot of 3D elements. Those are making things tricky, and there is need for many creative solutions.

Sounds a little… vague?

Fair enough. I’m going to describe an actual problem that I’m working on this week. That should demonstrate why it takes a lot of time to make this game accessible.

As part of the game, players have to build colonies on planets. This gameplay happens on the planet’s surface. Players can explore new regions, construct houses, farms and other production buildings and set up a flow of products between buildings. Everything is in 3D of course, and the camera can be moved and zoomed.

Screenshot showing a colony on a jungle planet, more than two dozen buildings, many lakes and part of the ocean

Colonies can get large

The difficulties start with selecting a free region to place your next building on. In the beginning only a handful of regions are explored, but there are a total of 2500 regions on each planets surface. Obviously I don’t expect players to swipe through them one by one, by one by one by one… I need to find a different method for players to navigate their colony.

The planet surface is flat, but it is a hex map, not squares. So a simple up, left, right, down navigation doesn’t cut it either. Each tile has six neighbors around it, not just four.

It is important to know which tiles are next to one another. Farms built next to a lake will produce more food. Houses next to an industrial building will have reduced capacity. Because which colonist wants to live next to a polluting, stinking factory? So the game can’t simply make the decision of where to build next for the player either.

The problems don’t end there. Some buildings need to be connected, so that one building can deliver products to another. You can produce food all day long, but you need a warehouse to store it in. And then you want the food to be distributed to your various houses, so your colonists don’t starve. Buildings that are too far apart cannot be connected. And one warehouse can only supply goods to a maximum of four other buildings.

Colony on an ice planet showing a warehouse receiving food from a farm and distributing it two connected houses

Warehouses are among the most important buildings in this game

Planning out what is delivered where is a core part of the game, so again, the game cannot make these decisions for the player automatically. These connections are set up visually by tapping on the buildings you want to connect. Difficult to do if vision isn’t an option.

But as you can hear in the audio demo, I haven’t been idle these past few weeks, and some parts of the game are already playable.

That was just a glimpse

I’m spending my days trying out a lot of different solutions to all of these problems, and then throwing away anything that doesn’t work.
This, obviously, takes time.

And keep in mind, everything I described above is just one of the mechanics in this game that I have to solve. It isn’t the only one. I haven’t even talked about space travel yet!

We made a good game with Galactic Colonies, and I’m determined to deliver a good experience on the accessibility part, too. I know as well as anyone how frustrating waiting can be, but I’m convinced it will be worth the wait.
Thank you for being so patient!

Dev Update #14 – Concept Graphics and Aspect Ratios

Have your base (classes) covered!

In spite of what I wrote in my previous blog post, I realized I need to create one more department before I can finally tackle the Build Menu: The Management department. Like the Design department, this one works differently from the production floors. This makes a difference from the coding point of view – as I want a base class to take care of all floors, and then handle only specialized stuff in derived classes. And like I said, I want all my bases covered.

Here is the mockup graphic for the Management floor:
Management

The idea was that a Management floor can employ up to four development directors. Each director would allow for one game to be in production. This way the player can work on multiple games at the same time. But I made a pretty noobish mistake when creating the above mockup – I hadn’t given any thought to the aspect ratio of my floors.

Aspect Ratio, anyone?

When creating the actual game graphics for this floor based on this mockup, I ran into some trouble. I hadn’t really thought about aspect ratios and screen width when I created those images. That was a big mistake, as it turns out. The mockup screens were too wide. There was simply no room left on the right side of the screen for the two big purple buttons, not unless I scaled the height down.  But then everything else in the floor would become tiny. To counteract, I would have to scale up the characters. But then I didn’t have enough room above the head of the managers to put the actual game icons. My characters were simply too big.

So I redesigned that department completely. Here’s the result (middle floor):

BlogPost15

Instead of placing the icons above the characters’ heads, they were placed next to them, sorta like a PowerPoint screen in the background. It actually gives it a nice manager look and feel. And as a bonus, this will free up some screen space at the top of each floor where I have been wanting to put a floor number. In another change, the Release and Trash buttons on the right are done away with. Instead, scripts can be released or trashed by clicking on them and opening up their details dialog.

I definitely learned my lesson and will create future mockups in a sensible aspect ratio.

Now, this time for real – next up is going to be the build menu.

Dev Update #13 – Code and Design Departments

It should have come as no surprise to me that spending my free time working on a game directly clashes with writing blog posts in that same free time. And one of these things simply comes more natural to me than the other. So it’s been five months… Time for an update.

I really want to start working on the build menu, but before I can do that, I need a few floors that I can actually build. So I created basic prefabs for the Code and Design departments.

Here are the results.
BlogPost12The Code department layout (top) represents the basic layout for all the basic production floors. 3D Art, Animation, Sound etc… they all will share the same basic setup with three queue slots. The Design department (bottom) works differently and needed a special setup. So it made sense to create these first and cover all my bases.

In my original game design document, the workers would all sit with their backs towards the player. This was mainly due to my poor drawing skills. But for the actual game I found this to be too boring. So instead, I turned them all around, so that they would be facing the camera.

The floors all use the same background graphic for the floor, which is actually grayscale. The graphic is tinted in realtime with the color of the floor.

Please keep in mind that the floors are not really finished yet. The coder for example doesn’t even yet have a computer in front of her. But it’s good enough to work with. Now I can start creating the menu that let’s me build floors into my game studio tower.

Dev Update #12 – Game Name Generator

I like to get all unpleasant work out of the way first – but I allowed myself a little fun task this week: A Game Name Generator!

blog_gamenamesFor my game Game Tower I need a bit of code that randomly generates game names for the virtual games the player creates.

This was probably the most fun task of all the work so far!

Pattern Matching

I went for a simple pattern matching system. The generator picks a pattern at random from a long list and then replaces the placeholder wildcards with random words from others lists.
Here are a few examples of such patterns:

<name> and the <noun>
<noun> Tycoon

The generator would take such a pattern and replace the wildcards with words from a list of pre-approved words. The wildcard determines which words match – there a nouns, verbs, names and plural forms of nouns. When all wildcards are replaced it spits out the finished game name, for example:

Jesse and the Unicorn
Waldo and the Zombie
My Mom and the Warlock
Zombie Tycoon

It’s soo much fun!

I added the name generator to my debug menu (see Dev Update #9) so I can test it out and generate new game names when I feel like it. It works great and I find myself adding new words or patterns to my database every few days, because it is simply that much fun.

GameNameGenerator

Good ideas come … while in bed.

All patterns and words are kept inside my trusted Google Spreadsheet. I have a macro that can convert them into a string list quickly, so I can get it into my code fast. I can access the spreadsheet from anywhere – and this has already paid off.

Like all coders (I assume) I have a lot of good ideas in bed. When I have a fun idea for a new pattern or a noun to add to the list. I can just reach for my phone and punch it in.

More updates and screenshots from the game in progress coming up soon!

Dev Update #11 – Tip of the Day instead of a Tutorial

I would like to see if it’s possible to make Game Tower a game that can be played without a needing tutorial.

It’s not that I would shy away from implementing one. But when I pick up a game, I would like to start actually playing it right away. So this is an experiment I will try. There’s two plans of attack I have for this: Giving the player more features only over time and a Tip Of The Day.

Tip of the Day

I like loading screen-tips in games, because I can easily ignore them when I don’t want them. A tutorial forces me to click at a sequence of buttons in a specific order and is much more restrictive. That is fine for other games, but feels like overkill for such a simple game like Game Tower.

BlogPost11More coder art for your enjoyment! Ok, I know that this is bad, even by my standards. But my plan is to get the entire game done and working. Then I can see to it that the graphics are replaced by someone with actual talent.

So I created this quick’n’dirty Splash Screen and a Tip of the Day database. A random tip is displayed every time the game is started. The game will load the player’s tower in the background while the screen is displayed. There is a minimum display time of 4 seconds, to give the user a chance to read it even if the loading is done faster.

Easy to Learn, Difficult to Master

Probably everybody has heard of Bushnell’s law, that good games are easy to learn and difficult to master. The actual quote is a bit longer and also mentions rewarding the player (here is an interesting blog post about it). But I’ll stick with the short-hand version for now.

Applying that to my no-tutorial experiment, it should be possible to make the game easy enough in the beginning that there is no need for a tutorial before the player can start actually playing. I will have to do some more trial-and-error testing, but my current plan is to provide the player with three basic floors instead of an empty tower at game start. That way he can immediately jump in and start producing games, rather than worrying about building the correct floors, hiring people etc. Essentially I want the player to learn the core gameplay first – and then get into the finer details as he levels up.

The level-up design should come in really supportive here as well. Since the player unlocks more departments and larger game designs by leveling up, the complexity of the game already starts out small and grows larger over time.

If at first you don’t succeed…

…make sure you don’t blindly ignore if something is just not working.

Making Game Tower playable without a tutorial is something I want to try. But I won’t stick to it like it’s set in stone. If in the end I discover that the absence of a tutorial makes the game to confusing, I will mark the experiment as failed and provide a tutorial. After all, the game is meant to be played.

P.S.: I am also playing around with different names. That’s why that screenshot reads “Game Studio Manager” instead of “Game Tower”.

Dev Update #10 – A Resolution Independent Tower

As promised I will post some updates about what has happened with Game Tower in the last weeks.

Creating the actual tower with all it’s floors was a little more difficult than the creating the overlaying UI and the menu screens. The main problem here was the various resolutions that needed to be supported. It’s a mobile game and with the multitude of phones and screens out there, it needs to be basically resolution independent. Buttons and other nine-sliced UI elements can stretch or be anchored and adjust themselves to different resolutions fairly easily. But the individual floors inside the game area are a different matter.

The floors should adjust to the screen size, but without squishing or stretching the graphics. Because of the different screens, the width of the tower is unknown. The tower doesn’t have a fixed height either, since I can add more floors to it as I play. This made it slightly difficult to set everything up.
BlogPost10I want each floor to use the entire width of the screen. Of course the graphics shouldn’t be squished or stretched, so depending on the width each floor then adjust it’s height to match the original aspect ratio that I designed it for. This would mean that the floor graphics look the same on all devices, but the amount of floors that are visible on screen at the same time depends on the aspect ratio of the screen of the phone it is being played on. Thinner or longer phones would show more floors than wider or shorter ones.

The new Unity GUI system is still fairly new to me, so it took me a little longer to figure this one out. But it finally worked. My code now calculates each floor’s position from it’s height, and the height is calculated from the width. Technically the game can handle it if the screen is re-sized in the middle of the game. Even though that would be impossible on a real phone, it’s just something I feel good about. The floors and their content keep their aspect ratios and adjust with the screen resolution, and I can even already scroll through the tower by dragging up and down.

There are more updates coming, next up is a startup screen with gameplay tips!

Dev Update #8 – Let the implementation begin!

With Thanksgiving finally out of the way, I have enough peace of mind for another blog post, even if it is just a short one.

Finally I found the time to start the actual implementation of Game Tower! It felt really good to finally create a new project and folder structure in Perforce (Yes, Perforce. I prefer it over Git.)

It will be fun implementing the functionality as I have written it down in the design document. Since the major design work is done, I should be able to focus mainly on the technical side of everything.

Unity Logo

For the implementation of Game Tower I chose the Unity engine. I don’t know it as well as I do CryENGINE yet, but I have worked with it before on two other games (Boob Rescue was made with it as well).

I think Unity is perfect for this game, because I can easily get the game to run on both iOS and Android (and Windows Phone – as per special request from a friend). And it is so ridiculously fast to do anything in this engine that I find myself moaning every time I have to do anything in any other engine now.

Since Unity has just released their new GUI system, I want to use that for Game Tower. I have previously used NGUI, and the base of the new system was written by the same guy, so I expect good things.

 Enough for today, I will post more soon.

Dev Update #7 – How to Balance a Game – Part 2

While Part 1 of this article explained the basic methods of game balancing, I now want to apply this to an actual game. By the way, if you are interested, I shared the spreadsheet from part 1 on Google Docs. You can find it here.

It’s time to run a first balancing pass over my game design for Game Tower. This will be fun! I feel much more comfortable creating formulas, tables and spreadsheets than creating art. Numbers are my friends. A woman with glasses has her hand on her hips and says: "I'd like me some 3.14159"

In the last week I created a ton of spreadsheets and graphs to tell me if my numbers are reasonable. I will pick two of these and present them in (some) detail here.

Does leveling up punish the player?
As a player levels up in Game Tower, more complex games can be produced. A higher level game takes longer to make, but will also pay more. But will it be enough?

My main concern was that it wouldn’t pay off for the player to create higher level games. If the longer work time didn’t pay a lot more, players would want to stay at a low level as long as possible. Leveling up would feel more like a punishment than a reward. What a perfect opportunity for some pre-implementation balancing! So I created a table that listed the time it takes to complete a game production and the money the game would make in relation to this time.

I work with undefined units instead of actual numbers. This means 1 Work Time unit will give me 1 Money unit – without specifying how many minutes or dollars that actually is. In the final game one time unit might be 15 minutes, and 1 money unit $7. For the math to work out, it doesn’t matter! Once the balancing is right, the resulting functions will work with any numbers I throw in. 🙂

I already knew what to expect, but to check my theory (and to be able to present it here), I started out with a simple linear relationship: 1 time unit would pay 1 money unit. At first my spreadsheet looked like this:

The graph shows that the payoff is perfectly linear to the work time. If the work takes twice as long, the payoff will be twice as much.

The graph confirmed what I already knew, a longer production time wouldn’t pay off (the blue and the red are overlapping perfectly). I needed a non-linear relationship between the work time and the money payoff.

So I added a third column to my table, which would contain a growth factor for the money payoff. In simple words – the more time a game required, the more each individual time unit would pay. I found a curve that would make a longer game production not only pay more, but a lot more than a lot of smaller games. This way it will always be beneficial for the player to level up to be able to produce more complex games for a bigger payoff. Here is the table:

A graph showing the non-linear relationship between work time and payoff. The payoff increases exponentially with the time spent working. If the work takes twice as long, the payoff is more than just double.

The new graph shows how the red line (money payoff) is increasingly moving away (up) from the blue line. The result of this balancing is a simple formula which I can implement inside the game’s code to calculate how much money a game will make, based on how long it took to create it.

By the way, this problem can not be solved by simply increasing the amount of money that a time unit will pay. Any linear relationship between money and time would yield the same result. If 1 time unit paid 5 money units, it still would not make higher level games more profitable.

Why? Here is the explanation:

Linear:
In a linear relationship between time and money, each hour of work will yield exactly the same payoff. If I get $1 per hour, it doesn’t matter if I produce ten 1-hour games, or one 10-hour game. The payoff at the end would be exactly the same: $10. Increasing that factor does not change that truth. It doesn’t matter if one hour pays me $1 or $5 or $10. It will never make a difference, the payoff will be the same for both scenarios.

Non-Linear:
In a non-linear relationship the amount of money an hour of work will pay is not fixed, but defined by a formula. The more work a game requires, the more each individual hour will pay.
Example: A game that takes 1 hour to complete, will pay $1 for each hour. But a game that will take 10 hours to complete, each hour will pay $2. Which means, if I make ten 1-hour games, I end up with $10, but if I make one 10-hour game, I end up with $20! In both cases, I have worked 10 hours, but the higher level game pays twice as much!

Result:
This is the formula for my work time payoff:

Formula: Money = WorkTime * (1 + WorkTime/100)


Instead of one formula, you can use multiple
One size doesn’t fit all, and that is true in balancing as well. If a balancing formula is great for part of the problem, but not for all of it, it might still be usable.

I ran into this when balancing the prices for building new floors. I wanted the cost of a department to increase with each floor, but wasn’t sure by how much. I started out with simply increasing the price by 50% each time the floor was built.

Following this formula the first Code department might cost $10, the second one $15 and the third $23 and so on. I get a small increase early but a steep increase in prices later in the game, which will entice players to build different departments instead of building the same one over and over. I put this into a spreadsheet and let the table figure out the build costs for building the same floor 50 times to verify my idea:

The graph shows the building cost increase exponentially. It doesn't rise much at all at first, and then rises super fast and super high.

For the first 25 floors, the prices looked OK. But after that the departments became much too expensive (as you can see, they literally went off the chart 🙂 ). But there is no reason I have to stick to this formula for all floors. Once the numbers get too large, I can switch to a different formula:

The graph shows the building cost increase with more moderation. It doesn't rise much at first, and then rises linearly and constantly.

The red line represents the discarded previous formula

The graph looks a lot better now, with the right half of it increasing steadily and linearly. The graph still goes off the chart – but in a much shallower incline. And while my table calculates the cost for 50 floors, I actually consider everything above 25 as late-game. If I get to build more than 25 floors of the same type in my tower, my tower is easily over a 100 floors tall in total.

In this case I went with the 1.5 exponential increase for the first 25 departments, and then after that switched to a linear function, to keep the increase in price reasonable.  I also went through the table and manually edited the prices for the first 25 build levels, using the calculated prices as a guideline, but rounding them to a pretty number. $5023 would be rounded to $5000 and so on.

My game is now reading those numbers from a hardcoded table for the first 25 build levels, and will switch to a linear increase function after that. The function that implements this is only a few lines long, since it only has to look up how many floors of this type exist, and then decide which pricing model to use.

The hidden Spreadsheet
I am cheating a little bit by ending the blog post here. There is a third spreadsheet that I haven’t mentioned yet and am not going to. This sheet takes the data from the two tables I discussed above and combines them. It can give me information about how long it would take a player to earn enough money to build the tower to a certain height.

This spreadsheet is my reality check. While the numbers are only an estimation (every player will build different floors and the order in which they are built is important, too), it can give me a sense of whether my values make sense or not. I will have to play the game to see if the mathematical model actually holds up.

I chose not to discuss that final spreadsheet here, because it would blow up the post even more – and there really isn’t any more to gain from it. It is more of the same: A table, numbers and graphs. Massage the numbers until the graphs look pretty. 🙂

Now the implementation begins!
Stay tuned for some first look screenshots!

Breasts? No thank you!

Maybe I should have just made a game about candy pieces. It would have been a lot easier. Calling my shiny, colorful puzzle game ‘Boob Rescue’ certainly made things a lot harder than they needed to be.

Screenshot of the game boob rescue. A puzzle game with crystals.

I think it’s great when developers create post mortems about their released games and I have always wanted to do the same. At the beginning of October I released my pink puzzle game on the Google Play Store. Boob Rescue hasn’t been on the market long enough to really gather relevant data in terms of download numbers or revenue, but I will post those at a later time. Today I want to write about the development of the game, which deserves its own post.

What I learned during the development of Boob Rescue in the past few months is that making a game about breasts is anything but easy.

Breast Cancer has to do with breasts, but it isn’t sexy.
Although these days the display of female breasts seems to be socially accepted for purposes of advertisement or promotion of goods and services, making a video game focusing on the female breast is still a challenge. Boob Rescue has nothing to do with sex, pornography or anything else the game’s title might suggest. It is a game about breast cancer with the goal to raise breast cancer awareness. That is a good cause and should not create any problems, right? Well…

A pink ribbon, the international symbol for the fight against breast cancer.

The idea for Boob Rescue was born in ‘Pinktober’, the breast cancer awareness month where everybody is happily and cheerily celebrating the fight against the disease. Pink t-shirts and fund raisers are omnipresent each year during October, and this year, I wanted to join the cause. Making a cute little mobile game dealing with breast cancer to raise funds for breast cancer research with in-app purchases was my attempt to support the fight.

I felt that I would be the right girl for the job: I am female, an experienced software engineer, and I have a personal connection to the subject matter. My mother battled hard with breast cancer and almost lost the fight. She had to undergo a very aggressive form of chemotherapy and lost one of her breasts. Somewhere in the back of my head lingers the constant fear that one day I might get hit by the disease as well, just because I might have inherited some of the wrong genes.

What better way than to combat that fear than to make a game that lets players ‘puzzle against breast cancer’!?

Not much ‘boob’ left
Well, let me tell you, now that the game has been released, there is not much ‘boob’ left in Boob Rescue. The first thing that died were the physicalized 3D breasts which could be touched and scanned in order to detect dangerous lumps. This was really the coolest feature of the game and has now been replaced by a simple 2D scratch-off style puzzle.

It is sad because the underlying tech prototype had worked really well and made great use of the multi-touch ability of modern tablets. It had a custom animation system with realistic surface deformation, using both blend shapes and joint animations. I even dare to say that this would have been one of the most realistic physicalized breasts you would have gotten on a tablet.

A screenshot from the game Boob Rescue. It shows an cartoon X-Ray of a woman with two tumor cells in her body.

However therein also lies the problem, since Apple or Google will not approve anything for release in their stores which even remotely features ‘bouncing’ breasts, no matter how far away the content is from any sexual reference.

It’s not that I can’t see where they are coming from. Even though the gameplay focused on detecting lumps and learning about breast cancer prevention, it isn’t hard to imagine that in the hands of teenage boys those wobbling 3D breasts might be used in ways not quite intended by the designer. 🙂

Breasts are fine in ads, but not the other way around
Even after removing the most loved feature of the game and replacing it with a more ‘safe’ 2D alternative, things didn’t go smoothly from there.

Since the game was free I wanted to bring in a bit of extra money by placing ad banners in the game. After signing up with one of the biggest ad networks out there it only took a couple of days to get the game banned from their network due to its ‘inappropriate’ content. Again the name ‘Boob Rescue’ was hurting the game, since something that is called Boob Rescue must clearly have some pornographic/sexual content, right?

My emails asking what exactly was inappropriate about the game never got any replies. It needed several attempts, a rework of the game’s logo and artwork to finally get signed up with an ad network without getting kicked out again.

Marketing
Next up was marketing. Everybody familiar with the mobile space knows that without marketing it is very hard to get noticed among all the hundreds of games released every month. One of the greatest things about Boob Rescue is that a share of every in-app purchase will be donated to breast cancer research. The more players spend in the game, the more funds for breast cancer research will be raised.

My plan was to get involved with the most popular breast cancer charities and try to get their help to promote the game on their social media accounts and in return it would (hopefully) generate lots of extra funds for them. I was even offering to guarantee a certain amount of donations, and pay for it myself, should the game fall flat. Everybody wins, right? Again, things proved to be a bit more difficult.

I have not yet found anyone who wants to partner with me and promote the game. I was turned down due to ‘contractual’ reasons or told that this isn’t really a fit. Do games and breast cancer not mix well? I don’t know if people found the two years my company has been in existence as too short to bear credibility, or if they found the whole idea of making a game about breast cancer too dubious. At this point I decided to just release the game without any support and see where things are going. I figure I can just donate the money anyway, without an official partnership.

A screenshot from the game Boob Rescue. A female surgeon getting ready to destroy the tumor.

Boob Rescue has since been released for phones and tablets, just in time for this year’s Pinktober. The game is out on the Google Play Store now and has not yet been banned, so I guess it will stay there for good.

I also submitted the game to Apple’s AppStore but there has been no approval yet. At the time of writing, it has been in review for three weeks, more than twice as long as the average review time. In my mind I am speculating wildly about what’s causing the holdup. I hope whoever is reviewing it doesn’t just look at the title and then rejects the for ‘sexual content’ without ever opening the app.

I never expected Boob Rescue to make millions. I just didn’t expect it to be this complicated.