Apple Featured My Game, Here's Why I Changed It
zervaas.com.au
zervaas.com.au
Before Google switched over to Wallet and allowed responses to reviews, you could get a fair bit of info about each sale (for a paid app), including often their email address.
I would often email people seeking clarification when they would review "XYZ doesn't work for me" in a bid to fix it.
On one hand it might seem a bit creepy, but on the other hand, they were my customer and I was provided with information about them. I never asked for a better review, just for information to improve the product.
They rarely replied.
Developers shouldn't be so concerned with reviews. Reviews are for other customers, not for developers to read. I say this as a developer who has received reviews that contain misinformation about my product (lying that it's going to be pulled from the App Store, for example). I made a decision to stop reading reviews and just focus on building something I'm proud of. This has paid off for me.
I also make it easy for customers to email me directly in my apps. I get a lot of good feedback this way — and I can send a response that is actually solicited.
I'm the same though, completely averse when it comes to looking at reviews, good and bad. I hate it.
Your last point is really good, I've always thought there should be super easy mechanisms like this (although I'm often guilty of not providing, aside from email address or Twitter handles).
The Google Maps feedback mechanism works really well - includes a screenshot and a bunch of diagnostics info. The only thing I don't like about it is you need to shake to trigger it, meaning most people don't know about it.
We currently have reviews implying that our dictionary is missing basic words when in fact I think many people would think there are simply too many words that are valid in English and will surprise people.
Review replies would at least improve context even if it didn't change the ratings themselves.
And note that at the end of Quentin's blog entry, there's a link to our blog series about creating the game. We've been talking to friends about the general aspects of the game so always keen to chat with other game developers and entrepreneurs about specific challenges.
What developers need to do is make it easier for a user to give feedback, than it is for a user to leave a review. Give them a way to vent to you, and they might not vent in a review.
Is this easy? No. Does it work? Yes.
Here's an example.
Referring to the "tap an empty tile to drag around" section of the post.
This step was added because a lot of our testing revealed people wanted to move around the board but didn't know how. The problem was, we didn't test that tutorial step extensively enough.
It's hard though, we're independent developers making our first game. We have limited time and limited budgets, so compromises need to be made, otherwise instead 3.5 months of development turns into 6 or 12 months.
One mistake is we talked often with our 15-20 regular testers so most feedback was confined to regular gameplay, not on-boarding.
Really need to continually bring in new people on an ongoing basis that had never seen the game before. We did this to some extent but there's always more that can be done.
That said, we would pay a lot more attention to the on-boarding next game. I was quite happy with our tutorial so it's frustrating we left holes and fell short.
As Quentin said in another reply, one big mistake we made was that a lot of testing was with a beta group that had played the game dozens of times before the tutorial was fully fleshed out. Huge mistake! Another mistake was watching someone play it for the first time where we were in a position to coach them. We should've been silent and seen what they did. Easy to spot the issues in hindsight!
Check out the 'discount usability' movement. Much of it is written for web / mobile development but the principles are pretty much universal and can be applied to both game design and/or interactive learning aids (in your case the tutorial).
If nothing else read up on how to run a usability test. Without even being an expert it will help you get much more out of your testing.
We didn't like the standard Game Center pop-in notifications, so we designed our own - these use normal UIViews, and we use the built-in Twitter/Facebook sharing view controllers.
The loading spinners, alerts / dialogs are all in SpriteKit. I'm not sure if this is optimal (I believe other developers lean on UIKit a bit more), but it all fits together nicely this way.
One of the youtube movies on your linked page is titled "Hexiled Gameplay iOS & Android iPhone & iPad HD" and uploaded by "AndroidGameTech".
But writing my own game apps, I do realize why you're not doing that when implementing games directly in things like SpriteKit.
Are they using flash ? Unity ?
The music was something we used a freelancer for, however.
Hopefully if Hexiled continues to prove successful, we're in a position to get help on the visual side!
Being the first game I've ever made I wanted something I could jump into really quickly just to play around. Got a bit of momentum on it and kept going.
I do wonder about the future of SpriteKit because of this, since having to code it two or more times is a huge effort. Apple seem to be all-in on it though, especially with SceneKit coming soon.
Here's a video from about 2 weeks into the project (it was codenamed Fractured at that time):
https://www.youtube.com/watch?v=BeMt9UJIPS0
One key mechanic in the game now that isn't in this video is the auto-panning after the user makes a word
(there's a bunch of other stuff too, like the timing mechanism, size of tiles, size of game grid, etc.., but that's more gameplay rather than mechanics)
However, my partner and I are looking at a different game right now.
Also, I know there are worse reviewers than this, but man ...
"The vocab in this game needs a serious update, I have no idea which words to go for due to the fact that it does not have some retry basic words built in. Not toention the selection process needs a tad bit rethink. Overall it is a pretty great idea, it just needs to be fully realized. I would give it more stars but I'm a pass or fail kinda guy, and this did not pass... Not yet anyway :)"
There's over 250,000 words in our dictionary (that's not to say you can necessarily make all of them in the game).
Most people just query "Zen" not being in there though ;)
It's stored in a single-table Sqlite database with some techniques to make word lookup really fast. I believe it could be faster still, but this is likely beyond my technical expertise.
Next problem is to scale the game to multiple languages without bloating the download size of the game too much. Haven't decided what's best yet for this: either compressing the dictionaries for distribution (and decompressing on first launch), or an in-game download (this seems like so much effort though and just adds more friction)
An Sqlite db sounds like the sweet spot of performance and easy of use.
Couldn't you automate the in-game download? I.e.: If the user selects another language download it on the spot with a little popup telling the reason for the delay?
- More technical debt - More points of failure - Need to host the data somewhere (plus pay for it... the App Store is basically a free CDN)
Off the top of my head, it may be possible to do a Free IAP where Apple hosts the content, but I may be totally wrong on that.
Having said that, as noted at the top of the post, at time of writing about 600,000 games of Hexiled had been played in the 3 days since the feature started, which has totally blown us away.
There's three modes in the game: Escape, Survive, Explore. The Explore mode uses a much smaller radius and no countdown, and doesn't suffer from the same issue. Instead of thousands of tiles on the board there's hundreds.
It was interesting playing with different mechanisms for drawing the tiles though. Between pre-generated letters, real-time letter drawing and everything in-between, the solution we have works well on most models of Apple devices.
Some of the issues were also with how SpriteKit did certain things (such as how inefficient cloning a text node object is)
I realised though only during Day 3 and barely had any time with them. The sessions are a small part of the week (I mean, you can watch those online at any time).