android computer games games design games industry games publishing iphone Unity3D

#Unity3d hardware usage + implications – Summer 2015

There’s tonnes of blogs out there, so I only talk about the bits that other people have missed, or were too polite or inexperienced to cover. Often that means I’m the one pointing out the flaws (most people don’t want to write bad things. Screw that; ignoring the bad points does you no favours!).

Sometimes I get to talk about the good bits that – sadly – few people have noticed. Here’s one of those.


Review: good SMS apps for Android

Why do we need this?

In a bizarre move, Google deleted the perfectly good SMS app from Android. Yeah. Hmm. Well, read this TechRadar piece for some thoughts on that.

Sadly, Google’s corporate policy is that the consumer is always wrong: you’re not allowed to simply “use the app I already had, that worked great”. Time for a trip to the Android App Store…

I tried:

Quick review of each


  1. does what it’s supposed to: show all conversations, send texts
  2. uses the “standard” view of SMS that we’re all accustomed to

…Deal breaker

  1. there’s no widget. Without a widget, you can’t get your phone to show “at a glance” new and recent SMS texts on the home screen / dashboard

Evolve SMS

  1. has a widget that works


  1. enormously unpleasant “forced swipe” control system. I’m not sure why. Maybe: “Facebook did it, and it sucked, so Facebook stopped. But we want to be Facebook, so let’s copy their failures!”
  2. the back button is actually broken. This is a core feature of Android, one of the biggest improvements compared to iPhone. And Evolve broke it. (Sad face).
  3. the widget can’t be resized. Fixed size widgets are a real pain – you can’t place them where you want, cant put the things you want on same screen, can’t control the info displayed


  1. basically works


  1. stupid forced-swipe control (see above)
  2. On first start, requires you to swipe in wrong direction
  3. no widget

Go SMS Pro

  1. has a widget!
  2. basically works, but ugly


  1. The widget WILL NOT DISPLAY incoming/recent texts. Instead it displays ONE text, and you have to hit buttons to “scroll” the widget to next / previous text. Wat?
  2. The app hangs if it’s not your “default SMS app”: you type something, it hangs. No other app had this problem, they all did a popup explaining, including a single-tap “fix this” button.


  1. has a widget
  2. looks really nice


  1. The widget … is simply “an ugly resized version of the app icon” … and it does nothing. Seriously, a developer chose to add this feature, and implemented … nothing. Wat?

Summary / Winners

TextSecure is a perfect recreation of ” an SMS app that just works, the way its supposed to” … Apart from the lack of widget (essential!). It even has Apple iPhone style “free text messages to other users of the app”. If they’d fix that missing widget, it would be worth paying for…

chompSMS is very much like TextSecure, perhaps slightly prettier (personal preference). But the broken widget is just as bad as TextSecure’s, maybe worse. And it lacks the “free SMS” mode and “secure SMS” modes of TextSecure.

Evolve has the only working widget (essential!). But … you’ll frequently exit the app unintentionally when you hit the back button. And it’s unusable unless you like “swipe all the time to control UI instead of using the back button” behaviour.

Final thoughts

The rest … are not winners. I’m using TextSecure for now. When people say “people on Android don’t buy stuff”, partly it’s because the apps are incomplete: most of these apps haven’t been fully developed (how can you have a broken widget? Why did you launch without a widget? etc).

NB: as a developer, I can attest that “adding a widget” is very easy. It’s stressful the first time, and then you read the docs and examples, and realise “wow! this is going to be super quick to implement!”.

android Google? Doh! programming

Android Dev: Eclipse won’t start? Hangs at splash screen? Kill Mylyn…

For the last couple of months, one of our dev machines has been literally incapable of opening a simple Android project. It crashes every time, on startup, while displaying the Eclipse logo:

Screen Shot 2013-04-05 at 14.45.54

Re-installing everything had no effect. We tried everything, and the only thing that worked reliably was to keep deleting the project and re-synching from SVN every time we wanted to start Eclipse

Today I finally discovered the cause: Mylyn


Download link for Android ADT in 2013

Tonight I lost 30 minutes because Google’s Android team still has the wrong links on the download page of their website. Every few months someone from their team copy/pastes the wrong link back onto the page…

Android’s download page ( says:

“download …ADT and Tools … from ”

This is 50% true. The “Tools” are on that page (although some poor web design means you now have to jump through silly JavaScript hoops to see them – this is a new “feature”).

…but “ADT” has NOT been on that page for something like 2 years now. I am surprised that no-one cares enough to fix this. You can wipe your system and download 0.5 gigabytes of trash to replace it, hidden inside which is the ADT – but you cannot get to the ADT itself.

So, until the Android team checks their links and fixes their webpage, here’s the actual (official!) download page for ADT: – Google’s ADT download page, NB: IGNORE the part at the top, the actual link is in “Troubleshooting”, and has been there for 3+ years

amusing android bitching iphone

4 reasons NOT to install iOS 6

As a developer, I’ve been using iPhone’s since they first came out. I have to test my apps on every version!

iOS 6 is the first version of iOS “post Steve Jobs”. But it’s terrible – it seems to be a 2nd-rate product rushed out by a small team of startup programmers, working from their garage.

As a developer … I’m dismayed. Consumers are famously slow to change (en masse) – but they are neither stupid nor indifferent. Their tolerance is high, but not infinite. The iOS 6 experience is going to force a lot of people away from iPhones. Looks like we’ll be doing a lot more Android development in 2013 than I was expecting …

1. It will DELETE your photos

Yes, really. You can recover them (from what I’ve seen so far: all of them) if you use backup recovery tools. But seriously: WTF?

Many google hits for this, plenty on Apple’s own support forums, with no response from Apple.

Or … it will randomly delete half your photos (happened to a phone I saw).

Or … it will REDUCE the quality of all your photos until they become tiny pixellated blobs.

AND … photos taken after you upgrade iOS 6? Forget it – they’ll be inaccessible too.

Deleting people’s photos is – commercially – unforgivable. I was amazed the first time I saw this happen.

2. It crashes. A LOT.

Until iOS 6, Apple’s OS was getting better and better with each release. I don’t *try* to crash phones, but it happens accidentally when you use the phone a lot. But iOS 6 is a total disaster.

  • iOS 2: took me 3 days to crash it
  • iOS 3: took me 3 weeks to crash it
  • iOS 4: took me 3 months to crash it
  • iOS 5: …never managed to crash it…
  • iOS 6: took me 3 seconds to crash it

    To be clear: this is through normal usage, nothing special, nothing “developer-y”.

    The iOS 6 crash was 100% reproducible, triggered by simply moving an icon on Springboard to a differnt screen, and then hitting the home button. Wow.

    3. It removes GPS and Maps from your phone

    Apple’s “Maps” app simply Does. Not. Work.

    iOS 6 REMOVES Google Maps, and there is NO WAY to get it back.

    So, now … unless you buy an additional “mapping app” (and there are none that are as good as Google Maps, unless you spend a huge amount of money), then … that GPS chip in your phone, that’s part of the cost of the phone? For most people it’s now a hunk of useless metal.

    In the last 10 years, very little in mobile phones has changed the way people live their lives quite so much as the instant availability of detailed, accurate, maps with GPS no matter where you are on the planet.

    Apple says you can “use Google or Nokia maps by going to their websites and creating an icon on your home screen to their web app.”. Wow.

    4. You cannot return to iOS 5

    iOS 5 worked. It was stable. It had a GPS! and Maps!

    …but Apple forbids you from running it if you ever install iOS 6.

    As a developer, this has been a recurring nightmare: we had to make sure no-one ever upgraded a phone – even by accident. (as a developer: you test your app on every old version of iOS that you can. Not just on a simulator, but on each physical phone)

    Now consumers get to find out quite how (unnecessarily and unfairly) painful that process is…

android community entrepreneurship facebook Google? Doh! marketing and PR startup advice

Google’s Strengths & Weaknesses in 2012

In the past, I’ve had terrible advice from brilliant people. The best way to avoid that is to be careful to research the brilliant person and tailor your questions to avoid their weaknesses.

Tomorrow I’ll be meeting a bunch of people at Google London’s open day. I started by writing down a list of known strengths/weaknesses based on my knowledge and experience of the company and the people. Earlier this year I had some in depth meetings with Facebook, which gave me a fresh perspective on the similarities and differences. I think the list itself is interesting – modulo: it’s only my personal impressions:

google strengths

[comments in brackets to clarify some non-obvious points for anyone reading this]

  • innovating on the Web
  • bringing native tech to Web and making it as good as native
  • software development
  • worlds biggest/most popular search engine
  • …? focus on curation ?… [Page ranking etc is subtle curation]
  • tech brand associated with “quality”
  • massive scale advertising
  • algorithms for automating heuristic tasks (imperfect, vague domains)
  • enormous scale data manipulation
  • throwing hardware at impossible problems to make them possible [Street View]

google weaknesses

  • community [in general, but also specifically: Google Groups]
  • consumer marketing [many Googlers have said “we don’t need to; the brand is enough”]
  • building products that people want, rather than products Google staff enjoy [Wave, Buzz, Google Voice]
  • understanding consumers [Android]
android computer games dev-process games design programming

Prototyping: Chess Quest v0.4

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

Major changes:

  1. Enemies have health, and can be killed by touching them
  2. Performance is another 30% faster (should be running OK on most phones now?)
  3. Enemies have a direction indicator (not necessary right now, but it’ll become important in a later version…)

Download link

Chess Quest-0.4.0

android devdiary games design

Prototyping: Chess Quest v0.3

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

Three major changes:

  1. You have a health bar, and can die
  2. The trackball is now supported for movement
  3. Performance is literally 1.5x – 2x faster

Download link

Chess Quest-0.3.3

So, a friend of mine tried it out today, and he couldn’t move around at all – something wrong with his HTC Desire (even though I’ve been testing on near-identical phone, for some reason his phone was losing the input gestures). This evening I did some improvements and fixes until it began to work “tolerably” on his phone – and I threw in some new small features too.

It’s still test stuff – not indicative of the final gameplay, but I’m trying out different basic ways of achieveing the stuff I want to achieve in the later versions.

Overview of what’s changed

  • You have a very basic HUD
  • There’s a couple of coloured powerups scattered around – red restores health, green increases maximum health permanently
  • Enemies actually kill you now, every moment you’re touched by one, your health drains continuously
  • You can choose different levels at the start – I included one of the early test levels that was easy for me to upgrade with recent changes. I’ve got another one I can probably add quickly later (one which generates 100% random mazes each time you play)
  • The ultra-simple EntitySystem I’m using was running too slow. There’s no simple fix I can see – the ES really needs to be written for performance, if I want it to be high performance – but I was able to do a 10-lines-of-code workaround that took the worst piece of bad performance in my game and made it literally 5 times faster. That’s good enough for now!
  • Input system has changed *again* – the Android OS has poor input management, a bit buggy, with an inconsistent programming API, which *also* runs differently on different phones – so I keep trying to do as little work on this as possible. The Android OS is desperately trying to prevent me from doing any prototyping at all – it’s begging for me to write hundreds of lines of code to make up for Google’s inattention there – but if I do that, I will lose all the time I would have spent doing game design and dev, and the whole project will be a failure. So, yet again, I’m putting on a band-aid and dodging the rest for now. But … at least now you can use trackball instead of / in addition to swiping on the touchscreen
  • There’s an FPS counter on the screen
android devdiary games design programming

Prototyping: Chess Quest v0.2

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

A couple more hours work, a few more changes:

Overview of what’s changed

  • Obvious from the screenshot: added alternating black/white background tiles. I want it to feel like the traditional chessboard has become the “floors” of the dungeons/towers you’re exploring
  • Major fixes for collision detection: player and enemies now do pixel-precise collisions (previously, if e.g. a piece moved 5 pixels per tick, it would move either 0 pixels (if 5 would collide) or 5. Now it moves “as many pixels as it can before the collision happens”)
  • Major upgrade to renderering: instead of just “render everything, in random order” it now sorts all sprites once per frame. Each sprint is instantiated with a sort-layer; things in the same layer are rendered in random order, but before all things in the next layer
  • Minor tweaks to movement: not happy with this, but I found the “never stops moving” annoying. Now I find the “stops too easily” annoying.
  • Various experiments with zoom level – I tried 20px, 32px, 64px and 100px (very zoomed in!). I found 32 px was working nicest on the Nexus 1, so I’ve stuck with that for now. In a future build, I’ll probably bring back the option to switch to a zoom level of your choice.
  • Added Flurry: I’ve never done this with a prototype before, but then I’ve never prototyped in public :). I’ve added Flurry just so I can keep track of how many people are running the prototype; as I add to the prototype, I’ll start adding in-app feedback options, so you can effectively “vote” on things you like/dislike, and I’ll use Flurry to graph it all automatically.

