Arctic Empire

Over the course of making Galaxy Express I’ve learned many things about playtesting.  At first I was under the impression that I’ll just play through the game, make sure I can beat it, and everything’s good.  This is not the case.
In galaxy express there can be many possible solutions to a given level.  Sometimes I’d catch a bug just by playing through, but a lot of the time I’d completely miss them.  Let’s say that I’m beating all the levels as I’ve done many times before, and there’s a bug that only shows up when I have to restart a level.  I’ll never see it.  So that was my first lesson, I have to play the game not to beat it, but to check specific interactions, some of which only occur when I stopped the level then restarted it.  After understanding this I hit Go and Stop many many times for no reason other than to make sure that these buttons worked perfectly.


Level 88

So while this was part of it, it certainly wasn’t all of it.  I then had to check more interactions, like doing one level, doing the next, going back to the one before, then hitting “view solution.”  man did this cause glitches at first, and that’s not actual gameplay!

Then there’s little things, like in the picture above.  The difficulty is certainly not 15 for that level, the code is just reading from the wrong column of a spreadsheet.  That’s being changed as I type.  One of the more interesting bugs we had a few times was the ability to place arrows off screen.  In one build whenever I placed an arrow on top of an asteroid which was already at the top of the level, it would shunt the arrow to the square above it, off screen.  In another build I could just drag the arrows off screen all the time.

If I tapped above the screen, I could pick up the arrows, but many people would think them lost.  It needed fixing.

But there’s one that I totally missed, and am really unhappy that I did.  We had a great update for galaxy express, new bonus levels, and the programming was rewritten to optimize for low memory usage allowing x8 speed to be back in the game (it was cut early in development for lag reasons).  We were really proud of our awesome update.  The problem was this.  I was so used to deleting and reinstalling the game, as I do on a constant basis, that I never thought to test if the newest build would corrupt the save data.  Unfortunately, one build did.  So for the users all the completed levels were no longer complete.  We felt pretty bad about that, and fixed it ASAP, but to some people the damage was already done.  This brought a whole new dimension to things that need testing for each build.  We all want the update to be ready and once it is, to go live, but at the same time failing to test properly can ruin the whole game for a lot of people.

Playtesters, be thorough!

-Avi

So this is my first post on the blog. Let me introduce myself first: I’m Ryan Pierre - Flash programmer for Arctic Empire. I’ve been programming in Flash for 5 years now, it is my second programming language after Java. I began programming in BASIC when I was about 13, but quickly grew bored because it was both ancient and arcane and not as fast as other languages, and I don’t think I learned enough to say I actually knew it. I picked up Flash shortly after from a design standpoint, but it wasn’t until I was 16 and learned Java through my High School that I picked up actually programming in Flash (ActionScript 1!). The similarities between Java and ActionScript made it easy to pick up, and from there my love of ActionScript was born as I could develop anything I wanted much more rapidly. That’s all about me, which brings me to my first post:

What place does Flash have in mobile development?

Just over two years ago, the answer would’ve been none - the ever dominant iPhone couldn’t run Flash, and Android devices had not surged in popularity yet. Adobe then has the elegant idea to make their AiR platform able to export to native iPhone and Android app formats, and thus a new sector I could work in was born! With my love for video games, and a wild west market to make them, moving into mobile development was a natural choice for me. The rapid development and smooth vector based graphics of Flash work perfectly with the new age of mobile games, and even the speculated performance flaws of AiR for iPhone were quickly silenced by the results. So in order to test this idea for myself, my first job at Arctic Empire was to recreate Galaxy Express, written in Objective-C to Flash, so that it could be ported to various other formats, as well as test it’s performance on an iDevice.

There were many challenges to this task that were unexpected, and if I hope to achieve anything with this post, it is to enlighten anyone attempting to convert an Objective-C program to Flash. The first (and biggest obstacle) was the XCode based data format PLIST. Most applications written in XCODE use PLIST files - tree-style data to be loaded into a program externally, synonymous to XML. As it turns out, Flash cannot read these files, so the first task was to get Flash reading these files, so we didn’t have to re-write over 100 level files in XML. This proved to be more simple than expected, but at the same time I believe a more elegant solution could’ve been attained. My solution was simply to interpret the PLIST as a String, and then interpret that string as XML. Worked like a charm. From here, I just needed to understand the architecture of the files, and learn how to organize the data. The next challenge was  to convert a program whose current systems were written in Objective-C into an Events based language like ActionScript. This meant there wasn’t much recyclable code - and a lot of strange bugs were awaiting me. The problem with Events based languages, and ActionScript more specifically, is garbage collection can be very tedious, and thus memory leaks were happening left right and centre. So through expert plumbing (Zing!), I was able to fix all the leaks and ultimately have a smooth flash-based version.

