As you probably (hopefully) know by now, I released my first game Polymer about two weeks ago. In it’s first day, it broke into the top 200 paid apps, the top 100 games, the top 25 strategy games, and the top 25 puzzle games (all referring to the U.S. app store). It has also gotten a bunch of really good press.

Originally, this was going to be a post about general marketing techniques, but I found myself getting deeper and deeper into Twitter tips. So I decided to focus just on that. In a future post, I’ll explain what I did for my press release, pitch, and media relations. By the way, I need to shout out a huge thanks to my wife Dana, who has worked in the PR industry and has given me invaluable help and tips throughout this whole process. A lot of these ideas originally came from her expertise.

I honestly believe that Twitter was one of the biggest parts of Polymer’s launch day success. I want to clarify a few things because there seem to be a lot of people who just don’t understand how to use it effectively. Or why they should use it at all. In this post, I’m going to talk about a bunch of random tips for using Twitter. All of these tips are really applicable to Twitter in general, so even if you’re not promoting a game, it’ll still hopefully be useful. I can in no way guarantee that anything I suggest here will work for you. I am just going to describe the way I use Twitter and hopefully you can use find some benefit in that! Without further ado:

Develop a Good Reputation

This is by far the most important aspect of your role on Twitter. Far too often, I see people make a new Twitter account a week before their game’s release, suddenly trying to earn followers and respect. IT’S NOT GONNA WORK. Developing a solid following on Twitter can take years! “No, that’s not true,” you say. “All I have to do is follow 50,000 people and some of them are bound to follow me back! #teamFollowBack LOL” DON’T DO THIS. It makes you look desperate, and it makes people think (rightfully so) that you really don’t care about who you are following. You are broadcasting the fact that all you want is followers of your own. You are clearly completely uninterested in the community.

Another thing I see people do all the time is spam other people who have influence on Twitter. I’ll look at their timeline and see something like this:

“@notch Hey man check out my game! www.stupidUglyGame.com”
“@helvetica Hey man check out my game! www.stupidUglyGame.com”
“@MattRix Hey man check out my game! www.stupidUglyGame.com”
“@NissaCam Hey there, check out my game! www.stupidUglyGame.com”
“@Imangi Hey guys check out my game! www.stupidUglyGame.com”

DON’T DO THIS. It also makes you look desperate and like you don’t care at all about anyone but yourself.

It’s actually pretty easy to develop a good reputation on Twitter. Think of Twitter as a metaphorical room. A massive room with millions of people. If you’re in a room full of people, would you walk up to everyone you saw and say “Hi look at my work” over and over? Well maybe you would but people wouldn’t like you very much. All you have to do is hang out at the virtual party, be yourself, and get to know people. That’s it. Even if you feel like you have nothing interesting to say, it doesn’t matter. Just get to know people, be a nice person, and join in on conversations and you will gain a good reputation eventually. I’m much more likely to follow someone with 25 followers who joins in conversation, is helpful, friendly, and funny than someone who has 1,000’s of followers who never converses with anyone (or is a dick).

Getting Advice

Twitter is incredibly amazing for iterative design. For example, frequently in Polymer’s development, I’d be working on developing a new menu or game mode, I’d tweet a screenshot, and immediately get a ton of good feedback about it. After about 20 minutes of back and forth, I’d generally end up with something way better than where I started.

However, you need to be careful too. While advice on Twitter can be extremely helpful, it can also confuse the hell out of you. I find myself being easily swayed by opinions, so whoever responds to my inquiries first generally convinces me that their opinion on my design is correct. A few times I did this and later realized I made a snap judgement without really thinking. Try to take a step back sometimes, take it all in, and think about how all the opinions add up, then finally decide if it fits with your overall vision.

Followers/Following

I mentioned above that you shouldn’t randomly follow 50,000 people. What you should do is follow people you are interested in and/or people who participate in good conversation. Don’t follow every single person in the world because you want them to follow you back. Also keep in mind that when you’re following 1,000’s and 1,000’s of people, it’s very very hard to stay up to date on what they’re all doing (unless of course you use lists, but then what’s the point of following the people who aren’t on those lists?). Plus, it’s all about quality, not quantity. In my opinion, it’s much better to have 100 dedicated followers than 10,000 #teamFollowBack followers.

