Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 29, 2014
arrowPress Releases
August 29, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Tile Crusher - A Postmortem
by Mike Murray on 05/20/12 07:56:00 pm

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Well, my first published game, Tile Crusher, is now available on the Windows Phone Marketplace. I started this game back in April 2011, but the idea was actually much older. I'm just happy I was able to take the idea and commit it to code! Now that it's finished, I feel like a legit game designer now. This is something that was 10+ years in the making, and now that it's happened, I feel like I can do anything. This moment has a deeper, more personal meaning than I care to share, but let's just say that it's a huge deal for me. I do hope that my first game sells well, but even if it doesn't, I am proud to say that I made it, and it's out there in the world for everyone to witness. And it's only the beginning of what I have in store!

 

In The Beginning...

Tile Crusher, like most games, began as an idea I had in my head, but I started coding it as a school assignment. I made a few iterations of Tile Crusher: once with XNA, the second time with a SDK called Dragonfire, and then a third and final time with XNA again. By the third iteration, I found a better way to design the game. Originally, I wanted the player to be able to control the ball by dragging it across the screen, but that ended up being troublesome because the ball would always get ahead of the player's touch. So, I decided to go with tap controls, and I feel that was the better choice considering that the game isn't meant to be fast-paced.

A rough image of how I wanted the game to be. 

An in-game shot of my first prototype. 

 By the time I got to Dragonfire, I came up with a better way to design the levels and to control the movement.  I was pretty satisified with the result, but I discovered that I really liked XNA, so I took what I made in Dragonfire and scrapped the old XNA version.

What Went Right

When I rewrote the game, I knew I was going to need some kind of level editor, because I wasn't about to hardcode 50 levels.  I wrote the level editor in XNA and created it as a Windows project so I could make them on my PC and have the game locate and read the files.  That turned out to be a problem, which I'll explain later in the next section.
My level editor. 

Creating the level editor was the best thing I did for my game.  I learned a lot in the process, much of which will carry over in other games that I create.

I'm really happy that I figured out an easier way to design the game overall.  I look back at my old XNA code and I'm like "did I really do it this way?"  Not only was it inefficient, the code was hard to read after not seeing it for several months.

What Went Wrong

This was my first time creating a game for a smartphone, so I had no clue how storage worked.  There's no way to see where the files are stored on the phone without using third party software, so what I had planned wasn't going to work.  I even went as far as creating a level editor in-game to see if that would help matters, but it didn't.  What I ended up doing to resolve the problem was embed all of my levels into the code.  The emulator that came with the SDK worked well for testing--as long as you didn't close it.  That eventually became a big problem, so I ended up purchasing a Nokia Lumia.  I had to spend money I didn't really have, but it was important that I saw this game through to the end (also, you really need to have a device.  You can't rely on the emulator alone!).  I made a $300 investment that I hope to recoup through sales.  As an added bonus, I got a huge upgrade (I was using the iPhone 3G before, heh).

I made a few slip-ups when I submitted my game for certification.  The Back button wasn't usable at all; whenever you pressed it, it would completely exit the game, which is an automatic fail.  I find that strange, considering that the cause of that problem was two lines of code that XNA puts in by default.  The other mistake had to do with the game taking control of the media player.  The rules state that an app should not take control without the user's consent.  What most developers do is just disable any in-game music if Zune is running, but I had none of that.  Thankfully, the issue was easy to fix, but let this be a lesson to all the newbie developers: read the guidelines thoroughly!


The End...Or Is It?
So the game is out, and I'm happy, but is that the end?  I'm already thinking about ways to improve Tile Crusher.  As I mentioned before, I created an in-game level editor; I think it would be really cool if players could make their own levels and share them with the world, but I don't know how feasible that is as a broke solo designer.  The second thing I wanted to do was create more levels, which is totally feasible.  I have other projects that I wish to work on, but if it turns out that my game sells well, I just might have to do it!

Good or bad, win or lose...my first game is out on the market, and I'm proud of my work.  But I'm only getting started!   


Related Jobs

GREE International
GREE International — Vancouver, British Columbia, Canada
[08.29.14]

Senior Game Designer
SAE Institute
SAE Institute — San Jose, California, United States
[08.29.14]

User Interface Design Instructor
SAE Institute
SAE Institute — San Jose, California, United States
[08.29.14]

Compositing Instructor
Bigpoint GmbH
Bigpoint GmbH — Berlin, Germany
[08.29.14]

Lead Game Designer






Comments



none
 
Comment: