WordPress multisite is a great feature for those who run multiple blogs. Recently I was tasked to set up such a configuration on Dreamhost, only to find that multisite doesn’t play well when it comes to using subdomains (and by extension, external domains) in a shared hosting environment. According to the official documentation, you’ll need access to your Apache httpd.conf file for subdomains to work. For most shared hosting plans, it’s understandably not allowed. Fortunately for those of us on a budget, there are some workarounds.

Multisite with subdomains

Getting subdomains to work with multisite on Dreamhost is fairly straightforward, actually. There are two ways to do this — after you follow all the steps to set up multisite, of course. For the first method, create the subdomain in your WordPress admin, then create the same subdomain in your Dreamhost panel. Pick the option to fully host the subdomain, but point its web directory to your root domain. For example, if your root domain is domain.com, create subdomain.domain.com and set the web directory to domain.com, as shown in the screenshot:

The second method is to set the subdomain as the mirror of your root domain.

There are no substantial differences, as far as I can tell. Then again, I haven’t done much extensive testing. The fully-hosted option gives you a bit more flexibility, I suppose.

Multisite with external domains

Getting multisite to work with external domains on shared hosting is trickier. One method requires a plugin, while the other does not. The plugin method worked much better for me, so skip down to that section if that’s what you’re looking for.

Without plugins

I found a post detailing how to set up multisite with external domains. It assumes you are able to create virtual hosts, but some of that information is still applicable to Dreamhost. Set up subdomains using one of the methods I covered just now. Then, edit the hosting options for your external domain to also use one of the two methods I described. Then, hop on over to Interconnecit’s post and skip to the section “Adding a new domain” and start from step 5. With that, multisite with external domains works, sort of. For me, I was not able to administer the new domain as a super admin and activate themes and plugins. There are workarounds (see the comments), but I really did not want to get into the habit of changing WordPress core files. That led me to the plugin.

Using the Domain Mapping plugin

This methods works by using the WordPress MU Domain Mapping plugin. WordPress developer Sam “Otto” Wood covers it in an excellent tutorial. Again, you’ll need to set up the hosting options for your subdomain and external domain using one of the subdomain multisite methods. I found that your subdomain needs to mirror your root domain, but the external domain can be either mirrored or fully-hosted using the root domains web directory. I found that the fully-hosted option worked better. To repeat: fully host your external domain, but point its web directory to the root domain, and have your subdomain mirror your root domain. Then follow Otto’s tutorial to map your subdomain to the external domain.

I have not tested any of these methods extensively, so I recommend backing up your site before you try any of this!

Let’s get one thing straight, though. Textpattern has been good to me. It has given me a platform to build and hone my skills as a budding designer, developer, and blogger (ahem). Alas, my needs have outgrown it, and the work I did for the University of La Verne redesign as well as other theming work really got me comfortable with working with WordPress. Furthermore, having used it with various clients, I have to say its admin interface, while not perfect, is still very user-friendly for the average user. Imagine trying to teach a client how to use Textile or Markdown for use in TextPattern. Yeah, right. It’s simple for web-savvy users, but for many of my clients it might as well be, er, HTML.

 Why not another CMS?

I’m not interested in starting a CMS debate, and I’ll link to why Nathan Smith chose Drupal. For me it just came down to what I was comfortable with. WordPress meets my expectations as well as my clients’ needs. As such, I’m not terribly interested in learning yet another CMS. For that effort, I’d much rather pick up a web framework, which for me right now is Ruby on Rails. Consider the age-old Photoshop/Fireworks or Mac/PC debates – there is never any end in sight, and the winners are the ones who are producing great work, regardless of tools.

It’s Responsive

The migration to WordPress gave me a good excuse to update some of the underlying code. Those efforts centered around moving to HTML5 as well as a responsive layout. Even though the movement for responsive web design has been around for a while, this is my first RWD site. Since this was not a redesign, the responsive portions are bolted on after the fact. Don’t be surprised if there are kinks.

What now?

The content has been migrated, and the code updated. That was the easy part. All that technology is nothing without content, which I see as the biggest challenge for this site. I really hope I can start writing more. Right now, I’m being cautiously optimistic. Stay tuned…here, I hope.

Programming (in Objective-C) is hard

Let’s start from the top: I’m not a programmer. At the least, let’s just say I don’t plan on selling my services as an iPhone programmer anytime soon. No, I started my career in digital media as a web designer/developer. I come from a world of Photoshop, Illustrator, CSS, and HTML. My programming experience was limited to some C classes and long days programming visual stimuli for EEGexperiments in MATLAB while in graduate school. I know a bit of PHP, enough to write basic functions while I make WordPress themes, and I’m somewhat familiar with the MVC pattern through working with Ruby on Rails (I worked mostly on the view part). Suffice it to say that learning Objective-C was not an easy task. I bought three books to start learning and gave up twice over the course of a year. I learned enough to perhaps build some really simple and basic apps, but nothing close to an actual game. Enter cocos2D.

I stumbled onto cocos2D while looking for frameworks for making iPhone apps. I knew of PhoneGap and found GameSalad. I didn’t give either a serious try because I wasn’t exactly sure of PhoneGap’s capabilities, and I was wary of GameSalad’s price and in-game branding (note: stuff has changed at GameSalad, but I haven’t been keeping up with the specifics). The overall concept of cocos2D kind of clicked with me, interestingly, after playing with GameSalad’s creator. Directors and scenes and objects made more sense to me after I realized I was just creating pseudo-code in GameSalad. This isn’t to say that stuff was easy from then on, but it was sort of an a-ha moment that led me to create my first game. Many tutorials and sample code later, I created Memory Flash (more on that here).

While I did create a functional game, I felt like I didn’t understand cocos2D well enough. By chance, I came across Steffen Itterheim’s blog and saw that his latestbook was in alpha. After browsing through the sample chapters, I was sold, and read through most of his book in one day. Through it I learned a lot more about cocos2D and game programming, and that was when I formulated the idea for Balloon Ride — a game that is simple enough to try out what I learned from the book. But what I thought would be simple was not so after all.

Game design is harder

The premise of Balloon Ride seemed simple enough: you tilt your phone to avoid enemies and collect stars. Nothing hard about that, right? In a sense, no, it isn’t hard. With the help of cocos2D and the book, implementing the basics was simple for the most part. Once I got past the basics, game design-related issues that I haven’t considered before popped up one by one. How fast should the enemies come flying? How soon do I ramp up the difficulty? Is the game too hard? Is the game too easy? It was the details that kept my head spinning, trying to find the right balance between hard and fun. I learned that what makes a game great is in the experience, and designing that experience is no walk in the park. In that sense game design is absolutely no different than web design: one may be able to learn how to program or use Photoshop using tutorials and a book, but truly great designs come from intuition, experience, and mastery.

On a somewhat related note, the graphics for the game came the easiest for me, as I’ve had plenty of experience with Photoshop and Illustrator. However, supporting Retina display was rather tedious as I had to create two versions of almost everything. This was when I came to appreciate Fireworks and its unique blend of vector and bitmap tools. I haven’t really used Fireworks even though most web designers swear by it, as I’ve already develop a level of comfort in Photoshop. But after this experience I might consider using Fireworks for my web mockups.

After a solid month of non-stop development and a couple rounds of testing, I finally managed to submit the app and got it approved. I thought the hardest part was over. Boy, was I wrong.

Marketing is hardest

There are 300,000+ apps on the App Store, and many of them are free. How does one app cut through the noise and reach its intended audience? To be honest, I hadn’t really seriously considered it. Memory Flash got 600+ downloads despite me doing next to nothing to get the word out (I blogged about it and tweeted about it once). It’s peanuts compared to other games, but way more than I expected. Even at this writing, after two months after release, Memory Flash is still getting downloads. I’m still not sure how these people found Memory Flash (App Store analytics, anyone?), but it led to the belief that something on the App Store helped people find my game. Surely, then, a better game would be easier to market, right? What I hadn’t considered was the power of the almighty dollar, or in my case, 99 cents.