Getting Followed Back

First of all, don’t be offended if someone doesn’t follow you back. It’s usually not personal. Be patient and if you’re involved enough, eventually people might reciprocate.

And on that note, don’t directly ask for follows. It’s tacky. If you ask someone for a follow, it sort of diminishes the value of it, and it potentially annoys the person you’re trying to impress. There are many people who I have really wanted to follow me, but have never asked. It’s always an amazing bonus when after a random conversation, I get a follow from said person. Of course, share your Twitter handle in as many situations as possible, especially when sharing content, but directly tweeting people like “@monkeyman Hey Monkey Man, can you follow me please?” is just tacky. (I don’t know if @monkeyman is a real person, just made it up for the example. Feel free to follow him if so).

Help Others Out

Make sure you return the favor that people are doing for you by retweeting and spreading the word about their games! Don’t spam your feed by retweeting everything, but make sure you take the time to give your followers a look and spread the word about people and games that look interesting, especially if they’re just getting started.

Be Active and Responsive

Unless you are already pretty well known through other means, you probably won’t get many people interested in your tweets if you’re not active. I try to tweet at least a couple times a day (even though it usually ends up being more like a couple thousand a day). If you don’t say anything for weeks at a time, people probably won’t follow you.

Even more important than being active is being responsive. There’s not much that annoys me more than someone who doesn’t respond to twitter mentions. Obviously, I’m not talking about people who have thousands and thousands of real followers (@C418 and @Notch, for example). There’s no way they could respond to everyone. I’m also not talking about responding to every tweet. You don’t necessarily have to say “Thank you” every time someone compliments your work (although it can’t hurt!). You also don’t have to respond right away, or every time. What annoys me is when people just simply don’t respond over long periods of time, ever. There have been people I’ve asked multiple questions (not in a spammy way, just in a conversational way) over the span of a few months and didn’t get a response to a single one, even though they are otherwise relatively active.

Press

Get to know press on Twitter. And don’t do this five days before your game’s release. Get to know them NOW. Talk to them like real people (most of them are real people, after all). Again, imagine you’re back in that room with a huge group of people, some of whom write for important gaming sites. Will they take you seriously if you’ve never met them before and you just walk up to them and open with, “Hey can you write about my game? It’s fun, addictive, and totally unique!” No, they probably won’t. On the other hand, if you’ve already been talking to them about random stuff for awhile, eventually your game may come up in conversation. Or even better, if your game is in your bio, they may search it out on their own. Which brings me to my next point.

Secrecy

Don’t be so damn secretive. I know a lot of people will probably disagree with me but you’d be amazed at how much interest you can garner by sharing your game design process through Twitter. I’m not saying that you should divulge all the important details. Of course not. But post random things throughout your process. Talk about difficulties. Ask for help. Post screenshots and videos. It’s clearly working for Mojang with Minecraft, Wolfire with Overgrowth, and so many others. People are interested in this stuff, and it gives users a feeling of involvement in the game design process. Plus, it can help your fellow developers.

Another thing, mention your game in your damn bio! It’s amazing how many times I’ve looked at someone’s bio, interested in seeing what games they have made, and all it says is something like “iOS game developer”. Obviously, if you have a pretty established following, this doesn’t matter much. But if you’re just starting out, it should be very clear what your game is and how people can find it. People have short attention spans, so if they’re actively looking for your game, it should be as easy as possible to find it.

Plan out major announcements

Throughout Polymer’s development, I was used to tweeting pretty much anything whenever I felt like it, which I think is really great for garnering interest. However, when you’re dealing with major announcements, they should be planned out a bit more.

Try to tweet announcements at times when the most people are going to see it. I tend to push important tweets out late morning/early afternoon. I feel like that’s the time when I get the most retweets and responses.

Format the tweet in an interesting way. Here are a couple things that bug me about major announcement tweets:

• Try not to include “Please RT”. Instead, tweet before the announcement tweet (or after I guess) saying “I’d appreciate a RT on the next tweet.” This shows that you’d appreciate it, but it doesn’t sound as desperate, and it doesn’t clutter the important tweet with unimportant text.

