Zombie Hood 1.4 has been a long time coming, we’ve worked really hard on this major update to the game, taking on board all of your complaints, comments, feedback and suggestions to give us what we think is our best update to date.

Zombie Hood 1.4 is jam packed with loads of new features, here’s a little taste:

Completely new Safehouse system that allows you to upgrade and build your Safehouse defences, the more your play the more safehouses you can get.

Player vs Player battles, scavenge for the best weapons, secure a big crew and then start taking on other players. This is an easy way to get XP and Cash.

All new zMart and coin system. We’ve made things a lot easier when it comes to purchasing better items for your loot stash, purchase coins or collect them the more you play.

New universal HUD. You can now equip weapons, recharge health and stamina all from your HUD.

OpenFeint and Game Center are now both supported.

More performance, UI, and game play fixes than we could possibly mention

Download or Update Zombie Hood 1.4 today, take a look around and let us know what you think.

Finally keep an eye out for a few hidden surprises inside the game, and don’t forget to tell you friends.

If you’ve spent any time building data driven applications on the Titanium Appcelerator platform you’ve probably had to deal with SQLite.

SQL databases (and particularly SQLite) are a great solution, but they can become a real pain when you’re prototyping or rapidly iterating the design of your application. Maintaining complicated databases schemas, figuring out indexes, and writing ugly embedded SQL queries can really slow down the pace your team works at and make your code difficult to maintain.

During the development of Zombie Hood this became a major issue for us as a team. SQLite proved to be unsuitable for a number of reasons:

It was slow and difficult to constantly modify, re-index and deploy a new schema every time we changed the application or added a new feature

Maintaining large embedded SQL queries turned out to be a maintenance nightmare in JavaScript

After version 1.2 of the app went live it became clear that SQLite was a bad fit for us. After researching better solutions we finally decided to build our own NoSQL data management solution. It works great, we love it, and now it’s available on the Open Mobile Marketplace for iOS developers.

If you’re comfortable working with JSON, and you’ve had a quick look at MongoDB then you’re already up to speed on how this module works. We designed the system from the ground up to be:

Secure – all data committed to and read from disk is signed so that it can’t be tampered with by users

File Based – we didn’t want to run a server on the handset, so all data committed to storage is encoded as JSON and stored in flat files. This also means that all your data is portable

MongoDB Compatible – we constantly shift data between our API and the user’s handset so JSONDB generates unique BSON Object Ids and MongoDate objects in accordance with the specification.

Flexible – JSONDB had to allow us to combine query expressions, conditional expressions and mutation expressions in any order. We also implemented the DBRef spec to allow references to objects between collections along with dynamic object reference resolution.

Single Context – single execution context apps are the only way to go in Appcelerator, so while JSONDB isn’t thread safe it runs in the same execution context as the app. This makes it lightning fast to perform queries and updates.

Simple – we wanted to get rid of ugly SQL queries and make everything object based, very similar to the way MongoDB queries work

Easy – no schema, no indexes, no complicated SQL. Just objects. That’s how JavaScript should be.

Geo-spatial Query Support – we needed to be able to perform geo-spatial queries on our data-set on the handset

So, let’s imagine an application where the user can add contacts to an address book, along with cartesian coordinates so that the records can be displayed on a map. A contact record might have a nickname, a full name, an email address, a phone number, and an address. We’ll also include some cartesian coordinates.

This creates a new contacts collection (or loads an existing one), creates a new record and commits it to storage. You would plug this into your contact management GUI so users can add contacts. Let’s imagine that your user has added a couple of hundred contacts to their collection and want to search through them to find John Smith based on his name:

This will return the first object with a name property matching “smith” ordered by creation date from oldest to newest. This is a pretty simple example, so what if the user wanted to retrieve a list of all contacts near them within a 1km radius ordered by nickname alphabetically?

Finally, if the user wanted to remove all records from their contact list that didn’t have phone numbers:

collection.remove({$exists:{phone:false}});
collection.commit();

These are really just a few very simple examples of just how powerful this module is. If you’d like to know more check out the product page on the Open Mobile Marketplace or drop us a line at ohlo@irlgaming.net.

Are you a survivor? If you are you’ll be pleased to know that Zombie Hood 1.4 is currently in development and tracking well for a release ASAP. Version 1.4 will have loads of new features PVP, Upgraded safehouse system, updated zMart, Game Center support and more. So please stay calm, sit back and relax and enjoy the Zombie Apocalypse or why not visit the iTunes store and rate and review Zombie Hood

