Get it here

I’ve been working on this game for nearly 16 months now and if feels great to have the game out there.

So what now?

Well now it’s up to the app to do the rest right? NO. Now is that crucial moment when you really need to hit it hard. Send out another email to those press contacts and let them know. Send it to your friends, family, estranged relatives, that one guy from that one time, and everyone else you see. Yes, being featured or editors choice in Apple will help, but it should never be counted on to happen. If you want your app to gain visibility, then go and make it visible. I know (like me) you’ve been telling everyone about it for the last 6 months and you’re ready to sit back and soak in the praise. Too bad. Get back to work! Any experienced developer will tell you, just because the app is released doesn’t mean you’re done. Quite the contrary, you’ve only just begun.

But seriously.. please download my game. It’s fun.

Opportunities multiply as they are seized – Sun Tzu

As part of the program the find folks over at Glitch have provided me with an All-Access pass to this years Game Developers Conference (GDC) in San Francisco. I’m super excited to attend, and extremely grateful for the chance to meet other developers.

So if you’re in the San Francisco area, or attending GDC yourself, please feel free to shoot me a message and let’s chat. The best way to reach me is twitter @AndyJamesAdams. I will of course have the most recent version of Unmatch with me if you’d like to give it a try (I’ll probably force it on you anyway).

If you want to try the game on your own device, (attending GDC or not) please let me know. Unmatch is currently in the TestFlight system for iOS. So if you’re into playing games that might have bugs, or getting in on that “before it’s released” crowd, shoot me a line and I’ll see what I can do.

Thanks for reading!

TLDR: I’m going to GDC. I’ll have my game with me. If you’re interested, Unmatch is in TestFlight beta.

Before the show
Leading up to the con, I was a little nervous and had lots to prepare. I started by making a list of what I needed and scraping everything I couldn’t afford. I decided I wanted my table to be very minimalist, to mirror the feeling of the game. The list was actually fairly short: Business cards, signage, playable devices, and power solutions. To start I had my business cards printed, but was not impressed with the results so opted instead to do them myself. While these home-printed cards were not extremely professional, I didn’t hear anything terrible about them and saved alot of money. I opted to print a single sign to hang behind my table at the con. I whipped up a nice poster design and shipped it off to Walgreens for printing. My local shop got it done for me in an hour and it turned out great with nice bright colors. With signage and propaganda out of the way I needed devices for my fans to play on. I already owned one iPad for testing, and opted to purchase another. This was the single most expensive part of the entire process. For power solutions I simply took an extension cord and power strip from my house.

At the show 
I got to the show at 8:30AM (Doors opened to the public at 10AM). I quickly found my place and began setting up my area. I was setup by the door to the games room, which I thought would be a great high traffic area. All of my cards, poster and devices were ready to go by 8:45AM. Arriving early gave me a chance to see some of the other areas of the convention, and a great chance to meet my booth neighbors. The show started off pretty slow with people trickling in before noon. Then my convention issues began. Having the devices constantly on and brightly displaying my title screen for hours was beginning to wear down the iPad batteries. I could tell that they would not make it all the way through the show without a chance to charge. I was not concerned as I had brought charging cables, but while the cables were connected the iPads would not rest on the stands I brought. Then I realized that having them connected to power would prevent them from dying,but they were not charging. My app was drawing too much power being constantly on, and plugging them in was only delaying the inevitable crash. While dealing with this problem, my bladder came to call. It struck me that in all my wanderings I had never located the nearest restroom. Luckily one of my booth neighbors was willing to watch my equipment while I tended to my humanly needs. After returning I decided to simply remove the stands for the iPads and let them rest on the table. While not as eye catching, at least my devices wouldn’t die. In hindsight I should have tucked one away to charge, and then swapped them later.

As the patrons went to lunch I took the chance to do the same. Again, a booth neighbor watched over my stuff, and I went and grabbed a sandwich. So my iPads were still working, I had eaten and taken care of my natural needs. The early afternoon was going fine, but I noticed that my table wasn’t generating as much traffic as some of the other developers. I mentioned it to them and they gave me the best advice of the show. While the door area was a high traffic area, it was dimly lit, and people had already committed to exiting / entering. They recommended that I talk to the convention people and move my table to a better lit area. They also pointed out that several of the other games were making use of larger screens, and grabbing a lot of attention. If I wanted to boost traffic, I needed to try and place myself within that line of sight, or as close as possible. I moved my table to a better lit location, and the results were almost instant. I had seen a few patrons of the show pass by my table two or three times in the past, and now they were at my table and loving the game. By 4 o’clock in the afternoon I had doubled my traffic, and visitors. As time wound down the show floor emptied and I sighed a great relief. I had made it (semi-successfully) through my first convention. It was a great experience.