• Don’t include a bunch of hashtags. Maybe I’m in the minority, but I find most hashtags to be an eyesore. I’d much rather see “Here’s a trailer for my new game Super Fat Man [LINK]” than “Here’s a trailer for my new game Super Fat Man [LINK] #indieGaming #gamedev #YOLO” or whatever. To me, it’s just clutter. Focus your message and keep it at that.

• Get to the heart of your message in as few words as possible, and be specific. I’m much less interested in a tweet like “My first game releases today. I’d love it if you checked it out! [LINK]” than a tweet like “Super Fat Man is now live on the app store. Swipe to eat burgers and tap to bake cakes! [LINK]” Keep in mind that a big benefit of getting retweeted is that people who don’t know you yet can find out about you! Try capture their attention.

Don’t be too trigger happy

It’s extremely easy to be overly trigger happy on Twitter. A week ago, I decided I wanted to end the sale and raise Polymer’s price to $1.99. So in a matter of minutes I just decided that it’s time and tweeted “Polymer’s sale ends tomorrow! Get it now before the price rises.” Furthermore, I updated the app store description and the Facebook page to say the same thing! Immediately, I got a ton of feedback from people who thought it was too early and that it would really harm my rankings. Plus, so many people told me how important it was to get as many users as possible this early on. Shit. The problem is, once a major announcement like that is out, it seems weird and quite unprofessional to take it back. But since most people said it was a bad idea to end the sale this early, I retracted. It ended up being okay, but it obviously would have been better if I had thought about it a little more, and maybe asked for advice before deciding.

Focus on launch day

This is not really just a Twitter tip. This is true in pretty much all aspects of a game’s launch. Build buzz and focus everything on the launch day. This is especially important in a low-attention-span world like the app store. If you tweet a ton of interesting stuff a week before your game’s out, I might have already moved on to a different game by the time it’s actually released. So try to save your most interesting stuff for launch day. For Polymer, I focused on April 26th so that on the day, multiple reviews came out, the official trailer was released, and Polymer’s website was announced. Try to get as many impulse buys as possible on launch day!

Follow Me

The true key to success on Twitter is to follow me: @wtrebella.

Okay maybe that’s not true, but I promise I’ll respond to you, and if you have any questions about anything, I’d be glad to answer.

Polymer is my first real game. Yes, I’ve made lots of little [stupid] prototypes in the past, but I’ve never attempted a fully polished, releasable game. Because this is my first experience going from inception of an idea to finished product (well, almost finished – I’m shooting for the beginning of April), I’ve learned a lot of programming techniques mostly through trial and error.

Disclaimer: I’m still quite new to programming so please comment if one of these techniques is stupid, unwise, idiotic, or any other adjective you’d like to use. Also, if you’re also new to programming, I wouldn’t necessarily assume everything I say here is best practice. These are just things I’ve learned by running into bugs and problems and finding ways to solve them. There could easily be better ways to do these things, but they’re all I know at the moment! Also, I’ll be writing all my code in Objective C because that’s really all I know! Without further ado:

1. Use a singleton class

People have suggested I use an Objective-C category on CCNode so everything inherits the methods rather than using a singleton. Good tip!
I’ve heard some people advise against singleton classes, but I’m not sure why. I have found it to be one of the most useful things in this entire process. Not only is a singleton class useful for global events (such as authenticating a GameCenter user, or keeping track of what items have been unlocked), it’s amazing for convenience functions that may be used anywhere. For example, I have a function like this in my singleton class:

- (void) boinkNode:(CCNode *)node;

So first of all, I know the name’s weird, but that’s all I could come up with. What the function does is quickly scales a node (a sprite, label, image, whatever) up and down very quickly. This is useful for when the user taps something. It gives visual feedback along with the audible click. When I first started making Polymer, I coded functions like this into individual classes. After awhile, I found myself recoding the same thing over and over and it was getting annoying. So I threw it into my singleton class and now all I have to do in any class when someone taps a button is something like this:

[[Singleton sharedSingleton] boinkNode:currentNode];

Very easy, and if I want to make changes to the function or to how a node gets . . . boinked . . . it’s all in one place. I don’t have to jump around my code searching for all the places I’ve used similar code to make changes.

2. Make a prototype. Scrap it. THEN make your game.

