Thanks!

This is a recent article I wrote for Indie(Function); magazine about my perceptions on what makes Minecraft so successful:

Minecraft: What Makes It Hit, Stick, and Grow

Guest Writer: Connor Ullmann

What Makes It Hit

Minecraft was amazingly confusing the first time I played it.  Suddenly, I find myself in this pixelly world, walking around and fumbling with the controls a bit, learning to jump and use my inventory, without any kind of tutorial or opening NPC telling you how to do this and that and what to do next.  This was initially cumbersome, but I soon caught on to the purpose of this—Minecraft’s unhelpful world really embodied what it is; it’s a world where you’re figuring out what you want to do, and you’re all alone to do it yourself.  In a sense, not having that NPC there made the world all yours, and that feeling really pulls you into the game and makes you want to find out more about it.  This is part of what makes Minecraft so immersive—players are given full control, and have to learn on their own how to use it.  Dying to zombies on your first night, making your first pickaxe, crafting your first torch—these are all important in keeping the player interested in the game, as well as keeping them engaged with thoughts of how each new tool can be used.  Minecraft gives you a world with scant few rules, and you need to figure out for yourself how it all works—thus you discover every facet of it, and the game keeps on giving.

 

What Makes It Stick

Picking away, block after block, seems like an enormous waste of time when seen from outside Minecraft.  You’re going to hold down your mouse button for hours watching the same crack animation overlay appear on block after block, just to find a one-in-a-million diamond ore pit (which will just make you more pickaxes with which to dig more?)  The answer for most people who play, however, is an almost begrudging “yes.”  Because Minecraft, even though it is built on very few core elements, has a sense of majestic discovery to it—on the other side of any block could lie an enormous and expansive cave filled with lava, water, coal, redstone, iron, diamond… Everything you need to help make your recreation of Middle Earth, but at the risk of creepers, zombies, and spiders that will scare you half to death when you find them, and enrage you when you die to them.  Minecraft is complicated, yet the elements within it are simple and not built to make you play with them in a single manner.  The piston wasn’t given a purpose when it was designed—it was designed with the idea of letting players give it purpose.

The future of gaming is in procedural generation.  I say this because I know the feeling of floating around in a Minecraft boat just looking at mountain formations and saying “man, that’s awesome!  I should put my base there.”  Playing an FPS with straight-edged levels and storyline, with the same ammo box in the same place for every player every time the level is played, removes the sense of discovery and instead makes you a role-player (don’t get me wrong, this is good for some games, but not for a truly addictive and replayable one).

Procedural generation, alongside letting the player discover the game without the developer’s hand-holding, has a few subtler benefits.  I’ve worked on my own small Minecraft-esque 2D digging platformer, and one of the most inspiring moments while working on the game was when I had finished building the cave generation algorithm—it lined walls in gold and limestone, created long, dark tunnels, and added pale enemies randomly that would attack you.  Walking into that first cave gave me an amazing burst of motivation, because I was discovering the game, not just making it.  This is an unseen benefit for using procedural generation because, with it, even developers get to feel out the game and enjoy it as they make it, making for a better game overall with more effort and motivation driving its creation.  Minecraft is also is an opportunity for the developer, given the fact that almost every idea is functional within it.  That, more than Minecraft’s explosive popularity and money-making power, is why I wish I had made Minecraft.

 

What Makes It Grow

Building in Minecraft brings about a need to share that is unparalleled by conventional “sharing” in video games used today—one example is online highscores, which are a way in which developers attempt to create replayability by driving you to beat others’ scores online and show your prowess at a game.  In Minecraft, however, you care much more about what you’ve done because you built something—something that isn’t just a number or an achievement.  And, just like showing your mom the lego toy you made when you were little, you crave for the world to see your 1:1 scale sandstone Taj Mahal that you spent 14 hours working on.

