Google Now in the Casual Game Ads Market

Google has entered the flash gaming ads market.  Right now that is pretty much owned by MochiAds for flash game devleopers at least pre-game ads anyways.  Advertising can be annoying but MochiAds has pulled it off where the ads are usually advertising other games or interesting things and it monetizes game development for Flash, Unity3D, Director and others, which is a win.  There are many flash gaming sites that are great fun that use ads almost stylistically like Nitrome and typically the ads are pretty fast when they are during the game loading.

Although advertisements in games have long been a scurge on gamers fun when they are trying to insert them into fat client, immersive MMOGs where it totally takes away from the experience, that doesn’t work.

What does work is stuff like MochiAds and possibly Second Life type sponsorships, where advertisements are almost nostalgic or fun and integrated. Developers and publishers have to make money somehow, the better the experience the more impactful and the more games for all. The key is making the integration a good user experience.

We shall see how Google plans to do this.  This might go along with their Lively strategy. The ad market entrance in games is possibly what started the rumors that Google was going to buy Valve for Steam, rumors which quickly died down.

Anyways, the one good thing about this announcement is advertisments go to where the eyes and crowds are going or already at, they are apparantly going massively to online web games and causal experiences make for easy advertisment integration. TV, Radio and many other industries have been supported by advertisement interest due to consumers using and buying the content.  So online gaming is just another one of those entertainment industries and it will grow further with this news.

Flash 10 Security Changes Good and Bad, Mostly Good (Full Screen Input, RTMFP, Clipboard, Local Save and Load)

Flash 10 security changes requiring user interaction are pretty breaking but they are for good reason.  Still though, the user could be inundated with prompts much like UAC on Vista. But, it is necessary otherwise security holes can be troublesome with the flash player and the “sandbox” of the web.  Much like Java signing, Active-X acceptance, and thus local file access, these actions need some user approval, it is that liability thing.

But what is a bit lost in this is some of the new support specifically for game development and app development.

Support for things like RTMFP which is bringing UDP support to flash.  UDP and reliable UDP (ordered) is really needed when it comes to larger scale networking applications and support for p2p apps.  Games for instance, that are large like MMOs and highly interactive real-time engines, need UDP to be able to scale.  So this is pretty useful, yet it currently looks like it is tied to Flash Media Server.  It appears Adobe is staying ahead of SmartFox, Red5 and OpenFMS with stuff like this.

Another great move in the way of security updates for Flash 10 for games is the allowing input from keyboard keys while in full screen mode. All these games and apps look pretty sweet in full screen until you try to use them.  There is only support for “Tab, the Spacebar, and the (up, down, left, right) arrow keys” but that is a start.  Enough keys for a casual game.  But still most keys could safely be used it must be a multi-platform support thing.

Limited full-screen keyboard input

Currently Flash Player does not allow keyboard input when displaying content in full-screen mode. Flash Player 10 beta will change this, allowing for a limited number of keys to be usable in full-screen mode. These include Tab, the Spacebar, and the (up, down, left, right) arrow keys.

Flash 10 is getting local save and load, this is great for any type of online editor, game or application. The ability to work on a file immediately without the server round trip initially is great.  I hope this is extended much further to local save and load with very high limits, there has been some confusion on the file size limitations here. Ideally this would be extended much further if the product direction is right. Typically making apps or games with more than 5-25MB of content quickly become non-economical in bandwidth such as gaming assets due to browser cache size limitations (defaults IE=50MB, Safari 5-25MB, FF3=50MB), I wish there was a better way to allow local saving for long periods of time.  Almost installing apps via flash with extended cache, talk about killer app feature. Downloading 10 MB of gaming assets that you know will be there for the month rather than the day.

Paste events can read the clipboard.  Using the clipboard is another great useful tool in applications and online editors.

Data can be read from the Clipboard inside a paste event handler

In Flash Player 9, the system Clipboard could not be read at any time. With Flash Player 10 beta, the new ActionScript 3.0 method Clipboard.generalClipboard.getData() may be used to read the contents of the system Clipboard, but only when it is called from within an event handler processing a event.

So yes, the security user interaction changes do break current features but it also takes this platform a bit more into secure applications and game features from security changes, hopefully these features are extended much further but they are on the right track.

Hardware of the Casual Gamer

