Archive for the ‘Technical’ Category
Detecting Multitasking Gestures
Thursday, July 26th, 2012
Wow, it has been a really long time since I wrote up a technical post here. But I finally had a technical challenge today that felt worth sharing, so here it goes!
As you may know, I’m working on a new game called Finger Tied. The game is a multi-touch puzzle game. Some of the levels require that you drag 4 fingers around on the screen at once. I sent an early build out to a limited set of testers yesterday afternoon and a few reported problems playing the 4-finger levels. This is why: Multitasking Gestures.
A while back Apple added a feature to iOS called Multitasking Gestures. This feature is turned on by default on the iPad, I believe. When it is active, you can use 4- or 5-finger gestures to do things like switch between running apps, close the active app, or bring up the multitasking bar. The problem is, as developers, we have absolutely no control over this. As far as I can tell, we can’t even query the OS to ask it if the feature is turned on, and we certainly can’t temporarily override the behaviour.
So testers were running into problems where they would start to play a level with 4 fingers, and the app would close. Or their iPad would switch to another app, etc. I had seen some other games bring up a message on first launch that say things like:
“Please disable Multitasking Gestures to play this game properly.”
But I don’t like the idea of ruining that initial play experience with a text-heavy popup that might not even be needed. I figured there had to be a way to detect when one of those gestures has happened. I started looking at what events I get in the game just before the gesture is captured at the OS level. It turns out, your app will receive a touches cancelled event when one of these gestures is captured. I realized I could use this in the game.
Here’s some pseudocode that runs inside touchesCancelled:
if (number of touches cancelled >= 4) save a BOOL that says a gesture was used |
Any time I get 4 or more cancelled touches at the same time, I’ll save out that boolean value to NSUserDefaults. Now, the next time the user launches a level I do this:
gestureUsed = get saved BOOL value if (gestureUsed && level requires >= 4 fingers) display a popup explaining how to turn off Multitasking Gestures clear the saved BOOL value from the save file |
This means that the user can play through levels that don’t require 4 fingers to play without ever seeing that message. It also means if they never use a multitasking gesture (or have them turned off), they’ll never see the message. It’s only if they use a gesture and then try to play a level that needs 4 fingers that they’ll see it.
I also force the same check on applicationDidBecomeActive so that I catch the cases where the Gesture happened mid-level and the user was dumped out of the game. This means that in the case where the user has Gestures turned on (but doesn’t use them), then tries to play a 4-finger level, if they accidentally trigger a Gesture then return immediately to the game, the game will immediately pop this message up giving them an explanation of what happened.
However, this is not foolproof. Because I want to try to catch as many cases as possible, this code can generate some false positives in the following case:
- Player has Gestures enabled
- Player enters the game, then uses a Gesture to switch to another app (this will save that a Gesture occurred)
- Player returns to the game, realizes their Gestures will interfere with the app
- Player quits the game and turns off Gestures in the OS settings
- Player reenters the game, plays a 4-finger level
- The game will present the Gesture warning dialog
The other false positive that could happen occurs when a player places 4 fingers on the iPad, then drags all 4 fingers off the screen in the same frame of execution. In that case you would also get 4 touches cancelled in one event, but it would be extremely rare.
Update (2012-07-27): As Alex pointed out in the comments, you’ll also get 4 touches cancelled in the case where the user has 4 fingers on the screen then presses the Home button on the iPad. Again, I believe this is a rare enough occurrence that I’m OK with a few potential false-positives in order to catch the real ones.
So, it’s not perfect, but these are cases I can live with.
Finally, since I haven’t ever submitted this code to Apple, I make no guarantees that it will pass review. This is also untested against iOS 6, so it might fail down the road. Use at your own risk. 🙂
Owen
Prototyping with Codea
Wednesday, November 30th, 2011
UPDATE: Since writing this, the developers of Codea have released an impressive number of huge updates to Codea. They have implemented many of the features I was hoping for, as well as many others. Go check it out if you’re at all interested.
It’s not very often that I talk about other games or apps on my blog, but I want to make an exception today to talk about a cool iPad app called Codea by developers TwoLivesLeft. This is a new iPad app that lets you write Lua code on your iPad and run it in-app. This means that you can use Codea to write and play game prototypes on your iPad. Say whaaaat?! Yes, on your iPad.
I first started hearing about the app on twitter a little before release, as some friends of mine were beta testing it. When it launched, I decided to check it out, long having wished for some way to write and run code on my iPad. I’ve spent several hours with it, and I’m quite impressed so far.
The first thing you need to know is that this will not let you create incredibly complex stuff. It’s 2D only, and it has a limited set of API calls available. However, what it is, is a fantastic prototyping tool, as long as you don’t mind typing on your iPad. They provide APIs that allow you to handle touches, and even accelerometer input. They also provide some basic vector graphic drawing tools (draw lines, rectangles, and ellipses). They even include Daniel Cook’s open source sprite collections, so that you can do some basic sprite work.
When I started playing around with it, two things annoyed me almost immediately:
- There was no font support
- There was no way to add my own sprites to the app
However, in reading through the (very active) forums, I discovered a bunch of people sharing code to solve problems. One person wrote a vector-based font rendering class and shared it. I’m now using that and it’s great. Others pointed out that by using tools like iExplorer to access the iPad’s file system, you can dump folders of sprites into the app and have them show up. However, I quickly discovered was that I find myself using vector graphics for eveything instead of sprites. This keeps me focused on working on gameplay prototyping instead of getting bogged down in Photoshop doing pixel pushing to procrastinate. TwoLivesLeft say they’re also working on getting a bunch of this stuff working in future updates, so I can only see it getting better.
However, there are still some things you should be aware of:
- Right now there’s no way to get code to/from the app, except via copying/pasting, or using iExplorer
- Support for Undo/Redo is pretty limited right now
- You can’t (nor will you ever be able to) export a game right from Codea to the App Store
- There’s no way to share code/projects with anyone else from within the app
But these are limitations I’m OK with. Having some way to retrieve files and drop new files in from my computer would be pretty great, though. I’m missing not having any kind of source control on my files. 😉
Finally, I thought I’d share a screenshot of the game prototype I’ve been working on in Codea. This is for a word game concept I’ve been playing around with. What you see is about 4 hours of work. I have built a working button class, I can build words out of letter tiles, and the words detect touches.
The other cool thing is this is only 4 files of code, each no more than 100 lines of lua. The vector graphics make it very fast to get stuff quickly drawing, and with prototyping, that’s extremely important. And let’s not forget that I can now write code while I’m not at my computer!
So yes, colour me impressed. The app is still a little rough in places, but the developers seem to be actively working on improving it. Even still, at under $10 it’s an amazing prototyping tool to have on my iPad.
Owen
* I chose to write this review on my own. I did not receive a review copy from the developer, nor did they request that I write anything. I just think their app is cool. 🙂
Universal OpenGL Apps
Sunday, November 28th, 2010
I recently took part in the 360iDev Game Jam remotely from home. The game jam is always a lot of fun, even if you can’t get yourself to the 360iDev conference itself (which you should totally do, by the way, if you can. It’s an amazing conference). I created a game in 8 hours which I’m calling “Dirty Diapers”, you can see the details of its creation on the Game Jam site. There’s a video of the game in action at the end of that page.
The game is about keeping a room full of babies happy. Over time, babies become unhappy because they either want to be fed, changed, or rocked. It’s your job to drag an action up from the bottom of the screen to make the baby happy again. As time goes on, they get more unhappy more frequently.
I think it turned out quite well, so I’ve decided to try to get it into the store at some point. Right now I’m extremely busy with some contract work, but I’m trying to find a few hours here and there to finish it up and submit it.
One of things I decided to try with this game was to build it as a universal app (that is, one app that runs on iPhone/iPod touch, and iPad, instead of separate apps for iPhone and iPad). The game is 100% OpenGL on the rendering side, so I needed to figure out how to set up my frame buffers for a universal app. I thought I’d go through that today. (Holy moly, a technical post instead of an indie lifestyle post! Hold on to your hats!)
Project Setup
The first thing you need to do for a universal app is set up your Xcode project so that it knows to build the app as universal. I went to Jeff LaMarche’s excellent blog and followed his instructions to do this part (and read the follow-up post for a few more details).
Once you’ve done that, you should have a project that can at least compile for iPad or iPhone. Good.
Frame Buffer Setup
Now that you’ve got your app building for multiple devices, you’re going to need to do some work to support multiple screen resolutions. As of this writing, there are three different resolutions to worry about:
- iPad: 1024 x 768
- iPhone/iPod touch (non-retina display): 320 x 480
- iPhone/iPod touch (retina display): 640 x 960
However, Apple does some clever stuff to help you with the retina displays. If you query the size of the screen:
CGRect screenFrame = [[UIScreen mainScreen] applicationFrame]; |
You’ll get 320 x 480 on both retina and non-retina displays. This is because they measure the screen in “points” instead of pixels now. On a retina display, there are 2 pixels for every point. The nice thing is that it lets you treat all iPhone/iPod touch screens the same way, with the same positioning code.
Ok, so we’ve got these different screen sizes, we need to tell OpenGL to create different sized frame buffers. Somewhere in your code you’ve probably got something like this, which creates a render buffer from an EAGLDrawable CAEAGLLayer:
glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle); [oglContext renderbufferStorage:GL_RENDERBUFFER_OES fromDrawable:drawable]; glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &buffer.m_width); glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_HEIGHT_OES, &buffer.m_height); |
If you build and run, what you’ll find is that your render buffer will be created with the proper size for iPad and non-retina displays, but you’ll end up with a 320 x 480 render buffer for retina displays (which need 640 x 960), and your retina display game will look awful. This is because the CAEAGLLayer is telling OpenGL that it’s dimensions are 320 x 480 on the retina display.
In order to remedy this, we need to make use of two new UIView properties found in iOS 4.0 and up called: scale and contentScaleFactor.
scale
The new scale property will tell you the amount the point values of the UIView are being scaled. If you’re running on a non-retina display and query a view’s scale, it will be 1.0. If you’re running on an retina display, you’ll find that it’s 2.0. This gives you a way to test which kind of display we’re working with, and we’ll use this later.
contentScaleFactor
The contentScaleFactor is a different beast. This will always be 1.0. However, if you’re running OpenGL in a view on a retina display, you need to set this value to match the scale value of the view. This will tell the CAEAGLLayer to update its dimensions to match the actual pixel size of the screen, allowing you to create an appropriately sized render buffer.
Now, if you’re planning to support iOS versions prior to 4.0, these properties won’t be available, so you need to do runtime checks for them.
This is what I do inside my EAGLView’s -layoutSubviews method to set the contentScaleFactor on the view:
// Set the scale factor to be the same as the main screen if ([self respondsToSelector: NSSelectorFromString(@"contentScaleFactor")]) { [self setContentScaleFactor:[[UIScreen mainScreen] scale]]; } |
Now, when I tell the render buffer to create itself based on the size of the layer, it will create a 640 x 960 render buffer on a retina display, but a 320 x 480 buffer on a non-retina display. Hooray! But, we’re not quite there yet…
Viewport Setup
We’ve got our render buffer set up to create itself at the proper resolution now. It will match the screen dimension and contentScaleFactor of the EAGLView, which is what we want. Now we need to tell OpenGL to create an appropriately sized viewport. This code is for a 2D game, so adjust as necessary for a 3D game.
You’ll need to create a viewport that matches the frame buffer size for the given screen. Something like this:
glViewport(0, 0, buffer.m_width, buffer.m_height); |
For a 2D game, you then need to set up an orthogonal projection. There’s a good chance that you have a line in your code somewhere that looks like this:
glOrthof(0.0f, 480.f, 320.f, 0.0f, -1.0f, 1.0f); |
Clearly this isn’t going to work. Now, there are two options here for creating the transform:
1) Create the transform based on the UIScreen size
The code for this is simple:
CGRect appFrame = [[UIScreen mainScreen] applicationFrame]; glOrthof(0.0f, appFrame.size.width, appFrame.size.height, 0.0f, -1.0f, 1.0f); |
However, let’s look at what this does. On iPad, it creates a 1024 x 768 sized viewport. Great, that’s what we want. On a non-retina display, it creates a 320 x 480 viewport. Also good. But, on a retina display, it also creates a 320 x 480 display. Now, this is OK. The framebuffer is 640 x 960, so the pixels are there. So what does this mean?
The Good
You only need to write two code paths for positioning sprites on the screen: one for iPad, and one for iPhone, and let OpenGL handle matching the render buffer to the viewport appropriately for you. The only caveat here is that you’ll need to manually scale all your sprites’ sizes by 50%. If you do this, you’ll scale them down to the correct point size, and then OpenGL will render them at 100% resolution when it pushes the textures through the render pipeline.
Confused? Think about it this way: you’ve got a view port of 320 x 480 but a render buffer of 640 x 960. Take a sprite that’s 100 pixels x 100 pixels and render it as a 100 x 100 point sprite in the viewport. This is actually 200 x 200 pixels in the render buffer. So in order to render it as 100 x 100 pixels, you need to scale your vertices down by 50% to a 50 x 50 point sprite.
The Bad
You’ll need to write some code into your sprite system (and bitmap font system) to scale things to 50% if you’re on a retina display.
This is the approach I use. At app startup, I get the screen scaling factor, and then use it to scale all my sprites:
if ([[UIScreen mainScreen] respondsToSelector: NSSelectorFromString(@"scale")]) { ScreenScaleFactor = [[UIScreen mainScreen] scale]; InverseScaleFactor = 1.f / ScreenScaleFactor; } |
2) Create the transform based on the layer size
The alternative is to create a different viewport size based on the actual pixel size of the screen. You can do this by getting the size of your created render buffer. Something like this:
glOrthof(0.0f, frameBuffer.m_width, frameBuffer.m_height, 0.0f, -1.0f, 1.0f); |
This will give you a viewport that matches the screen size in pixels, not points.
The Good
The advantage here is that you don’t need to do any sprite scaling. You just render everything at 100%.
The Bad
You’ll need to have three different code paths for sprite positioning, based on the size of the screen, as you’ll now have three different sized viewports to worry about.
Art Work
You’ll probably want to have different sized artwork for non-retina displays than for iPad and retina displays. For Dirty Diapers I’ve got two game texture atlases: one for iPad and retina displays, and one for non-retina displays. The non-retina atlas is identical to the larger one, it’s just scaled down 50% in Photoshop. You could scale your graphics in OpenGL, but it will never look as good. If you’re like me, the imperfections will just drive you nuts.
So I have two texture atlases, but there are 3 possible screen sizes to worry about (see the next section). I do a check like this to determine which texture atlas to load:
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad || ScreenSizeConsts::ScreenScaleFactor > 1.01f) { // Load texture atlas for iPad/Retina display } else { // Load texture atlas for Original iPhone display } |
If you want to load 3 different textures (iPad, non-retina, retina), you can use the @2x.png file naming convention (depending on how you’re loading your textures) and just check for iPad or not, but now you’re dealing with 3 sets of textures. The choice is yours. If you’re loading textures manually and the @2x trick doesn’t work, you can split things out like this:
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) { // Load texture atlas for iPad display } else if (ScreenSizeConsts::ScreenScaleFactor > 1.01f) { // Load texture atlas for Retina display } else { // Load texture atlas for Original iPhone display } |
Finally, Positioning
Now you’ve got your different artwork loading, you’ve got your render buffer set up, and your viewport set up. Now you just need to tell your objects to render in different positions, based on the screen. To do this, I set up a bunch of member variables for positioning code (for static items), and then on init, check the device and screen scale factors and adjust them accordingly. This is necessary for 2D art layout, but if you’re working with a viewport into a 3D world, you may not need to do nearly as much work here.
That’s it…
There you go. I hope you were able to follow along and I wasn’t too confusing. If you’ve got better ways of doing any of this, feel free to post suggestions in the comments.
Owen
Game Dev: Getting Started
Sunday, November 7th, 2010
A friend of mine sent me a message on Twitter the other day asking if I had any tips for someone looking to get started in game development. I mentioned this was quite a large question, so I asked him to narrow the scope of his question. He came back with “between idea and prototype.” That seemed like a good subject for a blog post!
So, you’ve got some programming under your belt. Maybe you’ve been building web site back ends, or accounting software, and you’d like to try your hand at games. Where do you start? If you’ve got an idea, how on earth do you approach the process of turning that idea into a prototype?
1. Consider Scope
I’m putting this right up front, because it’s the biggest and one of the most common traps a new developer can fall into: your idea is just too big. It’s very easy to bite off more than you can chew with a game idea. If you’ve never made a game before, don’t try to build a huge RPG in a massive world for your first game; you will almost certainly not finish it. What about something like tic-tac-toe instead? Or your favorite card game? Or a match-3 game (my first game, Dapple, was chosen because it had a very defined scope, and it still took nearly 6 months to make).
To put things into perspective: a triple-A Xbox 360 or PS3 game will have a team of 100-200 people working for 1-3 years on it. If you’re one person expecting to work on a game for six months, you need to make sure you’re working with an idea you can finish. You can’t build Halo by yourself. That’s ok. Pick a game idea you know you can finish; it will be challenging enough.
Also don’t forget that there are lots of parts to making a game that aren’t immediately obvious that you’ll need to build: menus, save systems, high score boards, platform specific requirements, etc, etc, etc. If you think your game is going to take you three months to make, bank on it taking six. So if you only have three months of savings to live off, maybe pick a game idea you think you can complete in a month and a half.
2. Learn About Games
This is a tough one, are you ready? You need to learn more about games. This means, yes, even playing other games for research. It’s a tough job, but someone’s got to do it. Take a look at other games in the genre that you’re targeting. Look at what they do well, and more importantly, what they don’t. What bugs you about the way they implemented things? What stands out as being done well? Are their menus clunky? Do the animations add that extra punch to really augment the gameplay? Does the music help draw you in? Take notes. Remember that you’re playing to learn, not just to have fun.
If you’re coming at this from a background other than game design, you may also need to do some reading. There are lots of great books written on the subject, and more being written every day, as the industry grows. See what expert game designers can teach you about designing games by reading their books.
One of my favourites, which is also a very quick read, is Raph Koster’s “A Theory of Fun for Game Design“. It’s great book to get you started thinking about designing games and what makes games fun. Another book I haven’t read yet, but have heard a lot of great things about, is Jesse Schell’s “The Art of Game Design: A Book of Lenses“. There are many other great ones, I’m sure. The important thing to remember is that making games is a constant learning experience, so get learning!
If you’re already a game developer reading this, what about you? What are you favourite books? What developer forums do you read? What blogs are the most useful?
3. Choose a Prototyping Technology
So you’ve got your idea and you’ve got some ideas about how to make it work as a game. Now you need to choose your technology for implementing a prototype. I gave a talk in April at the amazing 360iDev conference (their fall conference starts today in Austin) on rapid prototyping. One of the things I talked about is that when you’re prototyping, use whatever technology you are most comfortable with. This doesn’t have to be the same technology you’re going to implement the game with. If you’re targeting releasing an iOS game, but you’ve never touched Objective-C, but you’re a Flash wizard, prototype in Flash. If you’re an expert in javascript, prototype in javascript. If you’re not overly comfortable in any technology, prototype with pen and paper! Do whatever you need to do to get a working version of the game as quickly as possible. All the planning in the world won’t tell you whether or not the game is fun. Playing it will tell you that instantly.
If you’re doing iOS development, cocos2D is a fantastic platform with which to do 2D game prototyping. Flash is a great prototyping tool. If you’ve used Unity, I’m told it’s also great for prototyping. If you’ve got your own engine you’ve been building, use that, just be careful not to spend your prototyping time implementing engine features.
4. The 2-Minute Guide to Game Architecture
Ok, so what I’ve talked about is all well and good, but if you’ve never looked at game code before, you may be wondering how on earth a game works. This is obviously a HUGE topic, one that’s covered in immense detail in many books. However, I will attempt to give the extremely high level overview of how a game works. Ahem…wish me luck.
The Game Loop
At the heart of your game is a loop. This loop executes as long as the game is running. In fact, in many games, it’s a while (1) loop. In iOS development, you’ll be working with an event-driven timer instead. However it’s structured, the important thing is that you’ve got a chunk of code that’s going to execute over and over again. This chunk of code makes up one frame of execution. Most games aim for either 30 or 60 fps (frames per second). This means that your game loop needs to execute in less than 1/30 or 1/60 of a second.
At its most basic, your game loop is going to do two things every frame: update and then render.
The Update
This is where your per frame game logic resides. The update will do things like: pump the physics system (if there is one), update all the active animations, handle collision detection, etc. Basically, it updates the state of the game world in 1/30 or 1/60 second intervals. It says, 1/60 second has passed since the last time I was called, what needs to update? Oh, this character animation needs to be updated, these sprite positions needs to change, these two objects collided, etc. At the end of the update function, your game is in a new state and is ready for rendering.
The Render
Now that the world’s state has been updated, it’s time to render everything to the screen. This means going through all the renderable objects in the world and drawing them. If you’re using a graphics engine, then renderable objects (like sprites) may automatically get a draw() call made on them. If you’re using OpenGL or DirectX directly, then this is where you’ll be making calls into the graphics libraries to do the drawing yourself.
Building a rendering engine that runs quickly is an absolutely massive topic. You’ll need to pick up a book or two (and brush up on your 2D and 3D linear algebra, as well as low-level graphics hardware achitecture) if you’re going to roll your own.
Events
But let’s remember, games are interactive media. This means that at some point you need to handle user interaction with the game. This is often event-driven, in that it’s handled outside your main game loop. You’ll get calls into your code saying “this button was pressed” or “the user touched the screen here”. Some more traditional game loops would have input polling before the update was done. Many modern game frameworks (or platform APIs) rely much more heavily on event-driven code. Much more of your game logic will happen in your event handlers.
At any rate, these events are where you’re going to change game state based on what the user is doing. In a board game, the user might click a button to roll the dice, so your button click event handler is where you’ll trigger a dice roll. In a first-person shooter, you’ll be handling analog stick position updates to update the camera orientation and player’s position in the world.
You may also need to respond to system events, like an iPhone going to sleep, or the user alt-tabbing out of your full-screen game.
The Other Stuff
Those are the basics, but there is so much more that goes into a game: audio systems, user interface systems, front end menus, HUDs (heads up displays), physics systems, animation systems, game logic systems, font rendering systems, save game systems, leaderboard systems, achievement systems, and localization systems (to name but a few). But remember, not every game needs all of these things. That’s why it’s important to remember #1 and limit the scope of your first game.
The hardest thing about creating your first game is finishing it.
It will take dedication to work through the bugs and the tedious parts of building a game (yes, there are tedious parts), but in the end, it’s worth it. You’ll have a game that you made ready for the world to play and enjoy. So what are you waiting for? Start learning. Go make a game!
Owen
Finger Tied: A History
Thursday, December 13th, 2012
Yesterday I released a big update to Finger Tied (get it on the App Store) which enables the sharing of levels in the game. You can now share the levels you create, and download levels created by other players. I think it’s pretty cool, and I hope the players do too.
As I was working on the update, I started thinking back on the process of creating the game from start to finish. I like it when other people talk, in detail, about the process of creating their games, so I thought I’d do something to share the process of making Finger Tied. I wished I’d kept a diary or journal about the development of the game, but then I realized that I had the next best thing: my commit logs from my Git repo for the game. Every time I check in code or art, I add comments about what I accomplished.
With that in mind, I exported the logs and wrote a little PHP script to generate HTML code of all the commit comments. I’ve also gone back through my screenshots and pulled some that are relevant to given dates. I haven’t edited any of this, so you’ll see references to features that don’t appear in the finished game, because I decided to cut them.
The first commit comments are from Guelph Game Jam 3, in April, where I first prototyped the game. It was a game about planting flowers, called Trillium Fillium. From there you can see it involve into something more abstract and into the final game.
This post is long. I wouldn’t blame you if you don’t read it. I hope one or two of you find it interesting. 😉
Finger Tied: From Start to v1.1
Wed Apr 11
Sun Apr 15
Original Prototype created for Guelph Game Jam 3 (Apr 15, 2012).
Fri Apr 27
Mon Apr 30
Tue May 1
Wed May 2
Fri May 4
Sat May 5
Mon May 7
Tue May 8
Wed May 9
Sun May 27
Wed May 30
    Â
Fri Jun 1
Mon Jun 4
The style of the game is starting to come together.
Tue Jun 5
Wed Jun 6
Thu Jun 7
Fri Jun 8
Main Menu design is largely what shipped, though obviously with different colours.
Tue Jun 12
New colour palette is in the game.
Wed Jun 13
Fri Jun 15
Tue Jun 19
Wed Jun 20
Thu Jun 21
Fri Jun 22
Wed Jul 4
Mon Jul 16
Tue Jul 17
Wed Jul 18
Fri Jul 20
Mon Jul 23
Post Game screen. It’s becoming clear that lanscape orientation is becoming problematic.
Tue Jul 24
Wed Jul 25
Fri Jul 27
Game has been reworked to render in portrait orientation, making everything better.
Mon Jul 30
Tue Jul 31
Wed Aug 1
Fri Aug 31
Tue Sep 4
Thu Sep 6
Fri Sep 7
Mon Sep 10
Tue Sep 11
Final layout of the Level Select menus.
Wed Sep 12
Thu Sep 13
Fri Sep 14
Mon Sep 17
Tue Sep 18
Fri Sep 21
Sat Sep 22
Mon Sep 24
Tue Sep 25
Evolution of the icon design.
Fri Sep 28
Sat Sep 29
Sun Sep 30
Tue Oct 9
Fri Oct 19
Wed Oct 24
Fri Oct 26
Mon Oct 29
Tue Oct 30
Wed Oct 31
Fri Nov 2
Tue Nov 6
Fri Nov 9
Tue Nov 20
Mon Nov 26
Wed Nov 28
Fri Nov 30
Sat Dec 1
Sun Dec 2
Mon Dec 3
Tue Dec 4
Wed Dec 5
Fri Dec 7
Posted in Art, Business, Design, Finger Tied, ipad, Marketing, Misc, postmortem, Project Management, Technical | Comments Off on Finger Tied: A History