Download link for this version

Version 0.2

android computer games devdiary games design

Game prototype: Chess Quest

Last weekend, I was playing around with some ideas for a Chess / RPG mashup. I did some prototyping with Android (because iPhone apps can’t be shared, and Java is much faster to debug than ObjC).

If you’ve got an Android phone, try this, and let me know if it runs:

There’s not much you can do – touch and drag on the screen to move up/down/left/right (you’re the Rook – hence no diagonal moves). Bishops and pawns wander around randomly, pawns slower than bishops.

UPDATED: if you rotate the screen sideways, it’ll randomly pick a different size / zoom level. There’s four sizes, from 20×20 squares up to 100×100 squares. Player moves at different speeds based on the size too.

I wanted to make it a dungeon-exploration style, but with a Chess theme – and (like in chess) each time you complete a dungeon (kill the boss) you get to “pawn” and switch your character to the chess piece you killed.

i.e. first boss would be the Rook, second the Bishop, third the Knight, etc.

…but I’m not sure I’ll stick with that. If I get some more time this weekend, I’ll prototype a bit more.

NB: the APK above might run slow – I’m interested if it looks jerky / doesn’t work on your phone. It runs fine on an old Nexus One.

android facebook programming project management social networking startup advice web 2.0

Is Google’s mistaken belief in the power of Product killing them?