Now, what better way to share your vast, labyrinthine tunnel network to the world than through the marvel that is YouTube?  This need to share, in and of itself, brings about a new reason that Minecraft is successful.  When you show off your scale-size replica of the Star Trek Enterprise, people who are interested in Star Trek will stumble across your video when looking for Star Trek videos—this means that the interests that the audience has with which they populate their Minecraft world are also instrumental in propagating the game to an even wider audience.  This is very different from most games, which breed creativity within the game’s own sphere (for example, using different peripherals to build your own gun in an FPS) that take away the audience’s ability to bring in outside influences and share them through the game.

 

What Can Be Learned

Minecraft hits with its originality (sorry guys, can’t give you too many tips on how to replicate that!) and open world.  It is a discovery that is left to the player to understand.  Once understood, Minecrafters can build on what they have and discover new places with rarer ore and cool formations (has anyone else made the floor of their bedroom out of pumpkins?  No?)  Last, players want to show what they’ve made and are making, which is made easy through YouTube and the built-in screenshot button in Minecraft.  Sharing is absolutely crucial for Minecraft, as it helps build the audience and keep players interested because everyone will want to show what they’ve made to the world.  These are make Minecraft hit, stick, and grow with gamers.

Minecraft is an amazing game, and I hope it continues to gather a larger fan base.  It has been an inspiration for me, and I hope this article helped to outline some of the basics in Minecraft that have made it so successful, and how they can be used in more games today!

“Stunning graphics, great gameplay, overall a freakishly awesome effort. I’m blown away.” -Christer Kaitila

I made Hollow for Ludum Dare #21, which is a 48-hour game development competition held online in which you must make all content (sound effects, music, graphics, and non-library programming) during the 48-hour period.  This was a really awesome experience; I’ve meant to get into one for a long time, as they’ve always sounded like a lot of fun, but the scheduling (it’s always on a weekend) really made it difficult.  This time, however, the stars aligned and I got to work on the game almost every waking hour throughout the weekend, and I’m extremely happy with the result.

Hollow is an atmospheric, creepy little platformer where you play as a white creature who has fallen down a pit into a cave where he has to fend off multiple multi-eyed, pupil-less monsters to try and escape.  This fit the theme of “escape” as much as I could think of, but the development was much more about the game itself than the competition.  I haven’t gotten this excited about a game in a while, and even if the game doesn’t do well in the competition, it’s all worth it simply because I finished a game that I truly enjoyed making!

Anyways, in the future look out for a more complete version with more levels and content, as I’m hoping to get a sponsor for this game.  Thanks for reading!

Other comments so far:

“That was a pretty wicked and wicked pretty game.” -Zemmi
“This was a beautiful game. Aside from its length, it left no indication that it was made inside 48 hours.” -Josh @ Dreamland
“Very well executed, This had much more content than I would expect from a 48 hour event.” -hamster_mk_4

Yesterday came the official release of Project Gamate, a new website dedicated to a project of mine where I will build a game based solely upon the ideas given to me by the community.  Each update I post, I will choose one of the top three highest-rated ideas (as proposed and voted upon by the community) and it will be added to the game.  I’m really excited to work on it, and I think Noel Berry did an incredibly job designing the site.  Big thanks to him!

I recently created a promotional Quietus II trailer to get some more interest from sponsors so that I can release the game, and IndieGames.com was nice enough to post the trailer on their blog (click the picture to see the post).

The video itself can be found here:

I recently started programming using Java with the “Processing” library, which has been a ton of fun for quickly laying out prototypes and little tech demos (as I love to make).  On the gaming page I’ve recently added Points, Circles, and Maps (yes, incredible names, I know!)  Each of these programs uses simple math in 2D and 3D, making some cool effects.

In Points, the basis is that there are 1000 points floating in a 3D space, and they beat to the beat of a heartbeat when the mouse is not held.  Using the first two number keys, you can manipulate the points, and you can make the points fly randomly by holding the mouse.  The camera will fly around it in 3D, making a pretty smooth-looking simulation.

Circles is based around the idea of circles floating in space that will always instantly expand to fully occupy their space before hitting the edge of another circle.  Each circle will do this, and draw solid lines to any circle it is in contact with, and it will also draw almost transparent lines to others that are close to within two times its radius.

