Hey everyone! Super excited about Gravity Grid being in the polishing stage of production. It was suggested to me that I should ship it as-is and make changes as they come, but I’d like to dot a few more I’s and cross a few more T’s before I make it officially available. Until then, though, I figured I’d give some backstory and a few updates.
I’m also working on a cool landing page to get Gravity Grid information out there (and to design some fun marketing campaigns, especially for our Early Turkeys!). Speaking of information out there, we DO have a new mailing list tool online, and you’re free to join and become an exclusive Early Turkey. Check it out!
Anyway, I hope you enjoy this exciting history of Gravity Grid along with some ideas for the future.
Evolution of Gravity Grid
I remember when the idea for Gravity Grid came into my head. I was running through Bidwell Park and had Ingress, an augmented reality game, pulled up on my phone. As I was running and hacking portals in the game, I thought that it would be really fun to design a game where the player was communicating with some sort of unseen entity and charged with saving the universe. The idea sort of simmered in my head and I remember the first iteration of notes about what would eventually grow up to be a real game.
Probably the most interesting aspect of the birth of this idea was how much of the initial notes I scrapped. Originally the user’s device was supposed to be a special transmission hacking device that could decode transmissions. These transmissions would create parts of a level. These parts would be used to complete the levels in question.
It was a really convoluted concept. I created a demo that allowed you to collect transmission fragments, decoding them from outer space, and then using the results to feed a playing screen where you could then use said fragment data. As I developed the playing screen, though, I remember realizing that the whole decoding-transmission-fragments thing was not that exciting, so I dropped it and went all-in on the grid system I started creating.
In the notes above you can see that I had played around with a few version of the grid values. I settled on prime numbers after I came up with some mathematical proof while eating lunch one day. (The proof I came up with basically says that a^(p1)+(a+1)^(p2) = P (a prime number). In other words, any number a raised to a prime number added to a+1 raised to any prime number will always = a prime number).
The first prototype I created was stuffed onto my old website (back when it was on github). I had a whole Alpha Feedback release page setup, which was poorly written, rushed, and frankly, not very good. What I did like about this, though, was that I got a handful of people to play the prototype and affirm to me that this concept was 1) playable, 2) enjoyable, and 3) expandable.
One thing about this prototype that I think was really important was that I stuffed the gameplay mechanics into the game as quick as I could, without worrying too much about graphical representation. If the game was fun the play with shitty assets, then I knew that a more polished version was going to be successful. Time and time again, people would play this game with its garbage assets and tell me that it’s something they would definitely like to continue playing.
Still, three things were scrapped from the mechanics as I moved forward. The first was the concept of in-game currency, which I called “dark matter” and is represented by the bright circles at the top of the screen. Basically, every time you failed to complete the level in the # of moves you are provided, you lose a dark matter point. After losing five dark matter points, you have to wait until you have at least one more to continue playing the game or you could buy more dark matter points. This was one of those “capitalize on player frustration” revenue models and I hated it with every fiber of my being, so I removed it entirely. I got rid of punishing players for going over the number of moves given in each level and converted that to a Par value instead. Try to beat the level at or under par, but it’s okay if you go over.
After removing the dark matter and the moves left, I realized that a lot of the play testing that was going on focused on tracing the screen to try to match up the column and row values. What I had thought would be an essential aspect of gameplay turned out to be a frustrating reminder of why it’s so difficult to build a game with your door closed: not everyone sees a game the way you do, and what may seem like a simple concept to you may be an insurmountable obstacle for someone else. It was pointless to not know the value of the tile (I mean, the game wasn’t about finding values of tiles, it was about solving the puzzle!) so I scrapped this, too, and just added the tile values to the actual tiles.
After working on it here and there for about a year, taking a couple-month break as I finished up a large project for my PhD and published Burrow, the game has turned into a much more polished, much more fleshed out version than the alpha prototype:
And even now in the polishing stages of production, the game continues to grow up:
A good story is important to me. I think even the most minimal game could benefit from at least some attempt to suspend disbelief and engage the player with a storyline. For Gravity Grid, it goes something like this:
In three months, the universe will implode.
An ultrastar will collide with a black hole, causing gravitational tidal waves to pour out from the center of the impact and ripple through every nearby galaxy. This will cause a chain reaction of gravity implosions, eventually swallowing up everything we know (and have yet to discover). The only way to prevent it is to realign the planetary systems around the ultrastar so that their gravity fields lock in and contain the implosion.
We know all of this because scientists from the future have brought us the only tool that can save us all: the Gravity Grid. It seems like a simple app on your Android device, but it’s actually a highly complex nano-dimensional wormhole manipulator.
To stop the universe from imploding, use this app to solve the gravity grid puzzles in each of the one hundred planetary systems surrounding the ultrastar.
Solve the puzzle, save the universe!
That’s the Google Play store description that I’ll be working with on launch day.
Pricepoint and Market Research
I went back and forth on cost for a long time. My gut says that selling this game for $0.99 was the smartest thing to do. No In App Purchases, no ads, just a game for a dollar. Of course it would sell, right?
As it turns out, the mobile gaming market has come to expect a lot of stuff for free. What’s actually surprising is that consumers have come to expect advertisements in mobile games; the average person downloading your game for free from the app store probably doesn’t mind a banner ad that is unobtrusive or even integrated into the gameplay experience.
I don’t like in-app purchases, I don’t like ads, but at the same time, I want as many people to play the game as possible. I just don’t see how I can achieve that goal without making the game for free, and the only real monetization model available if I’m not offering in-app purchases is to support it with advertising. That means I’m going to have to ensure that nothing is compromised in the game by having a banner ad on the bottom of the screen.
After spending some time integrating AdMob into the game, I’m confident that an ad-supported version of Gravity Grid is not going to detract from the puzzle-solving experience. I’ve play-tested it with a few people who agree: the ads are what they are, ads that would be present in any number of other programs that other people use for free. The largest hurdle, then, has been convincing myself that having an ad-supported game out there is ok.
For mobile games, constant updates seem to be something that always entices people. Unfortunately, I think it is also creating a climate that encourages novice developers to just get stuff out there and then update it later. This does happen, believe it or not: people rush to production and stick something in the app store that is prone to crashing. That’s a mistake! Slow down, take a breath, and take some time to make sure your product is polished and as good as it can be before publishing.
The launch strategy for Gravity Grid is centered around hyperlocalized social media engagement. We’re in a lot of gamer groups where the target demographics center around parents and other people who have lots of time to play games on their phone (while they wait with their two younger ones while their oldest is at dance).
Other than social media campaigns, we’re really just building a word of mouth campaign to drive it all home.
Future Direction, Development Ideas, Etc
Gravity Grid has such great potential to offer hours and hours of puzzling fun. Future updates that I have thought about include:
- Packs of new galaxies, complete with new planet types and other fun modifiers
- Asset changes (e.g., a Christmas version where you are moving ornaments around on a Christmas tree)
- A more robust scoring system (instead of just Pass/No Pass)
If you have any ideas, please feel free to share them with me. Once Gravity Grid hits the marketplace, I’ll be scheduling regular update meetings to at least consider adding something new every month or so. I think it’s important to keep offering levels and new mechanics, because that’s what makes this game so fun. I look forward to people having this game installed on their phone, having them play for a long time and beat all the levels, and wait anxiously for the next galaxy pack!