Steve Yegge’s Google Platforms Rant is not so much a rant as a sign of someone fighting an inappropriate culture. We saw stuff like this a lot at NCsoft when people were trying to turn around the $100 million clusterf*ck that created hundreds of redundancies all the way to director level.

It’s a great article, but a couple of the key points resonated with my own experience of Google UK’s hiring practices a couple of years ago. There was clearly a lot wrong with the internal culture, but as an outsider I couldn’t quite put my finger on it. Here’s the crux of Steve’s post (but seriously – read the whole thing, it’s rich and meaty):

That one last thing that Google doesn’t do well is Platforms. We don’t understand platforms. We don’t “get” platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.

But no. No, it’s like our tenth or eleventh priority. Or fifteenth, I don’t know. It’s pretty low. There are a few teams who treat the idea very seriously, but most teams either don’t think about it all, ever, or only a small percentage of them think about it in a very small way.

It’s a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they’re building products. And a stubby service is a pretty pathetic service. Go back and look at that partial list of learnings from Amazon, and tell me which ones Stubby gives you out of the box. As far as I’m concerned, it’s none of them. Stubby’s great, but it’s like parts when you need a car.

…and finally, reading that, it clicked for me what I saw that was so wrong:

Google has forgotten what a Product is

“It’s a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they’re building products.”

That pair of sentences, back to back, is the problem: people outside Google would put the word “except” in between. Googlers put the word “because” in between. Google’s cultural definition of Product has got lost and perverted somewhere along the way, and now looks and smells like the real thing but is – to the rest of the world – a fake. Except Google – internally – can’t see this.

Every Googler I talked to worshipped at the altar of Product-as-King; three quarters of them would then – even in the same sentence – admit that they hated Product, didn’t believe in it, and felt it was a waste of time — “get out of my face with your product BS, and let me write beautiful code in my Ivory Towers, and leave me alone”.