A lot of people have been asking us about certain features inside Zombie Hood, so we figured we’re draft up a little primer to give you guys the heads up.

1. Scavenging

It’s the Zombie Apocalypse (duh) – you need to scavenge to survive. The scavenge screen is a list of venues in your immediate vicinity, you can search these venues for loot items (food, weapons, stamina, health). The loot breaks down like this

Food – This keeps you alive, you automatically consume the food items you find, if you don’t keep finding food you will start to lose health. You can also trade your food back for zombie hood bucks and keep a nice little bank roll happening in case you need a quick health recharge.

Health – Use the health items you find to heal yourself after scavenges and battles. When you’re out of health you can only scavenge venues listed as ‘medical’ which can include: Medical Centres, Hospitals, Pharmacies etc etc (you get the idea). If you try to scavenge a venue that is not a medical venue you can spend your Zombie Hood Bucks and purchase a health recharge and you’ll be good to go. Simple!

Stamina – You need stamina to scavenge, no stamina means no loot. So make sure you’re stocking up on Protein Bars and Energy Drink. Energy Drink recharges 2 bars of stamina and Protein Bars will recharge 1.Pro Tip: Your stamina also recharges over time, so if you’re out of Stamina just sit back and relax and in a few minutes you’ll be back scavenging for more loot.

Weapons – Zombies want your brains and you need to destroy theirs, the easiest way to do that is to scavenge some weapons. Weapons are more likely to be found in venues like hardware and sporting goods stores, police stations and similar. Equip the weapon you’d like to take out on your scavenges but don’t forget the fuel or ammo if its required. You can find that scavenging as well.

That’s Zombie Hood scavenging 101. But here’s one final tip: choose your battles wisely, if you find some great loot and engage a Zombie and lose, you’ll drop your loot running to safety. Sometimes its best to pull out of that scavenge early to make sure you secure that precious loot.

2. Awards

It’s all about bragging rights, the more you play the more awards you unlock and the higher up the leaderboard you go. The awards screen is where you can see what awards are available inside Zombie Hood as well as the awards you have achieved. Keep an eye out on this screen as new awards are added all the time.

3. Digitize your life.

Scavenging helps you find health and stamina, but there is also another way to add items to your loot stash. Head over to the LOOT – TOP SECRET screen and hit the ‘Scan Item‘ button and getting scanning. We’re adding new items all the time so make sure you scan your favourite items. Heres a quick example of some items that will give you in game treats.

Red Bull (standard) 250ml can [+1 enery drink]

V Energy Drink (standard + sugar free) 250ml can [+1 enery drink]

Monster Energy Drink (standard) can [+1 enery drink]

Mount Franklin Bottled Water (600ml) [+1 bottled water]

So there you have it, a few tips to make your survival a little bit easier. Please comment and let us know what else you’d like to see inside Zombie Hood in upcoming releases.

Before we start this update, we’d like to share some good news, IRL Gaming has been accepted into the first StartMate Australian start-up company incubator program.

This is going to be huge for IRL Gaming in helping develop and get our first App out and into the market place. You can read more about the program here StartMate. Out of around 85 applicants, IRL Gaming made it into the 5 start-ups selected for the program.

Now onto our update.

While Dan’s hard at work coding up an API storm Henry, Chris and myself have been getting stuck into the UX/UI (User Experience / User Interface) for ‘Zombies’.

Thanks to Henry’s huge effort on researching a lot of UI elements that work and don’t work for a game like ours, we’ve really started to make some good progress on what will be the UI for our initial release.

Below is a rough mock up of a potential Location list screen, similar to what you’d find in a lot of other location based apps, but with a difference; because you’re trying to survive the Zombie Apocalypse its best you check the ‘threat indicator’ before you search that venue or else you could end up in trouble.

Next up is another rough mock up of a potential layout showcasing the header of the screen. Because what you do drives you character in the game, its only fitting you get to customise your character any way you like.

Finally meet ‘Big Hoss’ he’s an example of a potential Zombie for inclusion into the game. He’s our Redneck/HillBilly Zombie, because we’re having a bunch of themed Zombies, you never know where he might pop up (Hint: Truck Stops, Gun Shows, Wal-Mart)