Maps is just a program that takes a grayscale geographic map of the world colored with brightness by the terrain height, and then it pixelizes it into blocks that will grow taller the farther you move your mouse to the right edge of the screen, all the while zooming around it with the camera!

I’ve begun work on my next game using a lighting engine (open source, feel free to use it!) that I put together after giving a bit of thought to pixel-by-pixel raycasting, and I’m really enjoying this process.  The game is pretty far from completion, as I would want to do a full adventure game (probably a metroidvania) and so far all I have are a couple enemies, what will most likely end up being a boss, rudimentary attacking, and a level editor that I’m building alongside the game (presumably to release with it).  Here’s a screenshot of one of the pre-made levels I have in the editor with some static lights I put down using <space>:

The level editor is hopefully going to be pretty easy to use after my work on it, as right now it uses XML files that I can load into the game by simply copy-pasting levels I’ve made.  This will definitely speed up the process of finishing the game once I get to simply grinding out levels later on before release.  Today I added some background color tiles that you can put in of varying size, and I’m using three default colors right now; I can add as many as I like without any extra effort, so there will probably be several more that I will add in the future.  Also, I added an obstacle, which is a red beam of light.  This one was interesting to add to the editor, as I wanted to let the player preview where the beam will carry before and after the beam is placed, which was a bit of a challenge.  Here’s an image of it in-game:
Please let me know what you think of the game as I work on it; I’ve already begun to run low on ideas, and eventually I’ll need a storyline for it.  Help would be greatly appreciated!  Here’s a link to the game on the website, which will be updated frequently: Lightus (name in progress).

I started a project this week with Noel Berry (Canadian game developer, creator of Leap4Blue, and brother of Liam Berry, who made the music for Quietus) that has been so far dubbed “Gamate.”  This will be a community-driven project, and a webpage will soon be made with more information and the proper description of how it will be fully community-oriented and the path (or lack thereof) for development.  I’ve been working on a level editor for the game that will allow players to make and share levels, as well as allow us to make XML-based levels for the game easily and intuitively.  Above is a picture of the editor with many features that may not be present in the future version but were placeholders and leftovers from when I worked on the project before deciding on the latest plan for development.  Anyway, look for updates, as they will be very frequent when things start rolling!

 

I wrote my honors application essay for the University of Michigan a few weeks ago, and I really enjoyed writing it, to my surprise.  There were a few prompts to choose from, but I chose one that I thought would be interesting to twist in my own way: “Take a complicated idea or object and make it simple.”  In response to this prompt, I wrote a ~600 word essay on how to make water using cellular automata, in layman’s terms (for the most part).  Without further ado, have a read:

One concept that I have found of continuous interest as a programmer has been that of water.  It is a fluid and, as such, it has properties that would seem to make it very difficult to realistically simulate in a fast, simplistic way in a video game or program.  Making water fall, splash, or spread outward due to celerity in waves, and still settle into available crevices neatly would appear to require a vast amount of calculation and rendering precision in executing it on even a basic level.  In the real world, this liquid interacts on a molecular level, which results in these properties of which we are all familiar.  But a program would not be able to run with per-molecule level precision at any kind of reasonable rate, if at all.  In programming video games, there exists a constant dance of balancing the game experience with the speed at which it is able to run; in essence, finding elegant solutions to complicated concepts is the hallmark of a talented programmer, and simplicity correlates directly with its running speed and its overall quality.  In order to solve these kinds of speed problems with water and still give it the capability to form waterfalls, lakes, and varying water levels, from deep to shallow, on entirely randomly-generated terrain where specific-case implementation is impossible, I use a simple technique called “cellular automata.”  This technique divides the aquatic region into squares or rectangles to make a grid where each “cell” can hold a possible amount of water.  Each cell has a set x/y position, width, height, and percentage of fill.  Using only the last value, the fill of the cell, and rules governing these cellular interactions, we can develop a program in which water is able to act in a naturally fluid manner and behave according to all of the tendencies listed above.