All things said and done, it was an interesting first experience converting a native iOS game to Flash. I wouldn’t exactly recommend the procedure as I have begun development on a native Flash project here at AE and I’m working at about 4-5x the rate. I personally feel Events based languages such as Java and AS3 and Non-events driven languages such as C or C++ just aren’t meant to be ported from one to the other. In the end I think it’s ultimately more productive to start from scratch in the native language instead of trying to recycle anything. I hope this post was insightful and in the future I promise my posts will be a tad less geeky!

Ryan

When designing Galaxy Express, most of the assets designed were illustrator based and therefore very reusable. The main ship would never change from level to level, along with many other assets.  The only exception being the enemy ships (there were 3 for different stages of the story), and the planets of which there are over 120.  

Now upon seeing only a fraction one might ask themselves how long did it take to make all these planets? How did one not go crazy designing them, getting all the textures and colours and unique quality to most planets? Why torture yourself as the consumers would only stare at them for only a fraction of a second as their attention span has lead them to something else.

Now you might think, he just used a tutorial, went on google, searched “How to make a planet in photoshop”, found the easiest tutorial, cranked out 120 + (that crazy man), and went on his day. Now I’m sure there are many a good tutorial out there for making planets, highlighting and giving them effects, but I don’t care about them, I enjoy exploring. The first planet I made took about 10 min, the next 5, then 3,1, and then 30 seconds per planet. So to make over 120 planets took around an hour or so. How? you may ask, well just give me a second… I’m typing as fast as I can.

Read More

Bombs, Wormholes and the stuff that didn’t make it.

Bombs are an awesome mechanic that has multiple uses.  The first use is the unique way that the bombs modify the level at runtime.  So you can take 10 steps, and BOOM! the level has changed!  Of course you have to make sure your ships isn’t around as it’s blowing up either, which is the second use; the bomb is an obstacle that reaches out from its starting position to explode everything around it.  The third use is that bombs add more explosions to the game, which is just plain cool.  Finally, the bomb cam be used as a lock and key mechanism.  In the bonus level pictured below, you must first get the key (the enemy ship) over to where the lock (the bomb) is to open the door, letting your ship out.

Of course you also have to make sure the lock doesn’t blow you up in the process :)  Bombs are an awesome mechanic that definitely contribute a lot to the game.

Wormholes are another great mechanic.  Go in one, come out the matching one.  Simple, easy enough to conceptualize, but it can also really test the spatial awareness skills.  I had a lot of fun using the wormholes to create loops where the same wormhole was used over and over, each time being entered from a different angle to get to a new area.  Wormholes are also used to send cannonballs flying all over the place in some levels, as a way to make mini levels within a level, and as a goal where the angle you hit it from matters.  One of my favourite examples of wormholes is in level 100, where I had a crazy time tracing all the enemies at once to test out the achievement on that level for destroying all the enemies before your ship reaches the planet.

Let’s face it, there’s a lot of enemies.  Mad props to everyone who gets that achievement.

As for the stuff we didn’t use… Well, there’s a lot, but here are some ideas we wrote down that never made it to development.

Off speed enemies.  They could be faster or slower, but we decided that this wasn’t needed.  Far better to have enemies that move the same speed but turn differently.

Lasers.  Think really fast cannonballs.

Conveyor belts.  They slide you, but won’t turn you.

Rockets.  Things would turn into a dogfight pretty quickly.  While that could be very cool, that wasn’t really our goal for this game.

Freezers.  Slow down whatever gets hit by them.  Again, we felt this would complicate things a lot, and we had enough timing mechanics.

Unstable space.  You can step over it once, but then it turns into a black hole.  Kinda like a reverse bomb, so it felt extraneous and like it was just there to have extra mechanics.