What I learned
Location, Location, Location. While you may not always have a choice in the matter of where your display is, you should try your best to identify the actual high traffic locations of the show. While some of this choice depends on the space itself, it is also affected by the other games and booths around you.

Be prepared as possible to adapt. While I had charged my devices ahead of time, I did not bother to check how long the charge would last. Make sure your devices and hardware are up to the challenge of an all-day play session before you get to the show.

Solo is hard. If you can, bring someone with. While I had family and friends in town, I was very lucky to have understanding and helpful booth neighbors to help me out. If you have to solo it, make some friends and hope for the best.

Be attractive. I think it goes without saying that you should take some personal hygiene time before the show, but I mean this in regards to your booth. People are attracted to larger screens, and brighter displays. Try and maximize your physically visibility.

Be grateful. Thank your patrons for their time, and playing the game. Several times, I would say thanks to otherwise mute players, and it would strike up a dialog with them about the game. It’s humble, polite, and opens some people up for feedback.

Costs
In the interest of being open to fledging developers I’m going to share some of the financial stuff. All of these prices should be taken with a grain of salt (YMMV), and are in USD. If you have someones couch to crash or can room share the prices will adjust. I also bought an iPad so my numbers are quite high.

Gamers Rhapsody Booth Cost -$75 (2 badges/table/and power cost included)
Poster Print (Walgreens) -$31
Business Cards (Home printed) -$13 and some ink
iPad Air 2 -$450
Hotel stay -$89
———————————————————————————-
Total: $658
Total without iPad: $208

Conclusion
Gamers Rhapsody was a great opportunity, and I will be repeating my attendance in the future. While it is not on the scale of GDC or PAX, it was a great convention. I learned tons, and got some great opportunities to network with other nearby developers, fans, press, musicians, and organizers.
If you did attend, thanks for coming. If you couldn’t make it this year, please keep it in mind and I hope to see you there next year!

Special Shoutouts to the folks that helped me:
@untiedgames
Escape Industries
Evva, Nicolaas, and Katie over at Glitch
And the staff and volunteers of Gamers Rhapsody!

“It’s a big table full of translated commonly used terms for game devs.”

I was immediately intrigued, and wanted to know where I could get a copy of this asset. I was shocked again when he told me it was free. I went home and researched (Googled) the project. What I found was nothing short of wonderful. See for yourselves here: POLYGLOT — It was as advertised, a large spreadsheet of generic game terms translated into a bunch of languages. The front sheet of the site gives you all the details on it’s founders, how to contribute, best practices, and licensing (CC0).

I was also impressed to find an already built plugin for Unity (my preferred game engine). Here is where I personally hit some snags. I’ll go through them with you now in case you find yourself in a similar situation.

First was that I needed to find a font that supported multiple language characters. Not all internet downloaded fonts, or even system pre-installed fonts, support languages like hebrew, bulgarian, or russian. I found this font which came with support for 25 of the Polyglot language characters. It also fits into the design aesthetic of my game, and is free to use for commercial purposes. So, now I had a decent font.

Then for every Text UI item, TextMesh, or GUIText that you have you attach a localizing script. You give that script the key from the table that you want to use such as MENU_LABEL_PLAY. This will then convert the word “Play” into whatever language the player selects. In the package they make use of a dropdown menu to let the player pick a language, but since I don’t want that in my game I modified it a bit.

Unity’s Application.systemLanguage method works natively with iOS to determine the preferred language of the device. Using that method I grab it from the users device and then tell the Polyglot plugin which language to automagically switch to. Here it is on the splash screen being tested in Russian on my iPhone.

It took roughly 4 hours and some minor tweaks and I had localized my game in 25 languages. The Unity plugin also downloads the most recent version of the Polyglot csv file when you start the game. This means that as the table grows, and corrections are made, your game will adapt. Adaptive Open Source Localization…genius. If you’re not connected to the net, it simply uses the last updated csv.