In determining how these different cells interact, it simply comes down to deciding how water would act with the different cells around it in reality; if the current cell has more water than the cells to the left or right of it and at least one of them is not obstructed by an impediment of some sort, then this cell must empty water out into that cell to make both have an equivalent fill value.  Also, if the cell below the current cell is not blocked by ground or another obstacle and is not completely filled with water, it must fill up with as much water as it can from the current, higher cell until it is completely full.  Then, we simply have each cell draw a rectangle whose height is determined by its fill value, and we have a program where water can flow left and right, as well as by gravity.  By using these simple, logical rules and executing them for each of the cells that contain water several times a second, a program can easily handle this method  and give an effect that will allow for waterfalls, bodies of water with varying depths, and waves.  Also, with a little tweaking, pressure calculations can be implemented to show when water is shallower or deeper.  Thus, the daunting task of making water adapt in a predictable fashion to a randomly generated environment is quickly turned into a simple case of taking a step back, looking at how water works in the real world, developing rules that fit the natural manner of a liquid, and manipulating a single value, the percentage of fill, to represent that behavior in each cell of a grid.

So I decided to start a new serious game project; lately I’ve just been tinkering around with random concepts without a cohesive game with which I can put a real bit of gameplay. So, today, I started a project that has a little green guy who can shoot an enemy that will bite when you come near and an enemy that can fly around and he’ll freeze and turn into a platform when you press his button (or die if you shoot him). It’s playable at this point, and darn near complete in what it does; it’s not really buggy, and all of the elements that I currently have in it, like the enemies, are pretty well-polished. Obviously, though, there isn’t much of a game there, so I’m going to have to expand. The main issue, however, is that I don’t really have a main mechanic to build the game on… Right now it’s just another mindless platform shooter. I’d like to keep the level design from getting too intense with puzzle elements, but I also want to keep things interesting. Any ideas?

Note: It will be iPhone compatible, so no crazy button-frenzy controls!  I want it to have the player only ever use left, right, jump, and shoot buttons, which will be placed in a static position on the screen.  Beyond that, it has to be something that at least isn’t used frequently like jump or shoot; a power-up activation button or something would be okay.

 

So I did some more messing around with my softbody simulation, staying up to an ungodly hour, and I managed to get some relatively stable collisions along filled figures like circles, rectangles, and triangles using some work with formulas I found in this article. The article gives a nice overview of softbody physics, and I got some nice results for the collisions when I grabbed a couple formulas (geez, those given values were not easy to find…). Anyway, the game is a bit laggy now, sadly, so optimization is going to have to come before I throw anything public with it. I really would like to stay off of the iPad or iOS devices considering how limited it will be in the FPS department, but having the multi-touch on the screen really puts me over the edge; it’s just not the same on a computer. I’ll put up a version to play online at some point, if I decide against the Kickstarter project (mentioned in the last blog post) or if it fails on me, but it’ll be a bit before I know whether or not it’s a good time to release. Here’s another picture with me grabbing one of the nodes and the bottom part hitting a floating circle:

I just started an experiment yesterday in using Verlet Physics Integration to make a multi-touch softbody physics engine on my Dad’s iPad, and I made a cool little app where you place nodes (grid or not), then you can press play to run the app using the soft physics and your shape(s) that you made. You can connect different nodes, and you can delete them and such to play around with it. It’s a bit of fun, but there’s not a ton of replayability thus far; basically just messing around for a moment. I want to make it so that I can get some softbody collisions in there, but I’m having difficulty getting it running, so disconnected objects pretty well ignore each other altogether.

One cool feature is that you can grab up to eleven vertices when playing around, which is a ton of fun. I’ve gotten all ten fingers each grabbing a node and stretching the shape out, which is cool to throw around in different ways. Below is a picture of me grabbing with three fingers:

This little app is functional for browser play, without the multi-touch, but I think I may wait because I’m planning to open up donations for a possible Kickstarter project where I will take on making 15 small flash toys (like the others I have been making recently, i.e. Conglomerater, Blocks, and Mold) over the span of 30 days from June 1 – July 1. I may mess around with the number of programs (possibly reduce it to ten, in case I’m over-estimating my ability), but I would put it up for about $3,000 minimum of donations to fully fund it over 30 days in May. We’ll see how it goes, but I’d really like to do this, yet I’d need the money to pay for it.