Overall, the reasons mechanics got cut was because we wanted the focus to be on the puzzle aspect of the game, and not the memory aspect of what mechanic does what and how well you can remember the graphical queues.  Keep the timing constant, letting people logic things out.  Keep the mechanics few, having just enough to make a great game, and few enough that they are easy to remember and reasonably intuitive.

I hope you all enjoy the game!

Avi

So far on this blog we’ve heard from Avi and Rico.  These two men decide what I do, day in and day out.  I’m a programmer;  I write the code to make Rico’s art work according to Avi’s game mechanics.  I take specifications of features and turn them into real working things.  For this blog post, i’m going to use our new upcoming game that we’re working on, called “Office Attacks!” for examples.  Please note that this game is still in development - many of the things you’ll see in these screenshots are only placeholders and not final.   Here is a screenshot of the game running.  I’ve just tapped on the square where there is that little blue “fingerprint”.  In our current design of these menus, when you tap a blank spot in the game, it brings up this “radial menu” and gives you all the options for that particular action: 

We’ve gone ahead and redesigned these types of actions’ menus.  We realized that while it was extremely handy to have all the options right there at your finger, we couldn’t display nearly enough information.  The other issue was, we weren’t sure how to handle corners - where there was too much information to fit around the spot while keeping it all on screen.  Here is an early screenshot of our redesign of these menus for actions such as these:

The idea behind these menus is that when you tap an empty spot, or in this case a tower that already exists at that spot, this menubar will slide into view and allow you to do whatever is necessary.  We’ve gone back and forth about whether to keep with the “radial menus” or move to this sort of approach, and believe it to be the best option.  Of course there are still some things to be figured out, but that’s not the purpose of this blog post.

The purpose of all this information is quite simple:  you can’t get attached.  When doing my job, that’s something extremely easy to say, and amazingly difficult to do.  I probably spent a good few days working on the radial menus.  As an example, I first got the menus working [in a very basic form] on May 19th.  Here is the first screenshot I took of them way back then:

So as you can see, the feature has grown and developed into a full structure.  You can also see that the tiles and carpet pieces have been updated and a top menu has been added.  As a developer, designer, programmer, tester, etc you cannot get attached to particular designed or features.  During development, things get cut and changed.  Features are tweaked and removed.  It’s just a fact of life.

I hope this blog post has given you some perspective into the life that’s lead here at Arctic Empire.  I also hope it got you excited to see Office Attacks! in the app store later this summer!

That’s it for now.  Thanks for reading!

-Steve

While trying to write this blog entry, the first thing that boggled me is where to start. What do I write about to tell you, the reader, about who I am, what I do, and my company Arctic Empire. Where do I start? is a very good question that comes up everywhere with anything that we do.

For example:

First you might consider to look on online, see what kinds of guitar there are, the kind of music you want to play, ask some professionals their opinions based on your wants and need.

Check out one of the many tourist guides at travel agencies, books at the library, friends who may have already done it or once again the internet.

The most important thing I do when starting anything is to follow these 3 r’s: research, get references, and use my resources. The best thing I do in almost all cases is firstly my research to see what others are doing and build upon that to get what I need. I apply this to everything I do in life, leisure, work, and especially with the games I produce.  References help to mould and flesh out the game as you have an example to see what has been done before, what works, and what doesn’t.  Using past resources is always a help, as frameworks, code and designs may already be done for me just waiting to be put to use.


 

When it comes down to designing and building a concept for a game what I do first is generally look at my available resources: what I’ve done to date, ideas I’ve had, and sketches I’ve done to see if anything I’ve worked on before will assist me.  From there I try to figure out the type of game I want to make. In the case of our latest release, Galaxy Express, the game concept came to us while sitting around talking about our release Forest Frenzy, and how we would love to do a puzzle game next. Pizza box on hand we started sketching on it, plotting the game style, mechanics, and theme.

When we brainstormed Galaxy Express we sat down coming up with over 20 unique mechanics, a few ways to play the game,  a couple of controller options, and we all immediately agreed on the theme and had a basic story concept to go with it. Based the game on a universe we previously created, and using friends and family as models for the main characters.

After concept came research to see what has been done before and to see where we wanted to pull resources from.  Our research took us from designs of spacesuits, ships and aliens to how big our grid size should be.  By the end of our research we had seen what had already been done, games like Chu Chu Rocket, and Trainyards, giving us plenty of references for improving on our original concepts, and helping us form clear goals for what we wanted to design towards.