Polymer started off very different than it is today. It had many iterations before it became the Rubik’s-cube-ish, shape-forming, tile-sliding game it is now. It’s been everything from a pixelated-picture-creation puzzle game to a match-four-numbers-to-make-a-giant-number-that-has-special-powers game, and everything in between. This iteration progress was great because every time I made changes the gameplay completely changed and I could quickly see if it was going to be fun. The problem is, once I finally got through enough iterations and settled on the Carcassone-like-shape-forming mechanic, I just kept building on top of the original code I had. Everything in Polymer’s code is build upon everything I wrote when I first started the game. That code is messy, it was built on unsure ideas, it went through a ton of changes, and it just isn’t very efficient. What I should have done once I decided upon the actual gameplay mechanic is start a completely new project from scratch. That way everything would be going towards one core idea, and I could get rid of all the crazy code from the beginning of the process. Here’s an early prototype image of what Polymer once was:

3. Make abstract classes (don’t be too specific too early)

Time and time again, I have found myself running into trouble because I was too specific too early. For example, at the end of a game of Polymer, a little menu pops up. When I first coded this menu, all I was thinking of was its use at the end of a game. I put score labels, buttons, and sprites in there, with everything’s position hard-coded (which is just stupid in general). Since I wasn’t thinking about the future, I just made this menu be perfect for the one situation I needed it for at that time. Soon after, I was really pissed at myself because I realized I needed the same type of menu for when the player unlocked something. Instead of doing the smart thing and refactoring the code into something more abstract, I just kept building onto this base class in a really messy way. It went something like this:

if (menuType == MENU_TYPE_NORMAL) {
    // do stuff here for the normal end of a game
}
else if (menuType == MENU_TYPE_UNLOCK) {
    // do stuff here for when someone unlocks something
}

Now I was rewriting a ton of the code for the menu and hard coding tons of different things into tons of different places. On top of that, in a lot of methods I now had to check to see what kind of menu it was before I did anything. With just two menu types it was getting to be a huge hassle. I thought about adding a third somewhere else but it would have been too annoying so I ended up doing something else. Here’s a pic of the menu I’m talking about (yes, I’m totally aware that shape looks like poop):

Later on in making the game, I had learned the error of my ways. In making the tutorial pages, I made an abstract Tutorial class. This class had a ton of methods built in for creating many different types of tutorial scenes. All I had to do in the init method of new subclasses was something like this:

[self addSquareRowAtIndex:5];
[self turnOffColumn:7];
[self addLabelWithString:"Tutorial mania!" atRow:3];
// and so on

This made it a TON easier and a TON faster to create a lot of different tutorial scenes that were all pretty different. The three following tutorial scenes (and more) were created by making simple subclasses of the abstract Tutorial class:

4. Don’t do something just because it’s quicker or easier (it will hurt you in the long run)

So many times, I’ve thought something like this: “Hm, I can rewrite the code entirely . . . or I can just add a few variables here and patch up the problem.” And so many times I have kicked myself for doing just that. Yes, totally reworking code is daunting as hell and not very fun, but it’s completely worth it and much better than just throwing on various patches. It makes the code much more flexible, a lot easier to understand, and just more fun to play around with. Always choose the more difficult option if it will lead to cleaner, more flexible code.

5. Use the hell out of completion selectors and blocks

This is probably obvious to seasoned programmers, but it took me awhile to really start using completion selectors and blocks in my own methods. Without them, I frequently wound up in tricky situations where I wanted something to happen once something else had already happened. Without completion selectors this got to be really messy. I would have to constantly check whether something was finished in an update method, then call the next event, then make sure not to call that next event any extra times. Plus timing was an issue, and things could easily get out of sync. With the use of completion targets and selectors, things are SO much easier. For example, when I want to get rid of the menu I talked about in point 3, I can do the following:

[menu dimissWithCompletionTarget:self selector:@selector(goBackToMainMenu)];

This will make the menu move down below the screen, which will trigger the game going back to the main menu. If I didn’t do it as a completion selector, the game would start returning to the main menu while the menu was being dismissed and moving downward.

6. Plan out a class before you dive into it