We’d love to get some feedback on these ideas, so please leave a comment below or drop us an email and let us know what you think.

It’s been a while since my last update so I figured I’d write a quick post to talk about what we’ve been working on over the last week or so.

As you may or may not know we recently purchased a couple of Ubuntu VPS over in the US of A to host our API code. At the moment we’re just testing the waters in terms of un-managed VPS hosting, and we may make the decision to switch to EC2 at some point in the future (more about that in another post). The main benefit in having hosting is being able to load test and harden our API code in preparation for our beta launch early next year.

We’re all pretty savvy when it comes to administrating Unix environments, so getting things set up hasn’t been all that challenging. Just for kicks here are the specs on our VPS systems:

Ubuntu 10.04 under OpenVZ

64-bit AMD dual core CPU

2 GB dedicated RAM

40 GB dedicated storage

1500 GB monthly transfer (in/out bound)

They’re not Gibsons, but they’re good enough to handle what we’re doing at the moment without breaking a sweat. When shopping around I was looking for a couple of boxen that would be pretty close to our development environment.

We’re running our entire system on both machines, this means we have the following stuff installed and running:

MySQL 5.1 (+server + client)

PHP 5.3.3 (+apc +curl +fpm +mcrypt +mbstring +mongo +mysql +cli)

MongoDB 1.6.5-rc1

Nginx 0.8.53

Varnish Cache 2.1.3

Our new server configuration is a departure from where we started out a couple of months back. Coming from a traditional LAMP development background my first choice was to use Apache, MySQL and PHP to put together the first cut of our API. Over the weeks and months since then I’ve slowly been evolving my ideas about what should drive our API and how it should all fit together.

Through my analysis of the usage patterns of our pre-beta testers it became pretty obvious that we were going to need server software that was able to handle massive concurrency without us being able to afford mountains of hardware. As much as I love Apache (and I really do), I had to look for something that would more effectively meet our needs. Nginx ended up being the right choice for us and so far it delivers on all the promises it makes. I’ll write a post in the future comparing the two servers and detailing our decision to switch – you may now await with baited breath. They’re very different beasts.

PHP is still a key component of the system, however it now represents a simple layer of glue between our application server, cache and persistence layer. We’ve gotten rid of the need for complicated frameworks and streamlined our code to integrate tightly with Nginx and Varnish. Our philosophy is that we want PHP to do what it’s good at – simple database interaction and output rendering – and leave the rest to more appropriate software solutions. We’re also running PHP inside PHP-FPM daemon as an Nginx back-end, which is a pretty big departure from our previous architecture.

We dropped Memcached in favour of Varnish. This wasn’t a hard decision since MongoDB already performs memory bound caching and we really needed something that cached rendered API output rather than tuples. With a bit of tweaking to our API code and some work on a socket based dynamic cache invalidation system for Varnish we should be ready to roll in a few weeks. If you don’t know about Varnish Cache then check out their site, it’s a tremendously handy piece of kit and works really well with Nginx.

So, to the benchmarks. Following is the output from Siege running the same test as our previous server siege on Apache2 on our dev environment:

Roughly 500 req/s with 10 concurrent threads, interestingly the results don’t change as we add more concurrent requests under Nginx. Check out the results from the same test with 30 concurrent threads:

The numbers are more or less the same; average response time is slightly higher and we have a slightly lower number of total requests, but still very impressive. Apache would have begun melting down under similar concurrent load.

Yikes! 2971 requests per second!! Of course, the test above represents a 100% hit rate on the cache, so you’d expect it to be fast. In reality we’ll probably be able to cache only a subset of our API responses, but this is still a great starting point and will definitely lighten the load for high demand resources that have low cache entropy (e.g. user profiles, mini-feeds, player statistics).

The real sticking point (for me, at least) at the moment is the use of MySQL for our OAuth store. We’ve made some changes to the schema provided by the oauth-php project in order to improve scalability, but I still have problems imagining MySQL being the right fit for our requirements in this case. One of the first projects I plan to undertake once the API goes live will be to put together an OAuth server implementation that uses Membase as the storage engine.

One last piece of news – we’ll be open sourcing some of our platform code in the coming weeks so you guys can use our work in your own projects. Hopefully we can help solve some of the technical problems we see folk struggling with elsewhere on the web.