We had our idea (puzzle game), theme (space), our research (other apps), and references (universe created previously, and friends as character models). So next came production, getting the team all in the same mind frame, and running with the project till its done. But things aren’t always that easy now, as I’ll be sure to tell you in future posts.

Rico

Over the past few months we’ve been building a game I’m exceptionally proud of in every way, Galaxy Express.  This game started when Rico said to me, “Hey Avi, let’s make a puzzle game!”  Well, of course I was up for that, it sounded awesome!  So, like usual, I and Rico brainstormed everything that could go into the game.  After generating a really large amount of ideas we then cut most of them because a puzzle game isn’t about confusing people with 800 different mechanics.  A good puzzle game has a few easy to understand mechanics, and uses them to make people to think!  Here’s a bit about why we chose the mechanics that we did.

Why do our ships turn clockwise, but the enemies turn counter clockwise?
The reasoning here is that the ships need to turn in order to go somewhere new.  The ships turning opens up a whole wealth of puzzle possibilities and requires the player to use the walls to turn.  But if the enemy ships turned the same way as you, then they would just follow you all level long on the exact same path, making them be a largely useless decoration.  Enemies turn left because they need to take a different route to still be a challenge.

Why do we have cannons, and how did we pick the timing?
Cannons were a very multi purpose tool for building this game.  Not only do they get people thinking about timing, but they also act as a one way wall!  Since the timing is that every third step brings a new shot, A ship going head to head with a cannon will be shot down.  But a ship running away from a cannon can always keep moving, safe from that cannon.

Black Holes?
Yes, the mechanic of an impassable obstacle is not really original, but is very useful.  Black holes are a way to lose, plain and simple, and you can’t do anything but go around them.  Their main usefulness of the black hole comes not so much from its interaction with the ship (blowing the ship up), but from its interactions with the other mechanics.   You can guide enemies into them to blow them up, shoot the black holes with cannonballs to block shots, or whatever, but the black hole will remain, always letting us know that this path is closed.

Next week: Part 2 - Bombs, Wormholes and the stuff that didn’t make it.

- Avi

Welcome to Arctic Empire’s new blog!  My name is Steve and i’ll be your cruise director through our journey here.  Will take a hard look at all the hard development going on behind the scenes, who works here, and what we do.

First, let me introduce myself.  As i’ve already said, my name is Steve.  I’m the “Lead iOS Developer” here, and often refer to myself as the “Code Monkey” of the company.  Besides just working on our iOS games, I also maintain a lot of our web presence - coding up our various websites, and quite frankly, just doing whatever needs to be done around the company that involves coding in some way.  I was asked by a few other members of the team to write in and maintain this blog, but they will be making their own posts from time to time.  So i’ll move on a bit from the information about me.

Instead of going through the entire history of the company now, I thought it’d be fun to focus a bit on our products.  So, let’s start off with our latest game to be released - Galaxy Express.  Galaxy Express is available in the iOS App Store and also on the web.  In Galaxy Express we follow the journey of Jonathan Rowe - a pilot from the Confederation of Aeronautic Space Travel (C.O.A.S.T.).  He travels through the universe delivering supplies and cargo when, unbeknownst to him, he ends up in the middle of an impending war.  With Space Orcs breathing down his neck, Jonathan must find a way to defeat his enemies and save the universe - all while avoiding asteroids, black-holes, and other dangers of deep space.  Your job - navigate Jonathan through his journey and deliver his packages safely.

Now that you’ve heard all about what our game is, here’s some behind the scene information for you - our blog reader.  Galaxy Express was designed and built in the span of about 3 and a half months.  Rico and Avi conceptualized the game in record time, and began an intense few months of development.  With me doing all the programming and Rico designing all the graphics, that left Avi to build and test levels.  We hit some roadblocks along the way, but all in all, it was a great game to build.  Here is a quick screenshot of our internal level builder: [click for larger version]

The app totals just over 81,000 lines of code, spread between 286 different source files - and that doesn’t even include cocos2d [the OpenGLES framework that I use], though it does include some very handy kits such as ShareKit.  All in all, Galaxy Express was difficult, but educational to build.  We’ll go a bit more in depth with the process of building our iOS apps in the next blog post.

That’s it for now.  Thanks for reading!

-Steve and the entire Arctic Empire team.