They were smart people; they never said this explicitly (although one came very close – and you could see the moment when he had the thought: “oh crap; if anyone else hears I said that…”, then backtracked very hastily) – instead they frequently said mutually conflicting things, and dressed them up in enough abstractions that you could pretend that they weren’t conflicting. They were very good at it – I could tell there was a crack, but I couldn’t work out where the fault-line lay.

Google’s illusions of Product

As Steve puts it later on:

Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don’t get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: “So is it the Stalker API?” She got all glum and said “Yeah.” I mean, I was joking, but no… the only API call we offer is to get someone’s stream. So I guess the joke was on me.

Product. Platform. Since when have those been mutually exclusive? Not in this Millennium, I believe…

And even when Google gets over their hatred of Platform, even with something as simple as the pixels that their apps put on screen, they’ve jumped the shark:

You know how people are always saying Google is arrogant? I’m a Googler, so I get as irritated as you do when people say that. We’re not arrogant, by and large.

But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we’re being fools. You can attribute it to arrogance, or naivete, or whatever — it doesn’t matter in the end, because it’s foolishness. There IS no perfect product for everyone.

And so we wind up with a browser that doesn’t let you set the default font size. Talk about an affront to Accessibility. I mean, as I get older I’m actually going blind. For real. I’ve been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they’re quite brazen about it, and Fuck You if you’re blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.

It’s not just them. It’s everyone.

Any genuine Product person would run screaming from that situation – there’s nothing salvageable. It’s like someone coming to you with their design for a chocolate teapot: “Once you’ve had your tea, you can have a tasty chocolate treat too!”, leaving you wondering: where do I even start with trying to explain to this person what they’re missing?

android fixing your desktop funny Google? Doh! iphone

Google Street-View on iPhone: a lesson in UX design

Today I finally discovered that the iPhone has StreetView.

That means it’s only taken me THREE YEARS to find this secret feature that Google has worked very hard to make sure no-one ever uses.

The best bit? The top two Google results for “iPhone Streetview” were both incorrect, and useless – but claimed to “solve” the problem (one of them was a Yahoo answer, the other a blog).

Eventually, courtesy of this amusingly-titled (yet poor in terms of Google hits) blog post, I found the solution:

  1. There MUST be a pin on screen – either because:
    1. you did a search for a place, and Google has found it and created a pin
    2. you tapped the curled paper in bottom right, then pressed the “drop a pin” button (incidentally: instead of letting you “drop a pin”, that button arbitrarily sticks a non-moveable pin in the center of the (now-hidden) screen. Terrible UX and GUI design. Google’s designers: what were you thinking?)
  2. The popup that’s attached to the pin has a standard button, and a standard icon – BUT THAT ICON IS NOT AN ICON
    1. …it’s an invisible button…

When we’re building iPhone apps for clients, this comes up typically once on every project: if you want to do custom user-interfaces, do NOT make them look like Apple standard interfaces. Apple has trained 200 million (total number of i* devices) to expect that (in this case: ) “a map-popup has exactly one button”. You are fighting against the work of one of the richest companies on the planet, a company famous for its marketing, interface-design, and visual-obsessions.

Worse is if you then go and break all the standards on what a “button” should look like, so that (in Google’s case), they:

  1. Put something in the place that is reserved for a non-clickable icon
  2. Used an icon-image instead of a button-image
  3. Provided no other ways of triggering the feature…even though this is usually NOT the place the user would want to click to get that feature

I laughed out loud when I discovered this – 3 years it’s taken me to get this to work, and me a professional iPhone developer too! How long is it taking the average “normal” user? If nothing else had convinced me Google is fundamentally f***ed by their refusal to design for anything other than “engineers who are exactly like us (and the rest of you plebs don’t matter)”, this would have nailed it for me.

android entrepreneurship

Google: “A patent isn’t innovation. It’s the right to block someone else from innovating”

A delightful quote from Google.

Although equally, Florian Mueller has an interesting analysis on whetherGoogle really wants to kill patents – or just kill “patents which Google doesn’t already own”?