Conclusion:
Polyglot is an awesome tool for developers with a minimal or no budget for localization. What are the drawbacks though? For one, you’re at the mercy of the internet to provide translations that won’t insult someones mother. There is also the lack of customizable terms, but for my purposes it works perfectly. The overall scores hit as follows:
Polyglot 10/10, would recommend, I’m recommending it right now.
Polyglot Unity Asset Package 9/10, had to add my own auto detection. Still awesome!
Kevin Harris 12/10, would talk to again.

In Unmatch, (my soon to be iOS game) all the levels are made entirely by hand. While it seems the rest of game development is moving towards procedural, or semi-procedural gaming, I have chosen to hand craft my levels. There are several reasons that I made this decision, and it was not an easy choice. I started in the beginning attempting to at least automate either the generation or solving portion of the game. Meaning that the game would generate puzzles for me to solve and review, OR I could’ve made the levels by hand and let the computer find out if there was a viable solution.In this post I’m going to let out the dirty secrets on how I originally hand made levels, and what has changed. I’ll also outline why I chose to DIY (do-it-yourself) all the puzzles in my games.

The original process was to create a level by hand inside the Unity scene view, and then output the level code to the console. Then I would copy-pasta the level code into the game for a particular level. This meant building levels that were pretty and hoping they had a viable solution, or building a solution and then jumbling everything up so it “hopefully” looked pretty. Not the best method, since it meant moving the tiles by hand inside the editor. There were several times that I started from a solution, jumbled the map, and then forgot the solution and couldn’t solve my own puzzles.

The paper process, was a period where I hand drew puzzles on paper. This meant using half the sheet for a solution, and then using the other half to draw the same tiles in a different pattern. While this was pretty fun and exercised my brain quite a bit, it had it’s own issues. Mostly when it came to some of the later challenge types, and determining accurate move counter estimations. While this was fun and crafty, I then had to transpose this new map into the computer anyway. It made the whole development cycle seem less fun and more data entry.