When I made a new class in the past, the first thing I would do is write the init method, followed by a couple functions that I needed at the moment. Over time, I’ve found this to be a bad idea because I would always end up going back later and totally changing the methods I had already written whenever the object needed to do something I hadn’t planned for originally. Now, when I make a new class, the first thing I do is really think about what it needs to do and write the header file. At this time, I don’t care about how I’ll implement a method. I just write the methods I need, to be implemented later. Same with instance variables and properties. I try to figure out exactly which variables and properties this class will need and put them in the header. That way, I lay out the class exactly as I want it to work. Then I just need to make it work based on what I planned. Obviously changes will probably still come up but planning it out like this has been really helpful to me.

7. Write convenience methods for everything

It’s amazing how helpful convenience methods are. My basic rule is: if I need to copy and paste something for some reason, it should be in a convenience method. For example, let’s say I’m making a game where objects can turn other objects into their color if they contain them. In other words, if a blue object completely “eats” a green object, the green object will turn blue. I may write something like this:

if (CGRectContainsRect(object1.boundingBox, object2.boundingBox) && object1.isBlue && object2.isBlue) {
    object2.color = blue;
}

This will work fine when I’m checking for overlap between two specific objects with two specific colors. If I want to then check two different objects that are red and yellow, I’d have to copy and paste the first snippet of code and make some subtle changes. Furthermore, what if I don’t know which object is bigger? Then I have to write even more code to check if the first contains the second, then if the second contains the first. This is already leading to creating unnecessarily messy and cluttered code. Instead, I would make a method that checks any two objects of any two colors. Like so:

- (void) takeCareOfObject1:(Foo *)object1 andObject2:(Foo *)object2 {
    if (CGRectContainsRect(object1.boundingBox, object2.boundingBox)) {
        object2.color = object1.color;
    }
    else if (CGRectContainsRect(object2.boundingBox, object1.boundingBox)) {
        object1.color = object2.color;
    }
    else {
        // nothing happens because neither object envelops the other
    }
}

Now it’s really easy! I can check any two objects and easily have them adopt each other’s color in the right circumstances with one line of code. For example:

[self takeCareOfObject1:square andObject2:circle];

This will automatically change the color of the circle to the color of the square if the circle fits inside the square (or vice versa). This is especially useful if I have a large array of lots of different objects. I can just scan the array and automatically change their colors with this one line! Moral of the story is: always write flexible convenience functions for yourself so you don’t have to keep rewriting the same code over and over. This way is much easier to debug too, because if something goes wrong, you just need to check one spot: the method implementation.

8. Use #defines in a universal file for easy parameter changes

I have a ton of #defines in a file that all my classes can access. It includes things like “SECONDS_PER_GAME”, “TIME_BEFORE_SQUARES_DISAPPEAR”, and “POINTS_TO_UNLOCK_GAME_MODE_2″. These are extremely nice to have because they make it very easy to make quick changes to your game without having to search around the code and change all the instances of something. They’re great for debugging too because, for example, you can very easily change it so that a game only lasts 10 seconds instead of 2 minutes.

9. Encapsulate things into individual classes as much as possible

I went through the process of making one of those volume slider thingies two times: once the completely wrong way, and once in a much better way. Just so you know what I mean when I say “volume slider thingy”, here’s the end result:

The first time I made one of these sliders, I included all of its components in its parent Settings class. This made it such a hassle to do anything with it because the touchesBegan, touchesMoved, and touchesEnded methods got incredibly cluttered with code dealing with the movement of the slider knob thing. Plus, when I wanted to add a second slider to the Settings page, I had to go through everything again, hard code its position, and update the touches methods to affect that one too. It was a nightmare. The second time I created these sliders, it took a lot of preparation and work, but when it was finally done it felt like a dream. This is all I had to do to use the slider:

// in the touchesBegan method
if ([slider knobContainsPoint:touchLocation]) {
    [slider startSlidingWithPoint:touchLocation];
}

// in the touchesMoved method
[slider updateWithPoint:touchLocation];

I just fed it the touch location and it took care of the rest. It was so easy. And then if I ever needed to rework something, I could just change it in the actual slider class and everything would stay the same everywhere else.

10. Refactor bad code, no matter how hard you worked on it the first time

Quite often, I find myself adding layers upon layers of patches and bug fixes onto certain parts of classes. This process can take days or weeks to get working right. When it finally works it feels amazing. But a couple weeks later, when you come back to the same spot in your code, it’s incredibly complicated and extremely hard to make changes to without breaking again. So although it’s painful sometimes, I try to rework really bad, messy code if there’s a way to make it cleaner and more flexible.

For example, when I first implemented the color modes in Polymer, I went against my number 4 above: I did what was easy and fast. While I ended up with some pretty cool results right away, it was a huge hassle to add more color modes and there were remnants of my messiness throughout so much of my code. I really wanted the color-mode-adding process to be as easy as possible (because I plan on adding more through updates) and I was quickly running into this wall of annoyance and tediousness at having to make so many little changes and updates every time I added ONE new color mode. So I set out on a mission to make the process a lot easier. It took me a couple many-hour days of work, but I finally got it to the point where adding color modes is extremely easy. Now all I have to do is allocate a ColorMode object, feed it some colors, add it to my singletons colorModes array, and the rest of my app can now use it, such as in this color mode selection screen:

While it was a lot of work and annoying as hell to refactor, it was 100% worth it for how easy the process now is. Here are a couple color modes on the same Polymer board:

Normal

Neapolitan

Forest

Thanks for reading! Hopefully I could help some of you out (or give you a laugh if I’m doing something unwise).

My game is called Polymer. Let me explain why.

According to Wikipedia, “A polymer is a large molecule composed of repeating structural units.” Here is a picture of real polymers:

In the game, the goal is to form strands of connected units. This isn’t a match-3 game though. The units can only be connected in particular ways according to their rotations. Each unit’s rotation is chosen randomly, so you never know exactly what you’re going to be able to make. A molecular polymer’s sub-units “are typically connected by covalent chemical bonds.” In my game, each unit has a dark half-circle on all sides that need to be connected to something else to form a true bond. When a bond is found, the half-circle disappears.

To put it simply, finding matches in my game is a lot like the gameplay in the board game Carcassonne. In Carcassonne, there are many ways to match tiles together, but they only connect in certain locations. By the end of the game, you have a pretty cool looking city with procedurally generated castles, fields, roads, and rivers. I wanted to emulate this gameplay style because I’ve never really seen it done before in a matching game and I’m insanely bored of regular match-3 games.

As I said above, at the end of a game of Carcassonne, you have created a pretty cool looking city. Similarly, Polymer saves your best creation during a game so that you can revel in your molecule-forming abilities, or show off to friends. Plus, you’ll be able to Tweet your creations from within the app. Here are some Polymers I’ve made so far, from fairly simple to crazy complex (obviously, the bigger the Polymer, the more points it’s worth):

Thanks for reading (and special thanks to my wife Dana for coming up with the name)! Expect more soon.

The title screen. The UI button thingies slide to the right to open different scenes and start games. The game type names are all temporary. I’m going to try to think of better ones. The three rows of shapes slide left or right for visual effect.

The endless/survival game mode. Create matches for as long as you want, but you better match the bomb pieces before their time runs out or you’ll lose.

The onslaught game mode. Create matches for points, but don’t be too slow because the board keeps filling up. Sort of like a version of Tetris where the pieces appear in random places instead of always from the top.

Keep in mind that “Myto” is just a temporary name because I thought it sounded kinda cool. It probably won’t be what it’s actually called. It’s basically a bastardized, shortened version of “Mitosis.” I’m still brain storming about names, so let me know if you have other ideas!

The gameplay is like a mix of Bejewled and Trism. You slide rows and columns to try to make matches. But instead of matching colors, you match sides to each other. The goal is to complete a shape without any unmatched sides. The little black half-circles indicate sides that are currently unmatched. By doing this, you end up making crazy shapes and chains.

I’ve been working really hard on making the visual, audio, and gameplay experience as smooth as possible. Even though I’ve never really done much actual design work, I’m trying to make it look really streamlined. I’m constantly opening up Photoshop and making small adjustments to things until they look pretty good.