note that Google’s discussion of its intellectual property rights starts with patents. They could have started with copyright, trademarks and trade secrets, putting patents last. No, they put them first.

So are they against patents? It seems they like their own patents very much (including the absurd Google Doodle patent, which they spent ten years fighting for) and are only against other people’s and companies’ patents.

Based on their activity over the past 5 years, I’d say Florian’s view seems closer to the truth: as a corporation, they seem to be well aware of such things as patent law, but uninterested in doing anything about it until it suits them. That’s fine, but it makes people less interested in working with them when they later cry “foul!” … Google seems much like a fairweather friend, in reverse.

android computer games entity systems games design

LudumDare 21: Escape from the (Android) Pit

I couldn’t enter this LudumDare competition on a technicality, but here’s my entry which plays by the spirit of the rules. I took a total of 24 hours (out of 48), of which only 12 were actual design + development (see below). Hopefully next time I’ll be able to do it properly, and actually compete. I’ve kept to every rule, except that I did my 48 hours time-shifted :) from everyone else (two successive Sundays, instead of a contiguous Saturday + Sunday).

Screenshot + Android APK

Download link (APK – you need to know how to install APK’s manually (google it if you’re not sure, it only takes 5 seconds)):

Escape From the Pit


  1. Make a LudumDare entry as an Android application – none of this easy “make it in Flash” or “make it in java” stuff – let’s go for a full mobile game, designed, developed, and launched in exactly 2 days flat!
  2. Use an Entity System (c.f. my long-running series of articles, and also the public Wiki I created), and show that ES’s facilitate you writing new games VERY VERY QUICKLY
  3. Make a game that was mildly challenging and (almost) enjoyable

Failed to officially enter the competition, but otherwise succeeded…


LudumDare challenges you to write an entire game in under 2 days (technically: 48 hours – it’s up to you how much of that you sleep). You can’t even design it in advance – there’s a theme that’s only decided shortly before the 48 hours starts.

LudumDare was the weekend before last – but I had to work that weekend on urgent day-job stuff. Like: I had to work all day Saturday, and there was no way out of it. So I couldn’t do the same 48-hour stint as everyone else.

Also, I know from previous experience that the “48 hours in one stretch” is very different from – say – “12 hours for 4 days”. When you do a 24 or 48 hour game, you tend to only manage a certain percent of “productive” hours. The challenge of designing + building something from scratch forces you to keep taking “time off” to go think about what do next.