The new process! I spent some time actually building in an editor. That’s right, Unmatch has an in app level editor. It was and is the best solution. I can build new levels anywhere I can use my iPad. I click away on the tiles and can start from a solution, or from something pretty. I also added code that requires that I playtest the level and confirm a solution before sending it off to be copy pasta-d into the game at my home computer. It’s such a lovely tool that even my wife (Playtester #1) has made a few levels. My 3yr old son thinks it’s fun too, but I wouldn’t call what he’s making puzzles. He thinks it’s a drawing app, and to a degree he’s right.

Below are a couple screenshots of the parts and pieces that work inside of each tile, and the settings inside the inspector that drive the graphics and functionality of each one.

Now onto the pros and cons that I weighed in the decision to make my puzzles by hand. It was not an easy decision, and I’ll admit that I’m still not persuaded to add in automation of some kind. For now here is my list/reasoning. Feel free to disagree with me on any of these and leave me a comment.

PROS:
1: Quality – Each puzzle is crafted to a level of difficulty and beauty of my choosing. Some make sense, and some are pure logic.
2. Timing – Building the advanced AI required to build even moderate quality levels, or to solve them would quadruple my development time.
3. Complexity – An AI capable of handling all the many tiles and layouts would dwarf my game in terms of code complexity.
4. Playtesting – If it’s computer made or hand crafted, players are the ultimate judge of quality. It’s easier to adjust how the gameplay evolves from user playtesting if it’s hand crafted. (At least I think so)

CONS:
1. Quantity – Hand crafting takes more time. More time per level means less levels in the long run.
2. Post release time – Unless I have a nuclear arms size stockpile of extra levels, players will eventually get to a point where they have to wait to get more after release.
3. Human error – I am human. I will mess something up. That’s not to say that an AI is not without it’s faults, but that is also mostly due to human error in it’s design.

Conclusion:
For the time being Unmatch will contain handmade levels. In the beginning I had a grand idea of releasing the level editor to the public and letting people share their puzzles with each other. This may still be a reality but ONLY if it can be presented in a clean and clear manner.
Ultimately letting the user generate there own puzzles would solve the quantity issue, but that leaves quality to the individual, and there is no guarantee that puzzle players want to be puzzle makers.

The chart above shows 2 stats for each level played, the number of players to pass each level, and the number of times a player has failed at each level. So what can we see from this data? The red spikes tell me that users are having a difficult time passing certain levels, and an easier time at others. The steady decline in blue lines tells me two things. The first is that more players have started the game, than ones that have finished it. Secondly, that as each red spike occurs (challenging level) the number of players continuing to play drops a little bit. These are expected results though, honestly. The game is supposed to become more challenging, and not everyone is going to finish it. So really all this chart does is confirm what I expected, and tells me that I need to adjust the pacing of my challenging levels (also that level 74 is a beast). Onto chart two then…

This chart is to compare how many moves it took each player to reach a solution (average across all players) against the allowed maximum number of moves for each level. Why do I need this data? From this data I can see wether or not a level might be too easy or too hard. If everyone is beating level 23 well under the max then perhaps it should be lowered. If everyone is getting close to the limit on a particular level I can check the fail chart and use a combination of the data to determine that the maximum should be increased. The idea is to get the average as close to the limit as possible without causing a spike in failures.

If you’re asking why I’d want to close the gap between the two points, I’ll tell you. Have you ever won a race by mere inches, or perhaps beaten a timer by portions of a second? Like a near death experience, the “Near failure experience” causes tension, and excitement. Narrowly defeating an opponent releases more endorphins, and provides a greater sense of victory then simply crushing an enemy. Don’t get me wrong, there are times that beating a level by a huge margin makes you feel like a boss, but I’d like those kinds of wins to be more of a rare reward then accidental occurance. It all boils down to pacing the challenges of the game, and the rewards to the player.

ISSUES-
So what makes this data less reliable? As I stated earlier, such a small sample size means I could be looking at a series of edge cases and my target audience is nothing like the data here. Also, The data for moves-to-completion is built on an averaged move count. So if a player has a tough go of it, and consistently above average then they may end up failing alot. Some games will take this into account and adjust during gameplay, but (as far as I know) this is not common practice in a puzzle game. The other failing factor of this data is that it is collected during multiple versions of the game. While the levels and limits have not changed, the interaction or percieved interaction may have changed. Even that minor adjustment can give a player a different feeling about the game, which could encourage them to keep playing or to quit.

CONCLUSION-Lessons Learned
In the future I will need a larger user base for testing. I’ll also need to include a version number in the data collected. I’m not sure what other data I should be collecting, but perhaps I will also include a timing element to determine if my players are thinking through a level or simply swapping tiles at random. That is all for this weeks log, I’ll hopefully have something prettier and more exciting for next week. Turns out game development isn’t all rocket launchers and kitty cats.

This is the first entry in a hopefully decent devlog about my new mobile game Unmatch. If you’re unaware, a devlog is exactly what it sounds like. It’s a development log showing my progress regarding any of my current projects. I’m going to use tags to hopefully keep this mess some what organized. We’ll see how that goes. Anywho… let’s start from the beginning:

I was prompted by my mother in law to make a mobile game. She’s an avid fan of puzzle games and match 3 style stuff. So I thought I’d give it a shot. My first iteration was entirely rubbish. I make a basic 2D grid of square sprites, and added a match detection algorithm from the webs. To add an “interesting” feature, I made it so that you had to slide entire rows or columns to make the required matches. Like I said, complete trash. It wasn’t my best work.

After some half hearted support from my family, and general dislike for my own “game”, I took it down to a local game developers meet-up in Madison, WI. The folks who were still awake after my presentation had only one opinion. “DON”T MAKE A MATCH 3 GAME!”  To be fair, they were nice about it. The meeting organizer Aaron San Filippo game me a piece of advice that would later lead to the creation of Unmatch. He said not to make a match 3 game, but instead to think about making something completely opposite of a matching game. In custom fashion with all advice, I took it to mean what I thought he meant (probably not what he actually meant). I was still motivated to create a puzzle game, and brooded on the advice for a couple days. Then it came to me… the complete opposite of matching is un-matching. Thus, the concept was born. I took a few days and modified the slide game to see if the concept was fun.

It was terrible on multiple levels. The first flaw was that it goes completely against the human need to organize things. I was creating chaos from order, which just felt wrong. It was a mental challenge to fight the urge to organize. The second disaster was that it quickly became apparent that simply making a checkerboard pattern would solve every puzzle (see the light blue tiles above). Again I returned to brooding mode. I revisited the game a few days later, and I had revelation of sorts. My mental challenge wasn’t necessarily a bad thing. Puzzle games are supposed to be mentally challenging, right? I also realized that I wasn’t creating real chaos, but instead a sorted order to things. Sure it wasn’t pretty sorted order, but it wasn’t a random mess either. To address the checkboarding issue I thought about the core of how the comparison between blocks was made. Each of the four faces pointed toward another block, maybe I should just add more faces? Maybe less? I considered making the game using triangles, but discovered that the checkboarding was still an ultimate solution. I pondered using pentagons for a bit but decided the code to line everything up would melt my brain. Finally I settled on hexagons. The grid of tiles would stay clean, it provided different possibilities, and I thought it looked cooler. So I went to work.

I made a basic couple of levels to get players used to the idea that they wanted to separate similar tiles rather than combine them. I still think this system could use some work, but only testing will tell. The game finally felt good, provided challenge, and some juicy menu stuff made it look nice too. I felt great about the game, but the insecurities in me needed some validation from those who had crushed my previous game. I took it back to Madison. I was crazy nervous, but at least this time I was proud of what I had. It was very well received (at least I think so). Other game developers started coming up with new and interesting ways of making the game more challenging. I drove home that night with a feeling of pride and validation. The game still had some major bugs though, and I wanted to try out these new challenge ideas. I set to work fixing what bugs I knew of and adding in some of the challenges.

I continued to work on the game for awhile and eventually discovered that my games core comparison system was flawed. Rather than gut the game and try and rebuild from a cracked foundation I opted to rebuild the entire project. This also gave me a chance to consider the new challenges like split tiles, and walls while building the system. Once the new version was ready, I needed someone new to play it. I kindly requested a twitch streamer and fellow game developer William Chyr to test it. He asked if he could do it on stream, and I agreed. Willy’s community ripped my game apart, finding bugs, requesting features, and re-affirming that the core mechanic was solid and challenging. The feedback from this opportunity was priceless, and should I ever meet Willy in real life I believe I owe him at least a couple beers. To top it all off, Willy uploads his streams to youtube. Now you might be thinking this was a great way to help get the game out there, but I actually used it as a reference for making further changes to the game.

About this time, I was contacted by a cool guy named Kevin Harris. He was a little more local, and wanted to start a game development meeting in town. I was totally on board and ready to show what I had. I took all that feedback and whatever else I could get from the local group and the Madison developers. I tweaked it here, and there for a couple weeks, and finally got to a stage where the only thing left before an actual public alpha was to make some more levels. I churned out 25 starter levels and uploaded them to my site. I posted in some Facebook groups, and on Twitter to get some more of that sweet, sweet nectar we call feedback. Results slowly came pouring in and most were impressed with the games progress, and it’s challenge. My financial advisor (aka wife) let me drop some money to renew my iOS developers license. I immediately pushed the game onto my iPad and any iOS device I could get my hands on. My wife played it and fell instantly in love with the game. She has been badgering me ever since to add more levels. Since the starting goal was to make a game for my mother in law, I also pushed it onto her iPad. The two of them were talking and texting each other for days about which levels they had issues with, and solutions they found. It was great. While listening to them I could “hear” between the lines about where the difficulty curve and pacing needed adjustments.

With a new look, more levels, and a very small fanbase I decided to put analytics into the game. This would further help me to understand where the players were getting stuck and which levels needed adjustment. Now most of this may seem like something to worry about during the polishing phase of development. I however believe that it’s important to understand where players are going to have issues with the challenges I’m presenting and when I introduce them. Understanding how the players think about tile movement and such gives me a clue into what challenges and changes will result in a better play experience. It’s an important part of the game, and I want to get a jump on it as early as possible.

CONCLUSION (finally, right?)

Currently there is a playable demo of the game on my site:
http://www.jdamsgames.com/Unmatch
While I continue to improve the game and try out new challenges, I’d like to make these posts more often. Hopefully once a week at least. I will try to make them shorter in the future, but with so much personal excitement about my game I make no guarantees. Currently the game is in Alpha version 0.10, and will be going with me to tonights development/playtesting meeting. I’ll be taking it on the iPad for the first time so we’ll see how the platform changes opinions and feedback.

Thanks for reading and for less verbose game updates you can follow the game on Twitter here.