I didn’t really set out to make a finished app at first, but the more I worked on the game, the more I enjoyed playing it. I’ve been doing a TON of iterative design. It is completely different than it was when I first started. It’s been a really fun experience, and I have also learned a more about programming than I have in a long while. It’s amazing the problems you have to figure out when trying to push through to create a finished product. In the past, when my code got to spaghetti-ish and I couldn’t figure out what I was doing, I would just abandon the project and start again. Every time, my code got better. This time, I’ve really had to be careful so that I can maintain all the separate classes without them getting too confusing or anything, because it just keeps growing and growing.

I still have a lot to do. Some things I still need to add are pop-up score labels for matches, a way to save/load gamestate, GameCenter integration, some sort of animation when you make a match rather then just fading out, actual options (right now there’s nothing really in the Options menu), some more audio/music, In-App Purchase for different types of shapes and game modes to play with, and more. I’m super excited about this and can’t wait to share more!

So there’s an open audition-type thing for the game Gunpoint and I did a tune for it. More info about this audition/contest thingy here.

Please listen on headphones or good speakers. It sounds way better! Also, the sub bass drone can be a bit overpowering on speakers with a good low end, but I boosted it a bit so that people listening on crappy speakers could at least hear it somewhat.

I really just went with my feeling on this. I kept adding a bunch of things that just felt like they should be there. It’s sort of a mix between electronica and spy movie soundtracks. Plus maybe a bit of Pink Floyd’s David Gilmour. This was amazingly fun to do!

Not only does it have all the original music from the game, but it also has unreleased tracks, as well as covers by Satstuma Audio, Disasterpeace, Joe Cavers, Charlie McCarron, Cain German and some1namedjeff. Go get it at www.CardinalQuestMusic.com!

Name Change

Dana’s last name is Tesser and mine is obviously Blackall. Some possibilities we considered:

• Dana changes her last name to Blackall
• I change my last name to Tesser
• We change both of our last names to Tesser-Blackall or Blackall-Tesser
• We make up an entirely new last named based on the letters of both

We ended up going with the last one. That way, we’ll have a name we both love. We won’t have to worry about what name our kid takes (if/when we have one). And it won’t be all clunky like a hyphenated name. We wanted to do this because, well . . . why not? Why does the woman always have to be the one to change? And why not make a sweet new name?

We took four letters from each last name. From TESSER, we took T, E, E, and R. And from BLACKALL, we took B, A, L, and L.

We then rearranged them and combined them into TREBELLA.

Nothing is set in stone yet. We have to actually go through the process of changing it officially, then changing passports, driver’s licenses, etc. That’ll be extremely annoying. But it’ll be worth it. We will now be Whitaker and Dana Trebella!

I have changed my Twitter name to @wtrebella. And I just registered www.TrebellaMusic.com. So keep an eye out, because I’ll eventually be moving over to that domain.

Thanks for reading!

The soundtrack to the upcoming indie game Cobalt is out and I have a remix on it! The music is by Anosou, who’s incredible. The album also features remixes by Chris Geehan, Jimmy Hinson (bigGIANTcircles), Magnus Pålsson (SoulEye), Daniel Rosenfeld (C418), and Steven Velema (surasshu). I’m proud and humbled to be in such good company.

My remix is called Chunkopia. Listen to it below (as well as all the other amazing music on the album). It’s my first actual remix. Usually I do covers but I actually used some of the original audio in this one, which I think makes it a remix. It’s a weird mix of genres. Hope you like it!

The first game I made was Snake.

Snake

Making this game really helped me understand the basics of Actionscript 3 and Flixel. It was surprisingly easy to make! My code got pretty sloppy after awhile though, so I wanted to try making another game, this time keeping clean, documented code.

Play Snake here.

The next game I made was another really common one. All you need to do is avoid the walls. There are three levels of difficulty (either click or press the number on your keyboard to start the game). Sorry, but if you start playing in one difficulty, you have to refresh the page to change the level, because out of laziness, I never built in a “Go Back to Menu” button. Also, sorry, but I made one piece of music that I used for both games, so hopefully you won’t get sick of it.

Racer

Play Racer here.

One of the main reasons I wanted to keep the code clean is because I wanted to open source the game. I tried to document every major thing in the code so it would be easily understandable. I’m sure there are still many things I could have done better, as I am definitely still learning, but anyone is free to download it and muck around with it. Download the full source folder here.