So, I kept a diary of hours worked, and hours taken “off” as well. I’m confident I’d have fitted all of this – development time AND down-time – into the 48 hours. But I had to spread it over 2 successive weekends :(.

Day 1

(3 hours) – install Eclipse and the Android plugin, and the Android SDK. Document what I’ve done (1 hour) and check I can re-do it at will. Google, please wise-up and fix your install process – it’s not changed in almost 2 years, and it SUCKS

(1 hour) – install some extra Android OS versions, get the emulator working correctly, get projects imported, get everything in source-control, get empty app running on hardware device. Ready to start project!

— NB: everything up to this line I should have done before the contest started. If I were the kind of person that had free time on weekdays. Which sadly I’m not —

(1 hour) – getting Android base classes up and running. Takes a while: Android is insanely badly designed for the “Core application” part. Needs hundreds of lines of code to make a Hello World app that *actually* works as an app (Google’s code example that does it in 4 lines is fake: no real app could do that).

(3 hours) – on the beach, not working

(4 hours) – upgrading the open source Entity System Libraries on to support a bunch of features I’ve been using for a while in my own projects. This required writing a lot of stuff from scratch (using my own old source as inspiration), and integrating some improvements from patches/forks that other people had submitted.

— NB: everything up to this line I could have done before the contest started. Interesting though that I thought this was going to be “about to start writing the actual game” and I’ve only finally got to the point where I can write my first line of game-code —

Day 2

(0.5 hours): trying to make textures in Photoshop. Photoshop really sucks. Half the online resources for making the kinds of textures I want require PSP’s unique filters/effects – useless :(.

(0.5 hours): get a single sprite to appear on screen. A couple of idiot errors in one of my libraries – plus Google’s Eclipse plugin being really really bad at understanding “the scroll bar” (bug in ADT: it implements the world’s only non-static scrollbar)

(1 hour): random maze generation (using: ) that makes nice mazes, printing out onto the screen, still with my default “starfield” background. Rotating the screen is causing the entire game-state to be regenerated – includkng the maze – which was an accident, but actually helped A LOT with testing the maze algorithm (just tilt to re-run the algorithm instantly)

(0.5 hours): learn how to do Android input-handling correctly; en-route, discover I’m missing the SDK docs, and set about downloading + installing them … + updating my blog instructions on how to install Android to include “SDK docs” as a section.

(2.5 hours): discovering MAJOR bugs in Google’s basic “touch handling” API for Android – including bugs on Google’s own website source code, and an API designer on crack who broke the core Java contract didn’t document it. Not Happy.

Day 3

(1 hour) – implementing a collision detection system that does proper swept-collisions, but works OK with the poor fine-grained control of touch input

(1 hour) – added filters to collision detection so I could have background images that the player will NOT collide with
(previously was colliding with every on-screen rendered sprite). Also added a very simple lighting system where squares that the player has walked close to or upon gradually light up, showing how much has been explored

(1 hour) – refined the user-controls so you can hold your finger still and character keeps moving in that direction. Added handling in collision-detection system to allow character to slide along walls and into side-passages without the player having to stop and be ultra-precise (pixel perfect!) in timing the change of direction.

(0.5 hours) – added an exit, fixed bugs in the maze-generation (if started on a right or bottom edge, it crashed)

(1 hour) – fix Android’s brain-dead handlig of Bitmaps, giving a big speed boost, and re-learning how to use DDBS memory-allocation-tracking. I’m now auto-caching each bitmap inside my Sprite object. Sigh. There’s no easy workaround: Google says “don’t use getter methods” but Google also says “don’t call our getDrawable method more than once”.

(1 hour) – added ghosts, made them move around the map nicely, and collide with player was *automatic* on first compile (freebie from using an Entity System!). Also made arrows float nicely in same place on screen even while scrolling.

(1 hour) merge code from laptop back to desktop. Finally add the “win” conditions that makes the app playable!

Source Code

To make this game, I improved the basic Java Entity System up on the ES Wiki, and added some usability improvements and features. I created a whole new page for it here:

NB: It’s called “Beta” simply meaning “second generation (beta == second letter of greek alphabet)”. Not because it’s a beta-quality release :).

Source code to the game itself is also up on github right now ––Escape-from-the-Pit – although that’s a closed repository at the moment. I want to double-check there’s nothing included that shouldn’t be before I set it to “public”.

android fixing your desktop programming

August 2011: Google’s install process for Android is still terrible

Following my own install-guide from Jan 2011 (because Google didn’t provide one at the time)…

  1. Google still doesn’t provide an install guide
  2. Eclipse is a *little* clearer on what to download – but only slightly
  3. on Mac OS X is *still* broken
  4. ADT is still “hidden” by Google for no good reason (my install guide still works)
  5. Google still blocks you from downloading any “Android OS platform” (this is a core part of the SDK that is *not* included in the SDK – you need it to make Android apps)

(also, in passing, I updated the instructions to be a lot clearer / a bit more idiot-proof. I just used them to do a fresh install, and it went smoothly – with fewer problems than trying to use Google’s auto-installer)

EDIT: On the plus side:

  1. My install guide spared me waiting for an extra 0.5Gb of Android OS platforms to download (I was able to copy/paste them on the hard-drive, no extra install work needed. Just don’t use the installer!)
  2. ADT v 12 is noticeably more stable and better-integrated with the Android emulator – auto-starting smoothly where previous versions needed you to lead them through baby steps on first-run

Which means the key problem from a year ago still holds today:

Google is still effectively blocking you from using Source Control on Android projects

And they wonder why people still prefer the pain of working with Apple…