In this post, I’m going to show how to take a normal Flash project made in FlashDevelop and make it work for your iDevices.

First, you’ll need to download Adobe AIR 2.6 and start a project using it.  Then, you can simply copy-paste your game with all of it’s contents into this new project and compile.  Starting with this new, AIR 2.6 compiled SWF, you can start the process of making it work for an iPhone/iPod Touch/iPad device.  At the very end of the tutorial, I will have packaging .bat files and an example XML app descriptor file.

Another tutorial for this development process can be found here.  Yet another using Flash Builder instead of FlashDevelop can be found here.

1.  You’re going to need to become an Apple Developer to get this to work; it costs $99 for app development.  You will not need an actual Mac to do any of the following sections, except for the final upload of the app, as that must be done using the App Loader that only works on Mac computers.  I personally just used Windows for the whole of development, and simply had a friend of mine do the actual uploading of the App.

2.  Install OpenSSL for Windows.  This will be needed in order to make a Certificate Signing Request (CSR). Here is a .bat file you can run that will accomplish this for you:

path %PATH%;C:\OPENSSL FILEPATH\bin
openssl genrsa -out -passout pass:YOURPASSWORD mykey.key 2048
openssl req -new -key mykey.key ^
-out CERTIFICATESIGNINGREQUESTFILENAME.certSigningRequest ^
-subj “/emailAddress=YOUREMAIL@example.com, CN=YOUR NAME, C=US”

3.  Using your new CSR, you can upload it to your Apple Developer Provisioning Portal (under “Certificates”) to get a certificate.  If you are working individually (essentially, there’s no team admin who will need to approve your certificate) just reload the page and you should be able to download the certificate file.  This file will be named “developer_identity.cer”.  Using this, you can now attach provisioning profiles to it (we haven’t made any yet, so don’t be surprised if you can’t!), as shown below with the attached “Home” and “Connor Ullmann” profiles attached to mine.

4.  Next, plug in a device you want to test your program with and open up iTunes.  Click on the device’s name, and open up the summary.  There, you will see the Name, Capacity, Software Version, and the Serial Number.  Click on the serial number, and you will see the Unique Device ID (UDID) appear in its place.

Now, go to the “Devices” tab in the Provisioning Portal and click “Add Devices.”  Enter the name of your device, and enter in the 40-character UDID.

5.  Let’s make an App ID!  Go to the “App ID” section in the Provisioning Portal and click “New App ID” in the upper-right.  Fill out the form with a name like “Quietus” for my game Quietus, have a new seed be generated in the drop-down menu, and make a suffix that goes by the form of “com.yourname.appname”.

6.  We can now make a provisioning profile that will allow this device to run a program you put on it; you can’t simply put your app on any device, as with the Android App Store without it making it through a review by Apple in the Apple App Store.  To make a provisioning profile, go to the “Provisioning” tab in the Provisioning Portal and click on the “New Profile” button, or simply click here.  Add any device you wish to allow to run with this provisioning profile, and click submit.  Then, you can now hit “Download” to the right of the profile table to download the provisioning profile (it’s file-extension is .mobileprovision).

7.  With iTunes open and synced with your device, open up the folder with the newly downloaded provisioning profile and drop it into iTunes.  Now, sync your device with iTunes again.

8.  Execute this .bat with the path for you OpenSSL’s bin directory, and you will get a p12 certificate.

path %PATH%;C:\OPENSSL FILEPATH\bin
openssl x509 -in developer_identity.cer -inform DER ^
-out developer_pem_identity.pem -outform PEM
set RANDOM=.rnd
openssl pkcs12 -export -inkey mykey.key ^
-in developer_pem_identity.pem -out iphone_dev.p12