First, the price, however low, prevented people from downloading Balloon Ride. Memory Flash was free, and there was no consequence in downloading it and trying it out. Once money enters the equation, the rules change against my favor. Second, paid apps are subject to piracy (I’m not sure if free or freemium apps are subject, and I didn’t check). I knew piracy existed, but I was surprised at how rampant it was. In comparing leaderboard entries and my actual sales I found that a whopping ninety percent of the game’s users are using the pirated version. While that really put a damper on things, I felt my real issue is that I’m not getting the word out about the game. Not only was I late on creating awebsite and trailer, I realized I had almost no experience in marketing, well, anything. I may be good with Photoshop, I may have picked up Objective-C, but marketing is an entirely different beast. So here I am, writing a post-mortem to be included in Steffen’s Linkvent calendar as part of the marketing effort. I have some other ideas/venues to try, including a lite version of the game, but I have to say this is all a painful learning process. If anyone reading has any good suggestions (and not just about marketing) I’m all ears!

Design is fun

However difficult the process may have been, I did learn that creating a game was really fun. It is nothing like creating a website (and as a standardist and iPhone fan, I’m not really including Flash here…) in that there is a lot more one can do with a touch device. The fact that I was able to create a fully function iPhone app is a testament to cocos2D and how powerful it is. While I do plan on keeping up with the framework, I recently discovered a real competitor that has pique my interest: Corona, which uses a much simpler language in Lua. All due respect to cocos2D, but it’s still Objective-C. Despite lagging sales, I’m still interested in creating another game, whether it is with cocos2D or Corona, but I’m sure I will be building on what I’ve learned so far. In the meantime, I leave you with this:

I’ve had several people ask me why I’m taking on programming even though my bread and butter is front-end design and development. Even though that is what I enjoy doing the most, I constantly felt that I was limited by content management systems that require arm-twisting. I wanted more control over the things I design. So I started learning Ruby on Rails and Objective-C. Yes, I’m trying to learn both, and that’s after I caught myself trying to do too much reading about Django, CodeIgniter, and Drupal. I decided to settle on Rails because I was already familiar with it, and Objective-C because it’s a channel into the mobile arena.

Programming is hard, and object-oriented programming was a lot to wrap my brain around. And let’s not even get into memory management. I was close to giving up on Objective-C many times until I stumbled across the excellent cocos2d framework. With that, things started to make more sense, and I was able to build off of some tutorials. To be honest, I’m still very shaky with Objective-C — I think I only finished this game through sheer determination, and lots of time.

I actually finished the game in July, but didn’t submit it because I thought I should be supporting Retina Display. Unfortunately, conflicts between Apple’sUIKit and cocos2d prevented proper display of hi-res images. And so my app sat there for 2 months collecting dust. It wasn’t until two weeks ago that I decided to follow through on the old software adage: “Release early, release often.” I’m glad I did. I’ve already submitted my first patch to fix a scoring bug. Hi-res display is coming soon as well. In its first three days of release the game has been downloaded almost 300 times. Nothing spectacular for sure, but much better than the 10 friend downloads I was expecting.

So, am I thinking of making another game? I’m not sure, but I do have an idea that I think might be decent. Stay tuned.

Trimming the fat

Starting with this version of my blog, I’m doing a hard reset on my sites. This blog moved from david.sutoyo.com to the new davidsutoyo.com, starting fresh with no old articles. The old domain redirects to here, although the old version of the blog can be found here. As for my other blogs — asimplecell.com is next up in line to be revived without a blog, and I plan to shut down Schema and move most of its articles here. To paraphrase Jerry Maguire, it’s less blogs, more personal attention. Single serving sites such as Two Versions Behind will stay as they are (although it will soon be three versions behind!).

What next?

Like I mentioned, asimplecell.com is up next for a realign. After that, I don’t really know. Twitter and Facebook has really diminished the need for dedicated personal blogs. This blog will focus more on design, but to battle for attention in this niche is definitely not an easy task. What I can promise, though, is that there will be no list articles. It’s like they say, quality over quantity.