Making great games, applications and tools using flash, silverlight or other tools that are emerging such as Unity3D takes great style, effort and knowing your target. We need to know what the end-user machine has at hand.  The Unity 3d guys put together a great post on the capabilities of casual gaming machines. With all the talk about flash 3d, unity3d and silverlight what level are you targeting and what group of people can actually PLAY your games as you envision.

Pretty much everyone knows Valve’s hardware survey – it’s a very valuable resource that shows what hardware the typical “hardcore PC gamer” has (that is, gamers that play Valve’s games).

However, the “casual gamer”, which is what Unity games are mostly targeted at, probably has slightly different hardware. “Slightly” being a very relative term of course.

Lo and behold – we have a glimpse into that data.

How? First time the Unity Web Player is installed, it submits anonymous hardware details (details in the EULA). This happens only once, and contains no personally identifiable information. It’s much like visitor statistics trackers on the websites that gather your OS, browser information and whatnot.

Remember, all this data is from people who installed Unity Web Player (most likely because they wanted to play some Unity content on the web). Hardware of standalone game players might be different, and hardware of your game’s players might be different as well. The data set is well over a million samples at the moment.

Check out the full stats here.

The most interesting stats to me:

OS Platforms

Windows 96.8%

Mac OS X 3.2%

CPU Core count overall

1 54.7%

2 44.1%

4 1.1%

8 .1%

Wow this one is surprising, but with the type of gamer that will play and download a quality new plugin to get to a game, maybe not.  They need to have the latest and greatest.  Multi-core processors have been selling for about 2-3 years so this is a continuing trend that will make Flash 3d and even plugins like Unity 3d better over the short term.

Also when you check it over at Unity Blog note the top cards, it is a bit painful if you are a casual gamer developer.  Not a decent card in the top 10-15. But that is changing rapidly over the next 1-2 years in this regard. But this also vyes well for flash based games that rely on dual core software rendered results right now as a decent constraint for developers to keep content painfully accessible to all states of machinery out there.

I wonder if this information is available on the flash player and public? This is specific to the Unity 3D plugin that is also a bit of a different market that is willing to install a plugin for better experiences.  With Flash it is usually preinstalled or auto updated for a casual user and might be different as Flash has a 98% penetration rate.  Or for that matter the Director users which would be more gaming focused which amout ot about 40% of internet users.  But as with the case of Unity it is specific to games right now and a small penetration rate, Flash is also apps, ads, tools, demos, interactives in addition to games.  Having this information on Flash or Director would be nice.

Moock Mentions XFL for Open Flash IDE Source Formats

Colin Moock an actionscript brain since the great Flash 4 advances that brought all sorts of fun to flash, like games, has mentioned XFL an open format for flash from a discussion with Adobe product managers.

This would be a format that would be able to import, export and allow compile to SWF. MXML for Flex does this now but bringing the two together into one common format and allowing for all sorts of open source and third party contributions to making flash will let it literally explode in support.

I recently met with Flash authoring product-manager, Richard Galvan, to talk about Diesel, the next version of Flash (i.e., Flash CS4, or version 10 for those counting). Adobe has already demonstrated a bunch of high-impact features for Diesel, including inverse kinematics, a new tweening model, 3D “postcards in space”, and advanced text components (see MAX 07 keynote, FOTB 07 keynote, and FITC Amsterdam 08 keynote). But Richard was keen to talk about a lesser known feature quietly percolating behind the scenes: XFL.

Since its inception, the Flash authoring tool has stored documents in a binary source-file called .fla. Historically, interchanging source with the Flash authoring tool has been virtually impossible for third-party software because the specification for .fla has never been public. But things are changing in the next version of Flash. Flash CS4 will be able to export *and* import a new source format called XFL. An XFL file is a .zip file that contains the source material for a Flash document. Within the .zip file resides an XML file describing the structure of the document and a folder with the document’s assets (graphics, sounds, etc). The exact details of the XFL format are not yet available, but Richard assures me that Adobe intends to document them publicly, allowing third-party tools to import and export XFL.

If this is a market test or check of interest I think that everyone I know working with flash would be very excited about opening and unifying the flash format and allowing great IDEs and tools to help produce better flash content more quickly. Also, with the competition Silverlight using XAML (uncompressed) this also allows a competitive advantage maybe making Silverlight add better compression and loading tools beyond their downloader object.

I hope this is also in the plans for Director. If they used similar formats it could be very nice and something to watch as an emerging market to prepare for.

Read the full post at