9.  At this point, you will have a plethora of different files, like your CSR, your CER, your .mobileprovision, your mykey.key, your iphone_dev.p12, etc.  For the most part, you will be able to ignore all of them except for the .p12, which will be packaged with all of your files (the SWF, the p12, the app descriptor XML file, the default start-up images, and the icon images) in the final .ipa which will run on your device.  Make the appropriate changes to this template below for your application descriptor file (save as “application.xml”, for example):
More information about the XML document can be found here.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<application xmlns=”http://ns.adobe.com/air/application/2.6″>

<id>com.yournamefromappid.appnamefromappid</id>
<versionNumber>1.0</versionNumber>
<filename>APP NAME (put what you like, like “MyAppiOS”)</filename>
<name>NAME (this shows on the actual iPod as the name)</name>
<description>APP DESCRIPTION</description>
<copyright>YOUR NAME</copyright>

<initialWindow>
<title>ARBITRARYWINDOWNAME</title>
<content>INPUTSWFFILENAME.swf</content>
<systemChrome>standard</systemChrome>
<transparent>false</transparent>
<visible>true</visible>
<minimizable>true</minimizable>
<autoOrients>false</autoOrients>
<resizable>false</resizable>
<renderMode>gpu</renderMode>
<fullScreen>true</fullScreen>
<aspectRatio>landscape</aspectRatio>
</initialWindow>

<icon>
<image29x29>ICON29x29.png</image29x29>
<image48x48>ICON48x48.png</image48x48>
<image57x57>ICON57x57.png</image57x57>
<image72x72>ICON72x72.png</image72x72>
<image512x512>ICON512x512.png</image512x512>
</icon>

<supportedProfiles>mobileDevice desktop</supportedProfiles>

<iPhone>
<InfoAdditions>
<![CDATA[
<key>UIStatusBarStyle</key>
<string>UIStatusBarStyleBlackOpaque</string>
<key>UIRequiresPersistentWiFi</key>
<string>NO</string>
<key>UIDeviceFamily</key>
<array>
<string>1</string>
<string>2</string>
</array>
]]>
</InfoAdditions>
</iPhone>

</application>

10.  When you have compiled your SWF file and have finished all of the previous steps, you will be able to package your application.  In the same folder that you run the final packaging .bat file from, you will need the SWF, the p12, you app descriptor XML, your .mobileprovision file, your icon images (size 29×29, 48×48, 57×57, 72×72, and 512×512), and default images to show just before start-up (called Default.png, Default-Portrait.png, and Default-Landscape.png; these will make your app seem as though it’s loading faster by showing an image directly before the app actually starts). Below is an example image of my project “Quietus” before packaging with all of the necessary files:

Here is a .bat that you will run, with the necessary changes:
Note: when executing this .bat file, if you are asked for a password, use the password you entered when making your key in step 2.

path %PATH%;C:\AIR 2.6 FILEPATH\bin\
adt -package ^
-target ipa-test -provisioning-profile MOBILEPROVISIONFILENAME.mobileprovision ^
-keystore P12FILENAME.p12 -storetype pkcs12 ^
OUTPUTIPAFILENAME.ipa APPINFOXMLFILENAME.xml INPUTSWFFILENAME.swf ^
ICON29x29.png ICON48x48.png ICON57x57.png ICON72x72.png ICON512x512.png ^
Default.png Default-Landscape.png Default-Portrait.png

11. This .bat will output a .ipa file; this is the final app file that you will be able to play on a device that is allowed to use it, as given when you set up the provisioning profile. To try this out, just drag and drop the .ipa file into your iTunes and sync your device. If everything works out, your device should now have your app on it, and it should run!

Final Notes: Here’s a little bit of iPod/iPhone/iPad information. AIR 2.6 only works on iPhone/iPod Touch 3GS+, and works on both iPads, so iPhone 3G isn’t supported. Also, the iPod/iPhone resolution is 960×640 with the retina display, and the iPad is 1024×768.

I hope you enjoy making iOS apps, and I will be happy to answer any questions in the comments!

 

It’s made its way through the labyrinthine maze that is the Apple review service, and it is now playable on the App Store!  It is ready to go for iPhone (3gs+), iPod Touch (3rd gen+), and iPad, and it costs a whopping $0.99; help the cause, give me money to feed my Wendy’s addiction!

 

