Commercial time ...

"Refreshing and Healthful"

"This is your brain. This is your brain on drugs.
  Any questions?"

"All my men wear English Leather, or they
 wear nothing at all."

... over now.

Ah tv slogans, so lets get to the point of this pointless post - we're having a little break and some blog re-design coming for us. If everything works fine there will be no break, but hey - who knows ...

nGFX

I just noticed that when getting back to the prototype of "Dial Z" to continue with it. The best thing I could do with it, was to file it away (yeah I know it's just a pretty way of moving it to the trash).

I'm pretty sure I've nailed the control scheme for the time being and I did a lot of planing on this one before I started coding (I usually do, just not to this scale).
Brainstorming into a mindmap was quite fun and it revield a lot of things that needed reduction in order to get a game out of it. Being able to use it as a kind of todo sheet also helps to keep the bigger picture in view.

Speaking about views ...

First thing I'm going to code today (ok, start coding) will be the viewport. To get the "features" I want for it I'll need to do some rewriting on my tilebased scroller.
My first idea was to just use 2 of them with 2 additional layers for walls and sprites inbetween. In theory this would work out but also waste a good deal time, because some of the loops will have to run a few times. First for the floor scroller, then for the walls and last not least for the top scroller.

Combining that all into a speacial viewport class (and maybe reuse it later) will take some more planing and a good deal of copy and paste...

But first have a break and return to the dungeon generating code and see how I can fit the maps into the new scroller.

Well, we'll continue with this interesting post right after the next comercial. Or tomorrow.

nGFX

I've finally done enough non-game related stuff during the last couple of month that I really want to do a game now. Fiddling with easier concepts at first (read: the odd quick-money-game-in-a-day), I realized that's not what I want. There is a game that I'm thinking about for ages, which I have planned through in various stages - just to abandon it for something that promised to be done much quicker.

There is a certain pride to swallow when going down the quick money way and right now I'm not in the mood to do so - I want the real deal, a big game.

Walking down memory lane to the point when I went away from VB to make games - flash 5 was just released - there were a few holy grails for the game making flash world, the full blown RPG (only 2 kingdoms from our mate Lux I can remember to have played more than just a minute) and of course the odd Zelda(tm) clone (yet again only a handfull have seen the light and I can't remember to have played a single finished one).
Mine has been an "exploration game with random levels" (but you might have guessed that from the rnd level generation articles a damn while ago).

I'm quite confident that this time ... well we'll see.

Anyway, back to the title of this post - control.

I think one of the ways a player connects with the game is the control scheme - if the player doesn't like the controls, the game has to offer a lot more to make him want to play it. So let's have a look of what options there are.

But before I go into detail, a quick description of the game this controls are for:

• the player moves his character around a map
• the player needs to be able to shoot and/or attack enemies
• the player may need switch between "weapons" (or alternate attacks)
• the player needs to access some sort of inventory and interact with the game's menu

mouse control only

There are not many ways to imagine how this might work out, but here we go. Point the mouse to a spot where the character should go and click. OK, so far it works, IF we had a second mouse button (like the right click) we could assign firing a weapon to it. We cannot use right-click in flash (at least not for this purpose) so either we use a key for alternating click actions (space, ctrl or shift come to mind) - but that kind of defeats the idea of using a mouse only control. Though we could use icons to switch between modes (walking / firing), I doubt it'll really add to the experience, as it trades ease of control with rather complicated handling.

keyboard only

At a first glance this might be a good way to go, but I'm talking about real keyboard only control, read: not even using the mouse for menus ... and that's as much fun as it gets. My Virus game did that - and it worked surprisingly well, but consider that for navigating through a shop or your inventory. Yeah, fun - right.

moving with keyboard, aiming with mouse

Honestly I hate that. I know I'm in the minority here, but for me this only works well for "real" ego shooters (the good old Quake for instance and then I do prefer playing on the 360 using a controller), for a top-down view game it really turns me off. The first reason is that usually A,W,S,D is used, which I can use to move back, forth and strafe in something like Quake, but moving a character with that - I'm way to slow to dodge bullets or move precisely. Using the cursor keys is not my cup of tea either because they are too far away from any other key and it just feels not confortable to play this way (using the left hand to use the cursor keys). Still I have to consider this as alternative (and need to think about making the enemies harder then).

moving and aiming with keyboard, using mouse for interaction

Yes, that's something I can work with. My idea right now is that you use the cursor keys to move your character and just shoot in the same direction you're walking - pretty old school. In an early (and infinished flash 5 game I found on my hdd) this worked well when adding some sort of "lock" to the firing direction, so you could fire single shots into the moving direction or hold fire for a half second to "lock" the direction and then move freely while still firing into the locked direction (as long as you hold the fire button).

If you have your own arguments about how to control such a game, well just leave a comment.

nGFX

ps: Today is also the first development day, I hope to get the basic viewport coded using two tile based scrollers and a few distorted bitmaps - if things go well and I don't forget it there will be something like the x development diaries.

We're at the start of week 3 of the new game, Destroy More Cars, which unsurprisingly is the sequel to our Destroy All Cars game.

It's the first outing for our blitter engine, so I thought I'd touch on that quickly.


If you've read the previous post you'll see there that I recommend a blitter engine for CS5 / iPhone development so I've been working on ours so it's there ready for the next project.

At the core of the blitter is the Canvas class. This holds the bitmap we're plotting to, does the lock / unlock thing, clears the canvas when needed ( By copying the background bitmap on there rather than fillRect ) and calls the children display objects.

Next up is the PlayField class. These are in effect layers. When I code I usually create sprites as holders and add these to the stage in order to simulate IDE layers, the PlayField class is just the same really.

At the bottom of this hierarchy are the building blocks, the Bobs. These are just simple sprites that are plotted to the canvas using copyPixel ( I've started work on a ComplexBob class which uses draw(), slower but it supports all the things that copyPixel can't, such as scale, alpha, rotation etc. Pain in the arse to code though, so slightly on the backburner and I'm just using bitmap's as simple sprites in the mean time ).

To make this truly useful I've tried to copy the existing DisplayObject as closely as possible, so for example if we've got an animated bob we can use bob.gotoAndPlay(bob.currentframe+1), to add a bob to a playField it's as simple as playField.addChild(bob) etc.
Depth sorting is in there too which makes life so much simpler ( The PlayField class is basically a list manager, making sure the bobs are always in the order we want. That's all depth sorting is really, just specifying what order to plot things in ).

One thing I stumbled upon the other day was the very sexy stage.invalidate(); To put it simply it's a way of flagging up the stage has been made dirty ( Altered ). If you have a stage.addEventListener(Event.RENDER,update);
listener, then when a stage.invalidate() is called at the end of the frame just before plotting everything our update method is called ( Via the RENDER event ). This means we don't have to call the update method as we usually would during our enterFrame main loop, in effect it handles itself, like the real display list does.

With using that, Vector lists which we loop through, lock / unlock etc. it all runs pretty quickly. Benchmarks I find are always a bit throwaway unless they're part of a really detailed set of comparisons, it's so easy to put a bit of spin on them to prove your code is the fastest.
Obviously I can't be bothered to do proper benchmarks, so prepare for some spin. DMC is running 6 layers of parallax on a 640x480 screen. It's got a handful of box2D objects ( The images are bitmaps rather than plotted via the blitter ) . In the screen grab above I think it's running 70 rain particles, but when I was testing I cranked that up to 500 just to push things. We've also got up to 80 glass particles ( Those little blue pixels at the top right of the grab ), soft particles for the smoke ( It's the first time I've used for particles for that as opposed to just pre-rendered images ) and there are 20 bits of debris spinning around in 3D, along with car door which rotates around in 3D too. With all that running it didn't drop a frame, stayed at a rock solid 35fps.

I think damage maps may speed things up in certain situations, but I'm more than happy with how it's performing right now, so that can be done if it's needed.

And that dear reader is how our blitter works.

Squize.

I hate using such a search engine friendly title to a blog post, we normally bask in the willfully obscure, but as this may actually contain something of interest as opposed to the usual random words I figured it was worth at least trying to vaguely flag it up.

Let's start with a big caveat. I developed Zap using the beta version(s) of Flash CS5, and due to it's very nature it's not the final finished product. That means a couple of things, firstly that the launch version is going to be better than the one I used, the Flash team are really breaking their necks with the iPhone exporter and just doing great work. Secondly as it was beta software things are pretty fluid. I really honestly doubt that there are going to be any major changes so soon to release, but some of these tips may not be valid on release.
One last thing, being on the beta program means being under a NDA. In terms of this post it means I won't be going into technical things, performance or new API's etc. Think of this more as a primer which can hopefully give you a little head start than a sneak peek at what's under the hood.

Ok, the main thing is eeking out as much performance as you can.

* Vectors / Drawing API / Gradients. No, no and no. We're bitmaps all the way baby.
* BlendModes. Think more about burning the effect you want onto the bitmap itself.
* MovieClips. Save them for intros and title screens, avoid them in-game, as you just can't cache them efficiently so you're hitting the slower vector plotter.
* Text. It's slow enough when running in a swf. Time to code yourself a text plotter using bitmaps ( Like Movieclips, for in-game anyway. Top and Tails performance is never really a big issue )
* CacheAsBitmap. He's going to be your new best friend, love him and cherish him, as he'll give you much better performance ( There is a new cache command too, but NDA and all that ).
Some things to keep in mind, setting sprite.visible=false wipes the cache, so when you use sprite.visible=true again you're forcing a re-cache. Altering the alpha property also forces a re-cache ( As does scale etc. All the things I'm sure you're aware of any way ). One thing I didn't know before starting on Zap was that if you holder.removeChild(sprite) the cache is lost too, and that the cache only kicks in when the displayObject is first added to the stage.
In terms of how that hit my workflow, I had to change up and create all my sprites / bitmaps in each classes constructor and add them to the stage hidden off to the side.
When you first launch an app on the iPhone the "boot" picture appears straight away. Make sure that the very first thing you do is have a copy of that same image sitting topmost on your stage. Then you can call all your constructors and create all your display assets hidden under that cover, and when everything is in place you just transition that screen out. It hides any nasty stutters whilst the game makes everything it needs ( Using Zap as an example, the boot pic is our logo with "loading" text displayed on it, with the same image minus the loading text in the game itself, so the change from bootpic to game is pretty seamless ).
* Every pixel counts. Only plot what you need to, abuse the swf background colour as much as you can to save plotting.
* Pooling. Hopefully this is something you're used to doing anyway, but it's really vital when exporting to iPhone. During the constructor stage of my game I created all the pools too. Just using a simple Vector list, or linked lists. Pooling is such a simple thing to do and avoids any more object creation / deletion and stops the garbage collector being a big fat processor hog.
* Music. That loop that doesn't sound too bad on your PC at 32kps sounds really nasty on your iPod, funny what with it being a music player first and foremost. It's not a web game, push that bitrate up.
* scrollRect. I usually use that for animating bobs ( Blitter objects, ie sprites you plot with copyPixels or by adding the Bitmap directly to your stage ), using it to view a window on a sprite sheet to make it look like a sprite is animating, all nice simple stuff. I only had the briefest of tests with it on the iPhone, and I think it could be a texture memory hog, so the best way may be to just copyPixel each frame as you need it ( I've really not tested this to death so this could be complete arse, I was using a really big sprite sheet, so for now take this point with a pinch of salt ).
* Think blitter. Our good friend Rich showed me a blitter engine running on the iPod and it was really impressive. Blitting really is the way to go, just one canvas and plot all your pixels to it. I've just finished our own blitter engine for the up coming "Destroy More Cars" game which will be handy for future iPhone games. I'll post more details about that another time ( I'm tempted to open source it, but I really can't be doing with "This feature doesn't work" feedback. It doesn't ? Write your fucking own then ).
* Petty things. Mark your classes as final where you can, don't divide by two when you can multiply by 0.5, stop events from propagating. All tiny tiny things, but every little helps.
* Remember startDrag ? Sure you do, we all used it back in Flash 5. You're designing for the sexy iPhone now, it's not a mouse interface, let the player drag things around in a sexy way, they'll love you that little bit more for it. Apple have lots and lots of style guide docs, give them a read, it still applies to us even if we're Flash kids.

In terms of workflow, if you use Flex or FlashDevelop then you're not wanting to go back to the IDE in a hurry, it's too much of a shock to the system. I stuck with Flex ( By that I mean coding as3 in it, not mxml, there's still so much confusion about it even now ) and with including the AIR swc got auto-complete goodness on all the new commands. Lovely. Because Zap doesn't use anything really iPhone specific that needs to be on the device to test, I just added a simple test. If it's running via Flex check the keyboard and use that, if it's on the device don't run the keyboard code and revert to just mouse events.
I can't emphasis how much time this saved. You surely know the difference in compile time from Flex / FD compared to the IDE anyway, who wants to go running back to that ? It's not always going to be possible, but where you can make a version that can be tested off the device.
( In saying that, still test often on your device just to ensure that you're getting the performance you expect ).

How I set it up was having an empty fla with the iPhone publish settings in it, which just pulled in my classes. With CS4/5 supporting <embed> you don't have to change a line of your code, just use a different fla for laying out your assets for import. Using an empty fla just feels cleaner to me ( In actual fact I used two, one for testing and one for distribution, as you have to use different certs / profiles for each, more on that below ).

Moving on to Apple related things, brace yourself, this isn't the same as uploading a game to newgrounds. We've all read that getting a game published on the App Store is so easy and pain free, but that's mainly coming from people who are more used to the hell of developing for consoles, not Flash.
You're going to have to pay your $99 or whatever it is to register as a developer with Apple. My advice here is just register as a person rather than a company, it's a lot less hoops to jump through, plus when it comes to the App Store you can use a company name anyway which is searchable.

Next up is getting a cert and provisioning profile so you can test the game on your device. On the Mac that's fairly straight forward, on Windows it's a couple more things to do, our mate Iain touched on it in his blog post about his iPhone game. Come launch time I'm sure the web will be sinking under the weight of tutorials on how to do it.
One thing with the provisioning profile is that you can add devices to it. We couldn't really get access to any non-3GS / 3rd gen devices which restricted our testing, but you really want to be bugging everyone you know with an Apple machine for their device IDs so you can send out builds of your game for testing.

Come the glorious day that your app is ready to submit remember you'll need a distribution profile and cert. Also remember to re-read all the Apple guidelines, you don't want your game knocked back because of a silly mistake. You'll need to supple a link to a support site for the app, so prepare to remember your html skills that you've forgotten ( We just used the zap preview page, added a link to the contact form and job done. We've got a pimping and support page all in one ).
One last submission tip, when setting the release date, set it off in the ( Near ) future. If you leave it as todays date then when the game is passed at least 2/3 days after todays date it will be hidden in the latest releases ( Say you submit your app today, the 26th, and leave that as the release date. The game is accepted on the 28th. Your game will be classed as being launched on the 26th even though no one can actually buy it 'til the 28th, and even then it's got to filter around all the worldwide App Stores. This means all the games released after the 26th will be shown above yours in any latest games list ).
Once the app is approved, dive into itune connect and alter the launch date to tomorrow.

I think that's it. Hopefully I've not said anything I shouldn't have and got myself into trouble. If I have then I'll just lie and say my Mum is ill and start crying, no one will give me a bollocking then. When you do finally get your hands on the brand new Flash CS5 have a good google around for Apple developer forums. Every possible problem you'll ever have with submitting game has already been covered off by other people, the iPhone development community is huge and excellent, imagine our community without all the "I need teh codez lol!" and that's pretty much it.

Squize.

Sometimes it's just nice to celebrate the good things, so I'm going to be self indulgent and do just that.

Ionic got a great review at JayIsGames the other day, ok the score wasn't the greatest, but we can live with that, it's not the most usual of games and falls slightly between two stools. I'm proud of it and still enjoy playing it, so anything else is just a bonus. It's also doing quite nicely in terms of traffic, not huge numbers but a good steady amount each day, and we've not overly pushed the distribution yet.

Zap ( App Store link, or video preview ) was cited as an example Flash CS5 app at FITC,

This is a whopper of a post. You may want to grab a drink before you sit down to read it. Ready ?

Barry kindly granted us an interview about GamesChart as I imagine a lot of you have a lot of questions about it, just like we did. That's more than enough intro, there's about 8 meg of text below.


Q: Twitter pitch. 140 chars or less, what exactly is GamesChart ?

How about 39..? ‘GamesChart is the chart for online games’.

Q: Slightly longer pitch, sell it to us.

There’s three sides to this coin really, in terms of benefits GamesChart helps Developers seed and monetize their games, GamesChart helps Publishers drive cost effective targeted traffic to their sites and GamesChart helps Gamers to access some of the best online games the internet has to offer. The technology platform is built around an API that tracks your game wherever it goes and gives you the option to display charts within your game. Although GamesChart works on any game portal, going to www.GamesChart.com and clicking on the small GamesChart icon in the corner of any of the games is the easiest way to see how it works.

Q: I don't know if you've heard, but us developers are all about the cash. Art is dead, money is king. Why should we be dropping the API into our games ?

Different things will motivate different people, but there are a number of very good reasons why you’d probably want to. If you are the competitive type, then you’re probably going to want to see how your game ranks against all the other games that get released. If you’re the kind of person that would prefer not to spend hours emailing portals, then it’s worth noting that there’s a publisher revenue share and that portals actually need to upload your game before they can bid on any traffic going to that game… that one thing alone will give your games a huge viral boost. Last of all, the money… which I guess leads me on to your next question.

Q: Let's be blunt, how much per click ? Are we going to be able to order that solid gold Helicopter which we've got our eye on ?

Probably not. We’ve all been there, we all know that everyone believes their next game is going to earn them a million dollars, be picked up by a console publisher and then get made into a blockbuster movie starring Arnold Schwarzenegger. However, we are confident that Flash Game Developers will not just be able to increase the popularity of their game by including it the games chart, but also generate healthy revenues. Bid-based Pay Per Click is an extremely effective and fully accountable method for Publishers to drive traffic to their sites. Each ‘click’ will be worth a different amount to each publisher depending on where geographically that click comes from, the type of game it originated from and other campaign settings.

We’ve been noticing recently that people have been bidding an average of $0.60 per click for ‘flash game’ related keywords on certain popular advertising-word based pay per click system. Now of course, we’d be over the moon if that was the case with GamesChart and if it were, then a developer would stand to earn up to 50% of that. If you were an excitable chap, and you think all your games players are based from the US or Europe, confident that your CTR will be at least 10% and you’re generating 5 million plays a month… then you’d probably want to get out your calculator and start making plans for that solid gold helicopter.

Q: China, 20 billion people living there, but no advertising revenue. How will geography affect the revenue ? Is it a case of if the games big in Russia then well done, but we're not going to benefit from it ?

What can you do, it’s a fact of life. Your free to play flash games will end up being played by people in Russia and China - our advice is just to roll with it.. with GamesChart every play counts and even if you do get an extra 2 million plays a month in those territories, your game will quickly move up the charts and expose you to new audiences in territories that people do want to bid on.

Q: On the subject of the API, easy to use ? Doesn't break things like bitmap.draw() which other systems do ? Nice easy testing ground to check it's all good before pushing the game out into the wild ?

The GamesChart API is very easy to implement.  Developers have the option to add the API by dragging the GamesChart component to the stage. This requires no code adding to the game at all. The game can then be tested locally before being uploaded to the GamesChart website.

Q: Ok, you've sold us. I'm going to drop the API in. What about other API's though ? Are we cool with cpmStar, mochi version control, GamerSafe etc. ?

Sure, no problem. The exposure your game will receive from GamesChart will actually result in more revenue from other third party services you use in your game, so if you can find a way to get all of these API’s into your game AND GamesChart.. that’s awesome! Just to clear this up, we don’t consider ourselves to be in competition with anyone. In fact, in order to save you time, we actually give developers the option to upload their Mochi Games Pack to the GamesChart console. We’re also in discussions to include other third party API’s in our developer pack too, including the great new multiplayer API from Player.io

Q: Does adding the API affect the game in any way ? Is it a big bloaty monster ? Will anyone have to change the way they've set their game up to get it in there and working ?

You can modify the API to fit into any game and the developer is given complete control over how and where it is displayed so that they don’t have to compromise their game to accommodate it. It’s a tiny file that won’t hurt performance in the slightest, why not have a look - http://wiki.gameschart.com/index.php/GamesChart_Developer_Pack

It’s completely optional to display the GamesChart API in your game. Even if you do decide to disable the charts within the game, your game is still eligible to appear in the charts. Developers have the ability to remotely enable/disable a little 40px icon that appears in their game. It’s very low key and most developers decide to place it in the corner of their stage.

Q: Adobe are doing a similar-ish thing, a kind of YouTube-esque system showing games you could like ( The name of the project escapes me, and it doesn't seem to have had much of a push yet ). I'm guessing two systems can't be sitting in the same game easily, why GamesChart over the official first party offering ?

I haven’t heard much from Adobe these days apart from the iPhone & iPad discussions, but if you are referring to Youtube’s recent patent application in relation to a "Web-Based System for Generation of Interactive Games Based on Digital Videos", it’s hard to say how much we will have in common. I guess we’ll have to wait and see, it does ‘sound’ interesting though.

Q: The crux of GamesChart is to push traffic to sites, how are you differing from more well established methods of throwing traffic to sites willing to pay for it ?

GamesChart is a distilled version of more established methods.  Why make a player sit through a 20 second advert when all they want to do is play a game?  We offer an efficient method of delivering traffic that is shaped and informed by the way flash game players use the Internet.  The result is a low cost, high value click-delivering juggernaut.

Q: Sponsorship in itself is a great way to bring home the traffic. Say this goes huge, could it have an impact on sponsor prices ? I mean why pay for the whole game when you can just pay for it's clicks.

Interesting question.. Sponsorship is often a one-time shot, whereas GamesChart may actually prove, over time, to be a more sustainable means of generating revenue for Flash Game Developers. We know how important sponsorship is to developers, so GamesChart is designed to be complementary. You can place it anywhere in your game and it’s flexible enough to meet the requirements of most sponsors.

Flash Game License is a brilliant service for developers precisely because it provides a fair and open market to buy and sell sponsorship deals.  The GamesChart publisher bidding system is also open and transparent, which means healthy publisher competition and the highest possible CPC earnings for developers.

Q: Look at my game, it's sex, it really is. Oh, it's slipped out of the charts. That's it then ? Will games which fall out of the charts just tumble into a void of never making any money again ? If it's say a 20 minute job to add the API, test it and upload it, and my game is in the charts for only a day, or never even makes it in there, isn't that a waste of 20 mins ? You guys will still be getting exposure due to the viral nature of games, but me as the dev have basically just helped you out.

I think it’s important to clarify that revenue is only generated from outbound clicks from a developer’s game, so there is actually no requirement to ever appear in any of the charts in order to keep earning money. However getting your game into the Top 10 will result in a massive boost in game impressions which will also have a direct impact on any revenues you earn through GamesChart and  from other third party APIs.

At the moment, you’re only able to see ‘The Official GamesChart’, we’ll also be adding multiple game category charts over time. Now you may have noticed on the game upload facility that there are a number of category options available. These will help define new charts that will appear in the API; charts like the ‘Puzzle Games Chart’, ‘Action Games Chart, ‘Racing Games Chart’ etc… keep an eye out for the ‘What’s Hot Chart’ and ‘Top Rated Chart’. The introduction of these new charts will enable everyone to have a shot at gaining fame and notoriety.

Q: On a similar theme, won't the charts just be dominated by the big hitters ? Won't a Fancy Pants 5 or a Bloons 12 just be permanent fixtures on top of the charts ? Great for those guys, but for everyone else ?

Well the Official Games Chart is based on the total previous weeks game plays for each game. It’s just one of the many charts that through targeting will be presented to the gamer, but it is an accurate reflection of how popular that game is at the time. Games will naturally fade in and fade out of the charts in the same way music does with the music charts… If over time this chart is less dynamic than the other charts, then we might choose to focus gamer’s attention on the ‘What’s Hot Chart’ or some of the other category charts instead.



Q: Mochi distribution is a thing of beauty, they spread a game like VD in the Navy. Are you guys going to be running a distribution model ? Have you looked at partnering with services like FlashGameDistribution who also provide a great service ?

Mochi distribution is pretty awesome and we’d also love to partner with Adam and his great service at FlashGamesDistributon. However I have a feeling that if your game features in any of the GamesChart top ten charts.. it will experience achieve such a distribution kick up the proverbial, you’ll probably fall over with shock.

Q: We've all got games gathering dust on our hardrives. Is it good to upload them to GamesChart to try and squeeze every last penny out of them ?

Wouldn’t you rather find out, than leave them there? If they’re good, then they will receive a new lease of life.. if they’re gathering dust on your hard drive for a reason ..then we make no promises ;)

Q: On a similar note, are you worried about the charts being flooded with crap whilst people take to it ?

Not at all. It’s early days, but if someone adds a decent game now, it will probably dominate the top of the charts for a couple of weeks yet. People are naturally hesitant and have been using some of their earlier games to check us out. Don’t worry, it’ll soon drop out of the charts.

Q: What are you doing in terms of sponsors good will ? Have you being speaking to those guys, and what is their take on it ? I'm thinking in terms of their support when it comes to adding the API, are they going to see it as potential threat ? A lot of sponsors aren't loving microtransactions, are many loving GamesChart ?

A lot of these Sponsors used to be Flash Developers themselves and the feedback we have been receiving so far has been more questions than comments. Those Sponsors who would like the games they have sponsored to feature in the charts, but would prefer that the games didn’t display the API, can always ask the developer to disable it. The GamesChart technology has been designed to be flexible enough to meet the requirements of most Sponsors.

Q: What track record have you guys got before starting the GamesChart project ? I'm guessing it's not just you in a room with a well thumbed php manual.

Not exactly no. The team we have assembled here for GamesChart are experienced developers who have been involved in web development, online gaming, viral media and social internet applications for many years. It’s a platform that has been built for Flash Game Developers by Flash Game Developers… Some of us designed and built the original GameJacket technology and have an acute appreciation of the complex issues facing massively viral applications and flash games.

Q: I've got to touch on it, and it may be a little delicate still, but GameJacket. You were the public face for it for so long, I don't think too many people were aware you left a good 6 months or so before the end. Are you concerned you are going to be known as "The GameJacket guy" when quite a lot of developers got stung ? 
Basically people don't want to be in a similar situation a year down the line, what lessons have you taken with you to GamesChart, is the company structured differently with a different mission, different goals ?

I will always be happy to be remembered as the Founder of GameJacket, it took up a lot of my energy and I was proud that the company achieved the phenomenal growth it did in such a short period of time. Working with Flash Game Developers, following the development of their games and helping them to monetize and distribute their games was personally very fulfilling.

Ultimately there were good reasons why I felt it was necessary to leave the company in December 2008. Although there's always going to be some fall out from GameJacket because of the way things were handled in the six months after I left, I hope people can understand that it wasn't easy for me to make that kind of decision and I was genuinely saddened to hear that so many developers lost out when the Company decided to close.

GamesChart is structured very differently in terms of the decision making process, which will result in a more ‘service’ driven approach towards developers, publishers and gamers. We have some fantastic additions planned over the next few months and we are looking forward to receiving feedback, comments and suggestions about how we can improve GamesChart.

Q: If badgers were given guns, do you think they'd rob Post Offices, or just carry on as normal ( ie walking slowly on roads when cars are coming ) ?

With great power comes great responsibility... I think if you took a test group of Badgers and handed them all guns, some badgers would obviously revel in the fact they could cause carnage amongst their furry friends. However, the backlash from more responsible woodland creatures would probably result in an uprising in badger politics with spokes-badgers calling for the widespread peace and the unity of badger kind. http://www.timesonline.co.uk/tol/news/uk/article1132020.ece

We'd like to thank Barry for taking the time to answer these questions. If you have any yourself pop them into the comments and we'll fire them over and try and cover everything off.

On a side note, this post is our entry to this years Webby's in the "Most times one service was mentioned in one post" category. We're clearing a space for the award right now.

Squize.

Really busy weekend, I've been working on my new Blitter engine ( More soon ), pimping Ionic and also Zap went live at the same time.