IRL Gaming | In Real Life Gaming | Zombie Hood available now for iPhone

After months of hard work, Zombie Hood 1.4 is finally here, you can download or update via the iTunes store.

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.

Thanks again for your support we really do appreciate it

IRL Gaming 2012.

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
• Migrating data between versions of the app became very difficult
• Our data wasn’t secure – users with jail broken phones could basically change whatever they wanted whenever they wanted (and they did)
• Translating between tabular data and objects in JavaScript turned out to be fairly inefficient even with our own custom ORM libraries
• Moving data between our MongoDB driven API and our SQLite driven application was clunky and error prone
• 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.
• Light Weight – the entire NoSQL engine comes in at 600 lines of JavaScript code
• 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.

We could create a contacts collection and add a record as follows:

var json = require("com.irlgaming.jsondb");
var collection = json.factory("contacts");
collection.save({
nickname:"Jon"
full_name:"John Smith",
email:"john.smith@gmail.com",
phone:1234567889,
address:"13 Dobney Avenue, Wagga Wagga, NSW, Australia, 2650",
loc:{lat:-35.110, lng:147.377},
timestamp:(new Date()).getTime()
});
collection.commit();

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:

var o = collection.find({name:/smith/i}, {$limit:1, $sort:{timestamp:1}});

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?

var o = collection.find({loc:{$within:[[5, 5], 0.2]}}, {$sort:{nickname:2}});
for(var i=0; i Ti.API.info(o[i]);
}

Another example might be the user wanting to update all of John Smith’s records to set the phone number to 9090909 if the records were added less than a week ago:

collection.update({name:'John Smith', timestamp:{$gte:((new Date()).getTime() - 604800000)}}, {$set:{phone:9090909}});
collection.commit();

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.

Zombie Hood 1.3 update is here!

Based on some great user feedback and support, we’ve been working hard and we’re pleased to release our latest update.

Zombie Hood 1.3 update release notes

Loads of new features:

• Reduced app size by over 50% you can now install over a 3g connection
• Easier to get started, no account creation needed, start playing in just a few click!
• Replay the tutorial at anytime.
• Equip / Un-equip weapons for your battle
• Scavenge venues and places for ammo
• Sell your food for in-game cash
• Take on the zombie horde with the new .50cal Barrett or M1 Abrams tank
• Create a survival crew, the bigger your crew the stronger you become
• New leaderboards  [Top Players, Top Earners and Top Zombie Slayers]
• We’ve added the ability to include downloaded content for the game including weapons, awards, loot, and other treats

Bug fixes galore:

• Updated HUD that now includes stamina, health, cash, and attack and defence
• HUD added to loot screens to show updated stamina/health/cash values
• Updated account system, create an account only when you want to save your player data (SETTINGS – YOUR ACCOUNT)
• Replay the tutorial at any time
• Updated safehouse system in preparation for v1.4 changes
• Updated player Attack and Defence system in preparation for v1.4 changes which will include Player VS Player
• Updated activity indicator  – activity message now displays from the top of screen no longer blocking user actions
• Multitasking support added
• Too many stability and performance bugs fixes to list

Thanks to everyone for you support and for those of you that update to v1.3 here’s a little treat. Enter ‘ZOMBIESHMOMBIE‘ at the LOOT – TOP SECRET screen.

Finally, don’t forget to tell your friends to check out Zombie Hood.

After months of hard work and beta testing Zombie Hood is now available in the iTunes App store. Download and install today! Visit the  Zombie Hood official website for more information

Want early access to IRL Zombies?

All you have to do is head on over to http://www.irlgaming.com/beta/ and sign up today.

It only takes a couple of seconds and while your there, feel free to answer a couple of questions relating to some in-game content.

Thanks for your support and watch this space!

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.

Hey Guys,

Following on from my previous update, here are the details of the new IRL open source repository.

The repo is available at: https://github.com/dan-eyles/irlopen

At the moment you’ll find only a small amount of code – we’ve open sourced some generic HTTP utility libraries, our OAuth 1.0 classes and the Foursquare REST API interface we’ve developed.

Moving forward we’ll be porting this stuff over to use the PECL HTTP extension for PHP so the HttpRequest, HttpResponse, HttpCookie and HttpCookieJar classes will be deprecated.

A couple of test cases demonstrating how the Foursquare stuff works are available at: https://github.com/dan-eyles/irlopen/tree/master/foursquare/test

Good luck, and drop me a line at dan [at] irlgaming.net if you have any questions.

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:

Lifting the server siege... done.
Transactions: 14420 hits
Availability: 100.00 %
Elapsed time: 29.59 secs
Data transferred: 30.21 MB
Response time: 0.02 secs
Transaction rate: 487.33 trans/sec
Throughput: 1.02 MB/sec
Concurrency: 9.97
Successful transactions: 14420
Failed transactions: 0
Longest transaction: 0.12
Shortest transaction: 0.00

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:

Lifting the server siege... done.
Transactions: 13933 hits
Availability: 100.00 %
Elapsed time: 29.46 secs
Data transferred: 29.19 MB
Response time: 0.06 secs
Transaction rate: 472.95 trans/sec
Throughput: 0.99 MB/sec
Concurrency: 29.86
Successful transactions: 13933
Failed transactions: 0
Longest transaction: 0.85
Shortest transaction: 0.00

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.

Now check out the same test run with Varnish sitting in front of Nginx as a reverse proxy cache:

Lifting the server siege... done.
Transactions: 82120 hits
Availability: 100.00 %
Elapsed time: 29.42 secs
Data transferred: 172.06 MB
Response time: 0.01 secs
Transaction rate: 2791.30 trans/sec
Throughput: 5.85 MB/sec
Concurrency: 20.24
Successful transactions: 82120
Failed transactions: 0
Longest transaction: 0.05
Shortest transaction: 0.00

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.

Till next time.