Reviews:
IndieGames Blog
Appolicious
iFanzine
Games Radar

 

Below are links to some reviews of Quietus when it was released for PC:
JayIsGames
IndieGames Blog
DIYGamer
Kotaku AU
Bytejacker (voted the winner in the Free Indie Rapidfire)
AV Club
E4
Canard PC
Game Polisher Radio
FlashPunk

Just to let you all know, I will be doing quite a bit of development for iOS in the future. My next several games should be fully playable on iOS devices, and the controls schemes will be tailored for one-touch play. I hope you enjoy Quietus for the App Store as much as it was loved for PC, and I hope it keeps you coming back for Quietus II when it hits for computer and mobile platforms!

iTunes Store

I posted 8 art pieces to my previously astonishing collection of one. These were all drawn in the past year using my drawing tablet on a laptop, and they were a lot of fun to draw.  The weirdest one, that being the really colorful “Trippy Beast” was my first foray into doing some art that is just plain random.

A lot of the reason I don’t draw very often is that I see drawing pictures as something akin to “lazy game development.”  Essentially, if I like an idea enough to do a very large, dramatic, scenic picture of it, I might as well make a game where the elements of it actually interact.  For that reason, most of my drawings tend to be something that would be hard to represent in a game with the level of animation capability I have, or they are simply because I was too lazy to attempt a full game with the idea.

So I’ve been doing some pretty big working getting some work done with making mobile applications.  I started out doing some work with iOS with Flash on Windows 7, but it turned out that the Adobe Packager for iPhone was a total deadweight and I couldn’t scratch more than 9 / 60 FPS at best with a simple program that just told me that FPS.  I gave this up, and I moved on to working on the BlackBerry Playbook, which has a sweet deal where any developer who gets an app submitted by March 31, 2011 gets a free-bee Playbook!  I submitted Quietus II mobile after some tweaking with the controls, and I’m hoping to catch on with this deal.  I’ve run into some trouble getting the signing keys from them, however, so it may end up breaking the deal since the app is doomed if I don’t get them in time for the deal.  Fingers crossed!  Below is a screenshot of the playbook version of Quietus II:

So I finished up this version and submitted to the BlackBerry App Store; it was really nice, because porting the game was incredibly easy, even with having to make the new movement system.  Following this, I found out that the day after I quit working on the App Store with Flash stuff, they released Adobe AIR 2.6, which makes Flash run much faster on iDevices; this meant I could go back to making myself some games for iOS!  So, in a night or two I managed to put Quietus II on iPad running at 25/60 FPS, which works very well considering it’s still above the 24 FPS minimum for eye check period (makes it so the game doesn’t appear laggy, just slower) and because slowing the game down for unfamiliar controls is something I would’ve wanted to do in the first place.

With some input from Vieko Franetovic, I’ve got Quietus up and running on iPad and I’m submitting it to the App Store.  Sad story of it all is that I’ve managed tog et through every step of the process on a Windows computer, down to packaging the app for upload and even filling out the app profile with the version number, icons, screenshots, etc., but the final act of putting it up for approval has to be done on a Mac.  It appears there’s no way around it, so I’m putting it up via Mac.

On another note, I’ve put up a few different programs for cellular automata, destructible terrain, and a weird 2D string ball that looks like it’s morph-rotating in 3D space (turns out it was an accident in the programs math that made it look like that).  These programs were never really shown outside my computer, so enjoy the fact they haven’t been played by very many people!  Lastly, Robot Climb was released across the internet after the 7 day sponsor period on Retromundi.com, so try it out on the games page here.

Thanks for reading!  I’ll try to put out more updates on what I’m doing as things progress, and I’ll keep putting out my little flash toys as I go.  Bye!

Finally it is up and going with a great design thanks to Noel Berry!  On here I will be posting any flash web toys and games that I make, along with art and general blog entries about my life and what’s going on with my games and such.  Keep an eye out for a bunch of new content, because I’ll be putting up my work over the past year or so as often as I can!