Time has flown and now AI Factory has been around for 15 years, almost hard to imagine. Here we look back at where we came from. Our success depended on choices, hard work and also inevitably quite a lot of luck. We still needed to be at the right place at the right time.
This article walks through our story and its ups and downs. These 15 years have been our entire work in that period so it is a big part of our personal history too. It was bold to go it alone, but our history justified the risks. This is primarily written from my own first person perspective (Jeff Rollason), but I am really just a vehicle for describing what we all did. The body is an amalgam of inputs from all involved.
On the business side, note that in 2003 the games industry was very different to what it is now. Very different levels of competition and risk. We entered a challenging business with skills but no financial roots.
This article was started with modest ambitions for a quick short article but, once started, we figured we needed to more-or-less discover our whole story, and the "whole story" needed a lot of digging and a lot of writing! It's a little more "book" than article!
In consequence this article is by far our biggest, and merited an index. Each year's header link has a brief summary of that year. The number of sections may seem daunting, but they simply provide selected ways into the article.
Our company has had just 3 people throughout most of its history, but originally had 5. Those 3 included a UI engineer, AI engineer and an artist.
The roots originally came together in a company called Purple Software in 2000, which had purchased Oxford Softworks, where I (Jeff Rollason) functioned as an external contractor on a revenue share basis. I had entered work for them for Computer Shogi, after leaving my teaching at Kings College UOL. Also from Oxford Softworks came Kirstie Berry, an experienced graphic artist who completed excellent artwork for all of Oxford Softworks's very many products. As new entries there was Dan Orme, a games engineer directly employed by Purple Software at the start of his career, and Andrew Ray, who was more senior and entered Purple software also as an engineer. My own entry to Purple Software was not automatic. I personally did not move to Purple directly, but I instead spend 18 months as part of another company and then was later head-hunted to re-join Purple.
Figure 1 : Last days at Purple: Jeff Rollason, Dan Orme, Andrew Ray and Kirstie Berry. Note no LED monitors in 2003!
At Purple Software we worked on many projects, including Psion and PC work, and critically a suite of PC products for GlobalStar Canada. Within this setup I was assigned to work alongside Dan Orme and quickly it became obvious that he was a very strong engineer. I made a mental note that if I ever engaged in a new company start-up, I would definitely want Dan there. There was good chemistry within this group.
However Purple Software had some 40 people and the revenue burn to maintain these was too much for the work coming in, and late 2002 it started downsizing. Purple Software had some great people and this was a painful process. It did not get better. In February 2003 Purple Software went into liquidation.
In February 2003 we had the final day at Purple Software, leaving us owed money we would never see. In the car park under the offices we gathered in the gloom and I suggested that we might create a new company from the ashes of Purple. We had some hooks to start us. We were working on a 6 game PC project for Globalstar Canada and could potentially take this over. Happily I had already made a strong connection with Jeff Quinn, the primary contact at Globalstar, so when I rang him to break the bad news about Purple Software I already had a foot in the door. I suggested that we could take this work over and do an even better job.
We were in! Starting a company with a running contract is a huge advantage. It gave us instant status.
Of course we still had to solidify the company. We bounced around company names, with AI Games, AI Factory and AI Cosmos as the last three candidate names. AI Factory had its appeal as it implied that AI was easy enough for us that it could be churned out "factory-style". I helpfully had a clear background there, with an academic background in teaching and having competed in many international competitions for computer Chess, computer Go and computer Shogi, so there was a hook to hang this idea from. There was also an intended allusion to Warhol's iconic and highly successful "The Factory". AI Factory won out and Kirstie created a vivid and imaginative logo for us, with a slight "mecho-punk" and anarchistic feel to it. The logo is very important!
We still had to establish the company members, which immediately included myself, Kirstie Berry, Andrew Ray and Chris Brewerton (although he departed early on). An option was the excellent Nat Snell, who had already completed some critical work for the Globalstar products but, after weighing up options, he decided to move on. The other key was to persuade Dan Orme to join us (he was unfortunately an earlier casualty at Purple). Gaining Dan was big as so very clearly he was an excellent addition and would be a vital engineer. He came on board and we started to move. The company was registered in March 2003.
This was already hard work! We had to establish access to assets through the liquidators, which burned time. We had no money so arranged to take the assets in return for a revenue share of our exploitation of these. We also needed the PC kit, software licences and contract specifications from Purple. Key was access to the Globalstar assets, but also the game engines in other projects. We shared licences for some of these with Zingmagic, run by the very capable and experienced engineer and Purple director John Holloway, who also went down the path of a start-up.
We, of course, were all working from our homes. Keeping in contact via MSN and later, by Skype. It was a bare bones company.
Finally we had to prepare to present ourselves to the Gaming Industry. Part of this was to create an impression of who we were, even if parts of this had limited foundation. Part of this was (for example) registering in advance to be an Xbox developer, even though it was unlikely this would actually manifest. We also needed a web page where we could announce our activities and intentions. We needed to create some product proposals we could hike around publishers. One possible avenue for business was Unbalance in Japan. I already knew the CEO very well and had provided very successful products for them via Oxford Softworks. We could re-exploit that opportunity.
We had the advantage of having already worked as a team on the Globalstar project, which required Friday Night Pool, Friday Night Darts, to be followed by 3D Tournament Chess and Omar Sharif Bridge II, and then Casino and Slots. Dan was the driving force behind the UI creation and design, and Kirstie the artwork. We signed up the band Meretto and Hasan music to provide soundtracks.
Having now gained executive control over this project, it allowed us to go the extra mile to make these better. The 3D work was good, with nice shiny textured and convincing Pool balls with good framerates. In case that does not sound remarkable, note that a very commonly used GPU at that time was the "fast" NVidia TNT2, which ran at 10m triangles/sec, compared to a modern NVidia GeForce GTX1080, which clocks at 16,000m triangles/sec, so 1600x times faster! To achieve the best look that we could within the hardware limitations, we mixed real and hardwired shadows. We had fixed light sources and exploited this by having some pre-rendered shadows on textures for static objects.
We also worked hard to create realistic ball motion for Pool/Snooker. The balls did not just enter a pocket and disappear, but might rattle and eject. This was all calculated physics, not animations. Of course it was limited and worked entirely inside a 2D ball plane, so no jumping balls. To test this we also took countless movies at the local pool hall to compare our emulation with the real thing, mixing business with recreation.
Figure 2: a frame from one of the 70 movies used to calibrate our pool
It also exposed the nature of Pool/Snooker AI. We found it was easy to make the program play like a god, bouncing 3 cushions before potting 4 balls, but that is not fun for the player! Check out "The Computer Play Pool", which describes in detail how we approached this engineering. Our AI players had built-in human-like errors.
The darts program had the issue of mapping a dart throw to a mouse gesture. That was really kind of strange, but it worked! We worked like crazy and delivered our first two products in August 2003. Coding continued to the very last day, late into the evening. Exhausted but delivered.
Figure 3: Our Friday Night Darts and Friday Night Pool, published August 2003
For our next product, Omar Sharif Bridge II, we needed the licence to use Omar Sharif's trademark. Happily I had arranged that I met Omar Sharif at Purple, by "accidentally" arranging to be in the foyer when he visited Purple. The contact was made. We talked to his agent and obtained the licence for these products.
Our chess needed a chess engine. We had some very limited chess programs through the Purple IP, and also the well-known program "Chess Tal". However the latter was an unknown beast and we had no-one who had worked on this. For myself I already had written 3 chess programs, with some very unusual tech, so I created a new chess engine for the company, called Treebeard.
It should be noted at this point that there was some critical game architecture going on here. While at Purple, Dan and I had started to create a generic game architecture Fireball to support multiple game engines. This was in its infancy at Purple but we matured it into a highly capable framework to support any game engine we might create and it provided an off-the-shelf console to allow any game to be tested. In hindsight this was immensely important to our success as it made both development and support of games much easier. This same architecture supported playing a chess move or playing a snooker shot with exactly the same function call.
This architecture has continuously evolved since then to add more complex and exotic generic console commands and debugging capability. The end product is not perfect and bits of its structure reflect earlier legacy decisions that we might have re-invented now, but mostly it is in good functional shape.
Figure 4: The Fireball generic game architecture
Within our component game engine classes were other important decisions. When this was in evolution the compilers, such as on the Palm, were somehow often in a kind of beta state, not fully supporting the C++ language. For example some compilers did not support multiple inheritance. Looking at what we had, we chose to live within a controlled subset of C++. Bound in with this was the need to make debugging as easy as possible, so no templates, which were hard to run debuggers on. Also we decided to avoid using pointers as they were harder to put effective asserts on. i.e. you could test for a pointer being before or after a block, but not easily whether it pointed to a valid boundary within the block. Memory was also constrained to essentially static objects within a class object, which itself might be allocated on the heap on app start-up. Beyond that no access was made of the heap as it was potentially an unreliable source of memory, which might even be refused. Also if an app started and then started significant allocation later it could cause apps to be sluggish as other apps were swapped out, inviting unwelcome pauses.
Dropping down one further layer we found, particularly with Android, that memory allocation on the stack could be very slow. This was probably linked to the handling of the cache. An array on the stack used by a function in multiple calls could find that it was flushed out of the cache, whereas if it was defined within the engine base class, even if it was just scratch space, it was probably more likely to remain in the cache. In one instance a relocation from stack to the base class delivered a 4-fold increase in speed.
Of course optimisation might not prove to be cross-platform. In these early days your PC would have multiple levels of cache, whereas a small device such as a mobile of Palm might either have either no cache or a small single level cache. We saw that exposed where the loss of speed on a PC might (say) cause memory to drop to a level 2 cache, but on the target device it dropped out entirely. Of course now a modern mobile, such as a Pixel 3, will have 3 levels of cache so much closer to a desktop.
The first demos for 3D Tournament Chess and Omar Sharif Bridge II were delivered November 2003 after an intensive run. As with the Pool and Darts, the Chess and Bridge were 3D creations set in a room you could look around and interact with. They also provided club and tournament rooms. As part of the gloss to the project we provided many extra items of eye candy, such as changing lighting to reflect the time of day and even having a manned balloon occasionally flying past the window. The Bridge product showed pleasing animated deals to add to the aesthetic appeal of the product. We put a lot of passion into these products!
The bridge engine inside this came from Purple, but was actually owned and written by Andrew Bracher, and then re-licenced back to us.
Figure 5: Our Bridge and Chess products delivered for Globalstar
Of course we were fully committed to delivering this series of products but this was a single track. We needed to prepare for future projects to the same publisher or to later be re-cycled to other publishers.
Note that at this time the games industry had a very different complexion. There were no app stores like Google Play, and almost no on-line purchase and download of game installers. A product generally meant a box and disk or a cartridge. That meant dealing with publishers to support and fund projects. Being an independent developer + publisher was not a viable game plan, unless you had some other substantial financial backing. We were not going down that route and expected to grow organically from the revenues we generated.
With multi-track in mind, we also prepared more detailed project proposals to take to Globalstar, some actually progressing to fully playable demos. This was actually a significant creative activity for us. In among these were some very cute and viable ideas, including a Toy Attic. These are worth noting as we committed significant effort to evolve such concepts and the experience lay the foundations for projects to follow. These are all crucial parts of our company design history.
The Toy Attic was a very attractive idea of providing an attic full of toys that you could play with. Items could sit in chests and boxes might need to be opened to get at the toy or game. For this Kirstie provided one of our best visual realisations of an intended game concept.
Figure 6: Toy Attic: A game concept we loved but is still on the shelf
Among the 15 games proposed, was a very ambitious one to emulate naval warfare during 1850 to 1906, covering the battle of Tsushima between Russia and Japan, and Manila Bay between the USA and Spain. The architecture of ships during this period were interesting and I personally had specialist knowledge in this area. If this had been taken up it would have been AI Factory's most ambitious product ever. It was a game that would have resonance in both the US and Japan (The battle of Tsushima was Japan's biggest ever victory at sea).
Figure 7: The USS Olympia at a crucial stage of the battle of Manila Bay
Figure 8: Legion and Extinction were fully working. Amazons was an idea
We had survived year 1 and had a meal to celebrate! It actually felt like we might really make it.
Figure 9: a blurry first Xmas meal!
The end of 2003 had gone well. We delivered 2 products and were well on the way for 2 more. By the end of the year we were feeling confident with plenty of self-belief. A manifestation of this confidence was reflected in our company Xmas card, which re-cast us into the Matrix! (below).
Figure 10: Our first company Xmas card, based on the Matrix
This was a crucial year for us. We were coming nearer the end of the Globalstar work and needed to establish follow-on work. Lack of complete certainty focussed our minds!
We still had to deliver the final Chess and Bridge products, which we did in May 2004. By the last night on delivery we had fallen a little out of love with these products! After many late nights we were indeed tired and jaded. These were our foundation products and just had to be right. Although it would not have felt much compensation at the time, all this was a good rehearsal for generally improving our capacity for reliably and efficiently delivering in the future!
Again we had gone the extra, extra mile, and the products were much better for it, but as the developers we paid the price in late hours burned getting them to where we wanted.
We still had to deliver the final Chess and Bridge products, which we did in May 2004. In parallel to this we also released 2D game products based on IP we licenced from Purple.
Since it appeared we were given incomplete sources for all of these products by the liquidator, we needed to write a program to binary patch some of these to provide our AI Factory branded products. Sometimes you need to resort to brute force methods to deliver what you need to. These games went on direct sale on a download site, The Trading Centre. The revenue was limited, but the activity made us look good.
Having completed 4 products for Globalstar we were now ready for the final 3D Slots and 3D Casino. Globalstar Canada was swallowed up at the end of 2003 into Globalstar USA, which potentially undermined the project for us. I was due to fly to Japan on the 18th May 2004 to compete in the World Computer Shogi Championships in Tokyo and visit a new publisher Konami to discuss porting our chess to the Sony PSP.
The night before Chris Mates of Globalstar USA rang querying cancelling Slots and Casino. We had to think fast. We invoked the cancellation clauses but, since there had been little notice, we wanted the right to take the existing completed products into Japan, since we would not be competing with Globalstar.
They agreed and this was huge for us as I flew to Japan the next day and presented the products to Unbalance Corp (who I already knew) and indeed they were interested, and so suddenly we had new and better business! As it happens we also did not fancy the Casino and Slots projects, so a double win.
This was extremely good "bad luck"!
Figure 11: Our first Japanese products for Unbalance
Unbalance wanted enhancements to these products, also to make them more suitable for Japan. They collaborated to provide translations and general support.
One of the key requirements was to add real faces to the provided opponents. We went around taking photos of our friends and even asking permission of people we solicited in a shopping centre to get their photo for use in the product. It was made clear it was just for products in Japan and that their real names would not be used. They signed their approval.
Figure 12: Photos of the people added to the product for Japan, with faces heavily blurred to protect anonymity
At this time, attempting to secure as much business as possible, we were in many internal meetings analysing pathways to more business and how to maximise and re-cycle what we already had. This also meant taking a string of EXPO passes to every games trade show we could.
At the start we did not take the paid passes but exploited the free expo passes to gain access. Key to networking was finding the people you need to talk to. One trick was to check the lecture schedule (which we had not paid to attend) and then turn up at the end of lectures where people we might want to talk to would have attended! This is a trick I re-cycled many times and it paid dividends.
Figure 13: Both sides of our double fold leaflet for ECTS
Part of attending a trade show was also having a suitable leaflet. This is a currency that has now fallen into disuse, but in 2004 was a needed way to get your message out. Of course you could pass these to people you met but also good for simply dropping copies on the circular coffee tables at the shows, for delegates to glance at when supping. We also make up some 3.5" disk labels for demo disks (What is a 3.5" disk, you may well ask?)
Finally the last needed ingredient is a business card. We started with a home-brew printed on a home printer but as I collected cards I noted one with the person's face on the card. This makes it much easier to connect cards with people, so I copied the idea for our own card.
During this period we were in contact with various business groups, as follows:
We met up with Revolution Software of York, a company with whom we now have a permanent contact. They came to see us with a view to taking bespoke puzzle games from us for their Broken Sword project. This was for the publisher THC, but THC changed their mind and the project was shelved.
Another track was taking games through to Symbian through Owen Waller. This got as far as a chess product, but we found no effective monetisation of this.
We were also in negotiation to licence a Go engine from a colleague Mick Reiss for the Korean market. We made progress but the project eventually stalled.
Finally, in our attempts to broaden our reach we were in discussion with Buruxo of South Korea to provide an engine for their Spell Mage game. They came to see us. This exotic product was interesting but again nothing came of it. However it created contacts in South Korea.
You can see some of these latent products and artwork in our news pages.
With our strengthening relationship with Unbalance we had many possible PC projects in consideration, such as Golf, Ping Pong, Air Hockey, Bowling, Crazy Golf, 3D 4-in-a-line, Archery and Taipei. All good thought experiments. Golf and Bowling did progress to detailed specifications, but none of these titles actually manifested as products. However other much more significant ones did later.
After the break with Globalstar we started talks with Empire Interactive, through a colleague Calvin Hutt, who I had worked with at Oxford Softworks, carrying through a number of projects previously planned for Globalstar.
Although we seemed to be busy we were still hard pressed to provide a solid income to support 4 people at full salary. Andrew, with two children to support, felt he needed to bail out. It was a pity to see him go. Andrew is still on our web and sees us each year. It is tough to keep in a comfortable financial shape with no external funding. Andrew was responsible for some 90% of the work on our Bridge and Darts program, which still looks good today.
The projects with Unbalance were critically important for us to survive, but had not provided a very substantial income. Our relationship was partly based on some ethos of mutual support. In the period 1997-1999 I created a Shogi product for Unbalance via Oxford Softworks that created substantial income for Unbalance. In return, seeing our potential, Unbalance were now providing us with work. That was instrumental in allowing us to survive as we gathered strength and now (2018), we are the stronger party and are returning some favours to Unbalance. They are in turn providing support for external developers going through difficult times. This is a known attributed business method, whose name I cannot currently recall. However it is basically a kind of "Business Altruism".
Although funds were lean, we had products on sale in the US and Japan and were directly selling PC titles via our web. We had many contacts and companies that now knew us. Time for our Xmas party, this time a home party in Pinner! We arranged our own awards with bottles of bubbly for "best art", "best product" etc. A good year!
Figure 14: Xmas in our Pinner own premises, the registered company address
This was another critical year. In a sense we had carpet-bombed the trade shows, looking for business and indeed this yielded crucial contacts and work. We filled out so many NDAs, the staple diet of so many businesses. We were also self-taught in our contract writing. That had been inevitable as we had to deal with contracts even before the company was established. We learned from these, gradually building up a picture of what terms must be there in a contract and learning on the hoof. We seemed to manage well.
Apart from the new work with new publishers, at the start of 2005 we agreed with Unbalance to create a new more lavish Pool and Snooker product for the PC platform, this time also including a full tutor. The product was a step up in visual richness. The tutor system also was an innovative dynamic system that played a game against the user and classified the positions reached to offer candidate tests for the user to try. Therefore no two lessons were the same. This was really quite sophisticated.
Figure 15: The Pool tutor setting a test for the player
The follow-on from this, starting in August, was to create an Aquarium product for mobile phone for Unbalance. This was a big undertaking and needed to be flexible so that fish, each with different characteristics, could be dynamically added with no new coding. This did not become a product until 2007 (see later).
However, as the year headline indicates, the big new event was Gizmondo. We met them at ECTS and this was a project to launch a handheld console in direct competition with the coming Nintendo DS and Sony PSP. That seemed a tall order, but they were willing to pay upfront, and we still needed the work. This device was not so bad and we indeed completed two products, each with 5 games. Tony Warriner joined us in this enterprise.
However, as we suspected, not all was well. The Gizmondo story is renowned and it appeared it was founded by former Uppsala Mafia from Sweden. The whole project was dubious, founded on some $300m USD funding. Money was shipped to fake companies for products that did not exist. We were eventually owed some £50k and only retrieved that by threatening to go public on the fact that we had issued a statutory demand against them. We did well but many more substantial games developers went bust, so we can count ourselves very lucky.
As part of this we went to E3, where Gizmondo had spent a lot of money on a big stand. This was a surreal experience. The flavour of their massive stand a bit strange, and seedy, populated by leather clad women. Rather different to what Nintendo and Sony were doing. This was one of the stranger Games Industry stories.
Note also that these were early days for us. By now we had attended many trade shows in the UK and this was our first in the US. I worked very hard at E3, but was still a real newbie. It was all good building experience.
2005 saw the creation of the AI Factory Newsletter, that we now generally call the "AI Factory Periodical". This was borne with one big idea in mind. By now through trade shows we had started to build up a significant number of contacts, but re-engaging these by calling them up or e-mailing them was cheesy, as the obvious purpose was to tout for new business.
How much better to have a periodical with articles worth reading that you could drop into each business contact mailbox. This was less obvious and just reminded them that you still existed. It also added to our image, that we were forward enough to have a publication, not just a bunch of nerds working from our bedsits (It has to be said that Dan lived with us in our small house for some time until our finances solidified, so collectively we were living and working in the same space).
This idea worked as we got business in direct reply to the periodical. We also found that business contacts were often eager to even discuss the periodical. Finally the act of writing the articles solidified areas where we thought we had a grasp but that the act of writing exposed issues. The articles have also provided a reference to look up past ideas for re-assessment. We have created a viable knowledge base for our own purposes. We started with 4 per year but pressure of work pushed this down to just twice a year.
When we had to go through GDPR we had to remove subscribers that neither actively subscribed nor were active business or academic contacts. It was agreeable to find that a significant bulk of our readers were unsolicited subscribers that had simply found us and asked to subscribe.
Figure 16: The attractive headline graphics of all our newsletters from 2005 to 2018, created by Kirstie
As a backdrop to the Gizmondo story, we did spec-up a number of well-thought out projects that might follow-through with Gizmondo, should this turn into a real business. Even though these did not come to fruition, they were good exercises and useful thought experiments. Among these were more than one GPS-based game idea that have since manifested in other products on more modern devices. These ideas were later floated with other publishers.
Figure 17: Artwork from multiple project design for Gizmondo, mostly GPS-based
Our most significant events were E3 (above), but also GDCE in London. In the latter it felt like we were looping back as we re-met old Purple Software colleagues. However it was a significant conference that I posted summaries of each day. Through this we made our solid contact with the South Korean company StraStar that ultimately led to our later business there.
By the end of 2005 our PC and other platform publishing portfolio had expanded to include titles in retail under Mindscape, BHV, Denda, EmcX, EXA, Unbalance, Byro, Gizmondo, Global Star, White Park bay and now SelectSoft. The latter, starting 2006, provided our first published Chinese Chess product for the market. This program was twice a gold medal winner in the Computer Olympiad.
Other companies we were in discussion with included: Empire Interactive, Microsoft, Kayak, Moblitec, Buruxo, Handmark, Hexwar, Paper Plane and Elixir Studios. Some of these consumed substantial volumes of time, whether or not a product manifested, but it added to our experience.
By the end of 2005 we were a little exhausted, but ready for an Xmas party at our home.
Figure 18: The 2006 Xmas party. Left Mick Reiss, author of Go++ and long term colleague
By now, with growing confidence and experience we pushed on and one good break was a visit to ECTS, where there were many modest stands and one particularly imposing one by Microsoft. No-one seems to be attending the latter as I figured that many developers thought Microsoft looked "too big" to talk to.
I held my breath and marched forward to sell who we were. We started with a hook into the company and climbed deeper into the hierarchy, culminated in Microsoft wanting to licence our chess for their MSN. For such a small fledging company, this was a big deal that improved our standing in all follow-on discussions with other companies. This was signed in 2006 and delivered in 2007.
However it exposed an issue of such a small company working with a giant like Microsoft. Their legal procedures were designed for dealing with big developer companies, but we needed to follow the same procedures. Part of this was taking out indemnity insurance to protect Microsoft, a mandatory step. After scouting around we managed to size this down to £8k, which would be of no consequence to us now, but a bigger issue then. Gallingly this required terms such as "protecting the building at Redmond from damage": which clearly had limited meaning in our context!
Note though we were extremely happy with this contract and Microsoft indeed proved to be excellent to work with!
Figure 19: MSN Chess, using our Treebeard chess program, published in 2007
Throughout this time (and also before the creation of AI Factory) we had competed in the World Computer Shogi Championships in Tokyo. Our Program Shotest has competed in some 15 tournaments, twice ranked #3 in the world and the significant achievement of beating 3 world champions in the year that they were world champion. This has not provided substantial direct revenue but has provided kudos and added weight to any implied claim for world class AI. We continued entering for a few years, combining with trips to visit publishers in Japan.
Figure 20: Our Shotest competing in the 17th CSA Tokyo
Again we were attending trade shows and conferences, this time the Casual Games conference in Austin, Texas. This further created a body of contacts for us and more experience through networking. Gradually we were solidifying our presence in the market. We started getting many approaches for us to create bespoke AI for other products, including a Quake-like game and also a hex-based wargame based around the US Civil War. Also many companies wanting access to our classic games or classic game AI. Too many of these would have been a too big a burn of our time given our existing commitments.
Figure 21: One of the many waits in the departure lounge, on route to Texas
As a freebie, I was also lucky in this choice as it coincided with a huge American football final between Texas and Ohio, and all Austin was taken over by barbecues. Marching bands and beers everywhere, and much hospitality. It also rammed home that I did not sound like a Texan. I struggled to talk to voice activated call line for buses, even trying to mimic George Bush, but not a single word I said got recognised. Eventually I was put through to a human.
One of our budding coming contracts was an Xbox product for chess with Paper Plane, through working with Relentless. This was an attractive company that had created the extremely successful product Buzz. Working with them was an agreeable idea. This would also have been our first entry into this premier console market, so was a very interesting prospect. However, unfortunately, this project was found to conflict with Relentless's legal commitments and obligations, so the project had to be cancelled.
However this was not game over as we had ideas for a Shogi Xbox product. This could no longer be with Relentless, but did then manifest elsewhere.
We did get into discussion again with a view to the Symbian market, in particular Vringo. We were at the Symbian show as we had already made some progress with Owen Waller in creating a Chess app for Symbian. You might wonder why Symbian would be of much interest as it was a restricted OS and basically no longer exists now. However in 2006 Symbian had 67% of the mobile market and so could not be ignored. At the time there was no reason to suppose that it would not continue to be the dominant player. It was eventually overtaken by Android in 2010.
We also had talks with NVidia, who came to see us with a view to creating demos to show off their mobile GoForce video hardware. There was little in it for us, except that it looked good to be working with NVidia.
Our Xmas party again was at our private address, the registered address of AI Factory. It is a curiosity but for each year this is the only time the 3 core members of the company ever meet up!
Figure 22: Xmas party. Note former owner of Oxford Softworks Chris Whittington on left.
In terms of developer satisfaction, this was a very good year as we engaged in an Aquarium project, which was both intellectually challenging and visually attractive. Tony Warriner acted as a consultant in this project.
The Aquarium was actually started in late 2005 and is arguably our most interesting project. It was designed to provide #an Aquarium simulation with multiple fish. This was to run on Japanese mobile phones from 2006 that had no real GPU and a main single core processor clock of 400MHz. It is hard to estimate the relative graphic performance of such a device compared to a modern phone, with multiple cores and a capable GPU, but perhaps these phones were some 100 to 1000 times slower.
However we were to render realistic 3D models in real time. To make this possible we needed a highly optimised architecture. The first stage was simply to visit aquariums and take many movies of fish moving. From this we factored it down to a limited animation framework that could replicate the full range of behaviours we needed. Given the tightness of available CPU availability, the animation was directly driven by the emulation engine, which directly controlled the timing of each animation frame. This allowed the engine to directly speed-up or slow down an animation in response to the situation. This tight direct control gave the engine maximum flexibility and avoided possible situations where an animation sub-system might fail to respond to some urgently required animation change. The resulting system never exhibited blips where the animation had clearly fallen down.
Figure 23: Animation design for the Aquarium
Of course with multiple fish and objects in a tank we needed an efficient method of avoiding collisions. To do this each fish had 3 spheres mapped to it and each object its own set of spheres. Detecting collision by testing sphere overlap was also potentially expensive with many possible sphere collisions, so we used this curious bespoke integer sum that approximated a sphere very well. Vital optimisations like this allowed smooth motion on such limited hardware.
Finally we wanted realistic fish emulation and this was achieved by defining 74 programmable parameters to define each particular fish characteristic. This allowed a fish to be added with no coding other than providing a 3D model and animations and a config file with these 74 characteristics. Each fish operated by "looking" what was ahead of it and then making a decision.
Figure 24: Using spheres to provide an efficient collision detection system
The end product was an aquarium that provided convincing fish behaviour, better than other such products we were aware of. It also exhibited good believable emergent behaviour such as shoaling.
Visually this was very pleasing. Kirstie created some great models and animations that, in combination with the game engine, provided fish emulation that appeared almost photo realistic.
Figure 25: The later PC version of the Aquarium product
The original Aquarium contract for mobile was extended for the PC and went through a few generations of PC variants. As of today (Oct 2018) it is still in service on PC and mobile networks.
The other significant branch to 2007 was our publishing games for In-flight Entertainment (IFE) through DTI Software. Our Bridge program featured on Emirates Airlines and Cathay Pacific.
Figure 26: IFE Bridge
Again this IFE product further added to the company image. It looked good to be publishing in Japan, providing game engines for Microsoft and now also games for in-flight entertainment. All this made it easier to spin our company more effectively.
We did enter discussion of one significant project with Unbalance, that we fully spec'ed up, and that was 3D Scuba. This engaged our imagination but sadly did not progress to a product. It was a related spin-off of the Aquarium project but would provide an infinite procedurally generated underwater landscape, which would dictate depth with extra procedural layers defining the position of vegetation, factored into depth. We learnt a lot designing this idea, even though no product came of it.
Figure 27: a mapping for a procedural underwater landscape
This was our first dip into the console market, exploiting our mature and successful Shogi engine that otherwise we had limited exploitation of. Shogi was our flagship product as it showed our reach into the Far East market and, through competition results, showed we could deliver something competitive.
This was also a collaboration between AI Factory and Rubicon Software. We created the models and the Shogi game engine and Rubicon provided the UI development. We also designed a script-based tutor system called TEACH, which Reijer Grimbergen used to create a Shogi Tutorial. This provided a rich and attractive way to learn Shogi. The general environment of the app was also agreeable, setting the game on a traditional raised shogi board (see link above for 8 additional pictures) in a traditional Japanese room with traditional stools and artefacts in the room. Outside is a Japanese garden. Animation of moves mirrored the piece rotation that would occur when picked up with two fingers and a thumb.
Figure 28: Our Xbox Shogi with the tutor running
This was released in October 2007, and had also been an exercise in developing a significant product with a company we never actually saw and who were based on an island (Isle of Wight). We completed the project but the work revealed that creating an Xbox product required a lengthy and complex submittal procedure that it was easy to fail. Xbox products are controlled by many rules to define how they should behave and the details of these are not necessarily easily understood.
Unfortunately we finally failed to freeze a release build so that any later fix updates were not possible as they demanded incremental patches. That was a procedural mistake to avoid in the future. The product was still very good and still provided a very pleasing game experience with an excellent tutor system.
Towards the end of this year we embarked on creating two games for an educational Leapfrog device for Asylum Entertainment. It is not an overstatement to suggest that this was an awkward project for us. I personally mapped the spec into our testbed but this was not wholly a success. There were issues about the specification and some "difficult" discussions with the company that had employed us to provide these titles. We were actually even wanting to bail out at one point, but we did see the project through, and the end product was very good. This was exhausting and not one of our favourite projects
Figure 29: Our Leapfrog products
What turned out to be a crucial involvement for us was Antix. They had created a realplayer that allowed common binaries to be run on any hardware that had the realplayer installed. This was essentially like a super P-code, but much more efficient so that CPU intensive games could be run. They approached us at the end of 2007 as we clearly supported multiple game engines with a common architecture. We signed up to provide 11 games. The first of these was Chess, but followed by Gin Rummy, Sudoku, Backgammon and Move it. This was to be supported on a wide range of devices, including TVs as well as all mobile smartphones, and made it through to the South Korean and Indonesian market.
Figure 30: Gin Rummy running on Antix
This was also crucial for us for an unexpected reason. It improved our multi-device and screen support and also gave us advance hands-on experience on the slightly oddball IDE Eclipse, which happened later on to be the IDE used by Android. This meant that when Android arrived that we could hit the ground running.
Android actually proved to be Antix's nemesis as it could still be run on relatively cheap hardware. The Antix project persisted through to 2013, but was then finally buried. Antix had proved valuable to us and the Antix crew were great to work with. We were sorry to see that the tide of history was not running the right way for them.
This was our first visit to the giant Games Developers Conference (GDC) in San Francisco, which we have now attended many times. It was an amazing conference with so many inspiring tracks. We made a number of lasting contacts through this.
In those days we looked very hard indeed at the budget and, inexperienced with this event, chose accommodation a tad unwisely. My room, apart from being very grim, was a couple of blocks down on Market near the conference, but rapidly in a less desirable area. The hotel had more of a "defended position" than a reception. Check out the view from my hotel window below(!!). It was one more formative experience.
Figure 31: the view from my hotel window!!
In all subsequent years I stayed in the much more agreeable, but still inexpensive, North Beach, and cycled into the conference though the attractive China town and financial district.
From our impressions at GDC, life in the games industry was apparently getting tougher, with less delegates and more developers urgently chasing publishers. Also a number of publishers going under. However, with our very low burn rate and active relationships, we seemed in reasonably good health.
As part of the conference we went 90% of the road down the path to take our Hearts AI to interactive TV, but as is often the case the project easily stalls at the last hurdle.
We had had some difficult work this year, little of which earned much, but further solidified our engineering expertise. Our company party was again at home, the last time at this address. We need to have taken more pictures! This was a doubles match at end of party on a very small table.
Figure 32: Andrew and Jeff take on Matt and Dan at doubles
This year introduced two substantial new projects into our work portfolio. We had a lot of work on and this was demanding of our time. From our project profile many contacts we made assumed we had 20 or so developers and were surprised that we only had 2. It was perhaps to our credit that our organisation and development framework was good enough and allowed us to reliably deliver stuff efficiently, despite our small size.
We continued to work with DTI Software for In Flight Entertainment and added Shogi and Go to the line-up. The latter used a licence for Hiroshi Yamashita's Go program Aya. This, with the existing Bridge program again gave us added kudos.
Figure 33: The IFE product Shogi
We were a very small company and two projects arose that divided our resources. Dan and Kirstie took up a train simulator for Unbalance and I worked on Poker for Microsoft. We engaged and overlapped at points, but for the bulk we each mostly functioned independently.
The president of Unbalance, Osamu Ikeda, had a passionate interest in trains. This was not so out of step with Japan as a whole, where trains are a common passion. Some games in Japan might be incomprehensive to Westerners. For example one arcade game emulates the circular Yamanote line that loops around Tokyo. The object of the game is simply to get the train to exactly stop at each station. It would not be a promising theme for a western arcade! This shift in reality manifested in other games too. Colleagues played a Japanese trucking game and were confused that the bonus level for completing the game was a chance to try and park the truck!
The project idea here was to provide an emulation of a toy train set that would allow the user to create a train layout on the floor of a room. The user would have to lay out the track, move around the furniture and control the trains. They would also need to be able to control the viewpoint. This project was successful and created a flexible framework that spawned a whole series of train products.
Figure 33: The IFE product Shogi
Our relationship with Microsoft was further cemented by them approaching us to create a Poker engine for them. The intended target was the Xbox product "Full House Poker". This turned out to be a slick and lavish product, full of sweet character animations and generally full of eye candy. Although started in 2009, it was not published until early 2011.
Microsoft did a great job. The product reviewed very well. For our part we needed to write a poker engine and for this we employed self-learning to tune it. This combined learning with Monto Carlo to gradually modify terms to reach some optimum set of play settings. It was new and challenging work for us. The "poker engine" link above details how we developed the engine.
Again this was helpful to us generally when talking to other publishers, as the maxim "good enough for Microsoft" easily translates into meaning "good enough for us".
Figure 34: Microsoft's lavish and slick "Full House Poker", based on AI Factory's poker engine
We also started work with John O'Neill of SparkPlugGames, who I met at GDC. Through him we published Aya Go, based on Hiroshi Yamashita's award winning Go engine. This was written in C with plenty of global statics. We massaged it so it fitted our Fireball framework and replaced file reads by static coded tables. This was a moderately good Go program at about 7 Kyu. It was nice to have our first foot into iOS!
Figure 35: Our first iPhone game, through SparkPlugGames
Work continued with the Aquarium, taking this through to Windows 7, with a touch screen interface. One of the exploitations of this is the ability to frighten fish or draw them to the point that you touch the screen, adding a further sense of immersion to the experience.
Of course we were doing other things in parallel, and attending yet more trade shows and conferences. Among this was Casual Games conference in Seattle in July. That also offered our first chance to visit the Microsoft headquarters at Redmond, where I spent a whole day discussing the project and generally getting to know them.
Figure 36: Microsoft HQ Redmond
We also shared knowledge of our techniques with other parties, which became part of a course run at Tokyo University of Technology. This helped us develop what we were doing by going through the process of explaining it to other parties. It tightened up our own understanding of our own work. Again it offered us kudos to show that we were giving lectures in Japan on the games industry.
Note that we had already established most of our casual games inside our Fireball framework and published these on the Gizmondo and Antix, so they had proved an excellent rehearsal and preparation for platforms to come.
This is where Android started to take-off for us!
Optime Software approached us in August 2009 with a view to licensing our game engines for publishing on the iPhone. Their original idea was to make single licence purchases but this morphed into revenue share, which fitted us better. Since we had no presence on the iPhone, and Optime could still go elsewhere, they had the advantage! Their CEO Jon Schlegel was pretty much the most capable negotiator we had dealt with yet, so we had to focus!
This was very good for us and over the following years they published 6 titles using our game engines. This was about the best most reliable income we had had and started our lift-off into an income profile that looked more solid.
Although they have published no new titles using our engines over the last few years, we still have a very solid relationship with Jon, always meeting up for a private dinner at GDC. Jon's career is probably a master class example of how to run a successful business!
Figure 37: Optime's first product from AI Factory
Optime published Hearts, Move it!, Backgammon, Sudoku, Spades and Reversi from us. The first of these was Hearts, published at the end of 2009.
Before we talked to Optime about iOS we were already ramping up to create Android games, helped by our advance experience on the Eclipse IDE through Antix, which was needed for Android development. At this time, knowing we were entering the new Android space and that iOS was already established, we might have been looking for a cross-platform implementation. However our existing licence deal excluded us from iOS, and no other platform looks that promising, so the imperative for cross platform was somewhat less. We instead went for Android native and actually this made our job easier, particularly as native was anyway more likely to work correctly than any cross-platform SDK.
Android native at that time also was Java-based with some support for linking to C++. However the UI had to be in Java (this has since changed). The consequence of this was that Dan needed to switch from his familiar domain of C++ to Java in order to support this. For the first time the two engineers at AI Factory were now using different programming languages. This created a pervasive precedent that dictated all our engineering from then on. If we were starting much later, when C++ was available to drive the UI, we might expect to be all C++. We created our own legacy of how our engineering was and how this thereafter persisted.
Our first chosen game was Move it!, which was a puzzle game entirely created by AI Factory. Move it! was particularly challenging to create. With my background in tree search I thought creating a puzzle creator with solver would be well within my grasp, but quickly found that solving deep puzzles might easily take decades, not minutes to solve.
I hit a brick wall, stepped back on some other project, and returned at the start of 2010. A new bespoke approach suddenly yielded much faster solve rates, sometimes down to 20 seconds or so. This proved an immensely interesting project, where my initial approaches were far from optimum. You need good methods to create candidate puzzles and good methods to test if they can be solved, and then good methods to create near optimum solutions. This is discussed in detail in this article on Moveit!.
The graphic design of the game mapped each piece as a combination of square segments, so the vertical yellow piece below was a combination of 2 square textures. Each shape was mapped to a matrix of texture IDs to construct that shape. It was the most efficient option for us.
This was the first board or puzzle game product for us to include music. Since the music was to be played endlessly while the user was solving puzzles, we needed a way to keep it feeling fresh. If we had multiple long scores then the app would be too big. Our solution was to take 3 Spanish guitar loops and randomly select from each of these. The result was a play track that appeared to improvise endless play combinations. Any one 3 minute segment would almost certainly never be repeated. The quality of these make it hard to spot where the joins were and the end product was compact and effective.
Figure 38: Our Move it! game, shown here as an animated GIF of the Antix version
We were now embarked on a long history where most of our attention was to be dominated by Android, which was proving to be our most lucrative source of income. We had got in early with limited competition. We analysed the Android charts to figure out what worked and gradually optimised our apps.
In hindsight starting with Move it! was probably not optimum. It was a unique new game and felt like the best starting point, but experience has shown that the games that succeed best are the classic known games, simply because a significant part of discovery is search, and people search for games they know.
The Backgammon game engine was based on IP we licenced through the liquidation Purple Software IP. It originally came from Oxford Softworks but we had significantly re-worked it. This was launched 26 Aug 2010 and Chess, which was based on our Treebeard engine, was launched one month later. That gave 6 products in total, 3 games available in free and paid versions.
Figure 39: Our Backgammon Free android product, now our 2nd most downloaded product
The Chess Free product entered the charts as the 2nd highest ranked chess, where it stayed for a long time, before eventually moving well ahead of its rival "Chess for Android". Its top level played somewhere between expert and master level, which is fine for 99% of chess players.
Figure 40: Our Chess Free product, now by far our top downloaded program
Having created Move it! for Android and Antix I was keen to extend the technology to another Puzzle game Sticky Blocks. We were also mindful of the neglected iOS market. One path to make this happen, without burning too many internal resources, was to work with the external Tony Warriner who we had collaborated with in the Gizmondo project. This worked on a revenue share basis. He would take it to both Android and iOS.
Figure 41: just one part of an animation of a gel piece
This new variant added a new dimension in that it had "sticky" pieces that were basically blocks of water/gel, then if they came into contact with other sticky pieces, they would fuse into solid pieces. Unlike Move it!, this might render the puzzle unsolvable if the wrong fusing was made. The tech used for Move it! could easily be re-cycled for Sticky Blocks. As part of this I also took on the artwork creation as I had a clear idea of what this should look like, so this became a pet project. This included a low-tech solution of using complex programmatic animations cycling a series of bitmaps.
Figure 42: Our Sticky Blocks app for Android
The lessons learned from this included the issue of grading the puzzles. I was stretched as I was deeply involved with all the other company processes so did not devote enough time for this. In hindsight I have ideas that would have made grading much more effective. Instead the grades were simply an amalgam of the puzzle depth, time to solve and the input from testers. There were better ideas around and a consequence was that a number of puzzles were either too easy or took hard for the section they occupied: a lesson for the future. However once released the game is locked in stone. It still gained favourable reviews and I think still a credibly good puzzle game.
We were not doing all this for free, so we had to figure out our best monetisation model for Android. The obvious one taken was to have a free version, with banner ads, plus a separate paid version with no ads. This relatively simple model has persisted through to the current day.
Our choice was to use Admob/Adsense, as these were the big players at the time. There was no IAP as that did not exist yet, so there was no path to migrate a free version to becoming a paid one. However we arranged it that users that had saved a game, or saved stats, could retrieve them when they also purchased the paid version. Of course this meant that they had two versions of the same program and had to delete the old free version.
We did not want branched paid and free products with different artwork, therefore we arranged that ads overlapped some headline name of the app, so when ads were not available that the program looked ok. The paid version basically looked the same as the free version with ads removed.
Of course our presentation of our apps in the Android store is critical to the success of the product, but we need to exploit other means of exposure. One tie-up was with Heyzap, who we connected with at GDC. Heyzap was a social network that also provided automatic feeds through to Facebook and Twitter and had the potential to become a big player on Android. It offered the attraction that, once installed, players could track any game on Heyzap, winning awards, even if that game had not been Heyzap-prepared, so there was an automatic potential tide there to carry Heyzap into prominence, even if games developers did not pro-actively try to support this service. We had been in detailed discussions with Heyzap, requesting ways to improve their service. We converted 3 of our apps to support Heyzap, providing an in-game button that invited the user to login directly.
This was an interesting avenue, but eventually Heyzap were eclipsed by the coming Google Play Games, which took their market away.
We also used the DailyAppShow to prepare promotional videos for our products, also appearing on their home page. They were also paid to feed into many other media channels. It was relatively low cost, but gave us a finger into this type of promotion.
Figure 43: experiments with video reviews. TheDailyAppShow
Supplying ads required some special engineering. It was not ok to request an ad at just the point it was to be displayed as this could cause the app to freeze. Our apps were designed at outset to start-up and initialise the ad SDK so that it was ready when the ad was later first shown. Getting this wrong would deliver a bad user experience.
Another key aspect of design, which was actually much more important than we imagined, was that we carefully designed our apps to share the same UI characteristics. This in a sense made our life easy as we did not have to re-think stuff, but it was not until we had an external engineer try to replicate our UI philosophy that we realised that any deviation from the norm was very disturbing. It is very likely that the easy similarity of one of our apps to another significantly contributed to our success.
As a last step into in-flight entertainment, out final product for DTI Software was the Chinese game Dou Di Zhu. It was our first game engine to use the Monte Carlo method of analysis, so provided us with this initial experience, which we carried through to other products
We had only just released our Backgammon when we found that we faced a huge barrage of accusations that our app cheated.
OMG! What have we done wrong?
We knew that the app did not cheat by design so we then checked to make sure that nothing was going wrong by accident and that the random dice rolls were working properly. Everything was correct.
However a side look at other Backgammon programs revealed that ALL of the other top 40 programs are also accused of cheating. We attempted to deflect the accusations by responding to e-mails, but all we could do with app store reviews was to mark such reviews as unhelpful. We could not respond to reviews! Later down the line we had a chance to request this at a Google Developer Day. When I did, suddenly a throng of hands also shot up saying "yes please! We want that too!". A few months later this was added! Result!
We also published our own complete thorough riposte and explanation of this phenomenon in our newsletter article Backgammon Programs Cheat: Urban Myth?? and in a specially created web link that we could paste to user e-mails. However we made little impact. This says something about the frailty of people and nothing about our Backgammon.
As part of our involvement with Tokyo University of Technology I gave a lecture there in May on the development of our company. More significantly I also gave a keynote at Imperial College for the AI & Game Network, that drew in researchers from all across the UK and also Trinity College, Southern Ireland. However the most significant groups were from Bradford, Imperial and Essex. I had been approached by Prof Peter Cowling earlier to write a letter of recommendation for research into Monte Carlo Tree Search (MCTS) and, as I truly believed in its value, I wrote a strong endorsement.
Figure 44: The impressive Tokyo University of Technology
This turned out to be a profoundly significant event for us as it started a collaboration with Peter that carries through to this day. He is now based at York University and teams run by him have made a substantial and vital contribution to AI Factory's engineering. The starting point for this, first at Bradford and later moved to York, was by Ed Powley and Daniel Whitehouse who took our core game framework with our Dou Di Zhu engine as a testbed for trying out MCTS ideas. This was immediately helpful as we had regular meetings to discuss progress. It was helpful alone in just having parties to discuss AI with.
We are not just 24/7 engineers and one significant invasion of our company time was the arrival of my first daughter Lucy at the end of 2010. In consequence no Winter 2010 newsletter appeared and indeed this inevitably meant I was spread even thinner than usual from then on.
This is the year when we really got going on Android and one welcome consequence was us being awarded the Google status of "Top Developer".
This and other such things help to further solidify our reputation. At our peak in 2011 we had 5 of the top 15 apps in Brain & Puzzle free in Android. It was also noticeable that we were becoming known. More often than not when I met a delegate at a conference that they would have already heard about AI Factory. By 2018 most have heard of us.
Although we were starting to be heavily focussed on the Google Android store, we were aware of other Android outlets, so became involved in discussions with new publishers. Three of these were in South Korea and one in Beijing in China. The latter gave us a flavour of how the Chinese worked as they over-played their hand and played hardball. We backed off and instead elected to work with the Korean company StraStar. Through them we had 4 titles published on the T-Store:
Figure 45: Our products on the South Korean T-Store
Figure 46: Publishing via Joymoa in japan
This worked well and they were a nice group to work with. We still maintain contacts. Through them we also embarked on publishing with Joymoa on the Japanese KDDI store as well.
This year we published 6 new titles on the Google Android store. This was eased by having our common engine and UI framework, which optimised the delivery and support.
Reversi is a classic old game, more commonly known through a variant called Othello. This included some cute animations of pieces flipping. Four in a Line showed some departure from our generic UI, but in many respects followed the path we set with the previous apps.
Figure 47: Reversi and Four in a Line
This had already been released on iOS through SparkPlugGames. A reason to launch it early was that there was no competition and we might steal a march on any rival. In practice it proved to be a relatively low revenue app that was not well-suited to ads. However it fitted well with our "AI" badge and was the ultimate board game that should be part of our portfolio.
Checkers was an inherited engine from Purple Software, but substantially re-worked by us. Sudoku was a new challenge and part of this was to create solvable puzzles. This required a program to search from an empty board to create a puzzle with just one solution. This is non-trivial. We also needed to provide puzzles at different grades of difficulty. All work on such a game within our generic framework provided an engine that could be easily re-cycled for licencing out with minimal pain. In this case the same engine was passed on to Optime through to iOS.
Figure 48: Sudoku and Checkers release for Android
Our Spades program had been originally written by myself for Purple Software. It used a probability based evaluation that combined inferences to predict the probability of any one card played winning a trick. This had some nice sophistication in it, but did not stand up well in all parts of the game and could play weak moves. That engine was in a very different format and Dan took this and inserted it into our Fireball framework, which was a non-trivial task. I further worked on this and the product was released.
Hearts had a similar ancestry and similar processing. The hearts program has been tested against Microsoft's free hearts provided by Windows and was clearly stronger. The net product was in stronger shape than Spades.
Figure 49: The first releases of our Spades and Hearts on Android
We licenced 5 of our games to run on the "Andy Pad" tablet designed specifically for children. This was a sweet device that would confine access to a child-friendly store. These were the days when Google Play had no real parental restrictions, so this was good idea. It was an easy and comfortable contract.
Figure 50: The Andy Pad device, using Android 2.3!
The Google console provided breakdowns of downloads, deletions, active users and reviews etc. This allowed export of data to CSV files so were open for our analysis. Unfortunately different parts of these provided stats did not quite tie up, but at least this should have given us an idea what was going on.
Just looking at these graphs in response to changes made was not enough. The market ebbs and flows so that a dip or rise caused by some change may be lost in the noise of the market movement. However we had the fortune to have multiple apps, so we could weight any one app performance against the geometric mean of the rest of our apps. This worked very well and a wavy download line became roughly flat after comparison with the geometric mean of all other apps. So any change to that app could be exposed by any net shift in the line.
We endlessly created spreadsheets to analyse this. It was hard work but gave us meaningful information and allowed us to change how we did things to improve downloads and retention. Checking our "Market Stats" folder shows that over 9 years we generated 186 different analysis graphs to track our apps!
The cumulative impact of all the adjustments we made must net have significantly improved our situation.
Figure 51: A plot from one of our many app analyses
We also entered this slightly oddball ZEDGE store from a NY company. This was an app on Google Play that was designed for retail of ringtones and wallpapers, but also could list apps that would be hooked into the Google Play store and charging us a cost per install (CPA) for each install they made. It was something new to try and did not demand any mods to our apps, so we gave it a spin.
In September we were hit by a claim of a patent breach by the patent troll Lodsys, who had also been in the news. The claim was essentially absurd and spurious, but depended on a threat scaring developers into surrendering revenue share to Lodsys. Their patent was based on a fax machine that allowed the users to answer survey questions. Their premise was that they "owned" the idea of storing on a central server the outcome of a 2-way interaction between two sites! They cited 4 breaches, 2 of which are below.
Figure 52: one of the cited "breaches" identified by Lodsys
Their explicit breach was that our Google Play store listing had a "buy" button for our Go, which would of course setup a 2-way transaction between the user and Google on two sites, then storing the outcome on a server, which breached the patent on their fax machine survey facility! Another cited breach was simply that we had an app that "can be used by respective users in different locations", so that having an app that could be used by different users in different locations was a breach! Lodsys were registered in Texas, which was a patent friendly state, even though in all probability there was no active office there.
Figure 53: one of the other breaches against Lodsys patent
This burned time as we considered our options, including attending an on-line Lodsys boot camp. One of the advantages they had was that if we contested the claim in court in the US, which we would certainly win, under US law we would not be able to claim the costs of bringing it to court. They therefore could threaten us with no danger of us contesting. The option of employing lawyers or patent experts was therefore of little point.
However we could analyse their claim with forensic eyes to assess what was going on and clearly they had selected a poor app to base their claim. They looked at our Go app, but that was by far not the top earner. They had looked at paid earnings and overlooked that almost all of our revenue was ad revenue on other apps. So the person identifying the claim was not skilled, but the presentation of the claim looked professional. We surmised that they basically had an army of interns with some fancy claim software and just went through the entire google store.
Our final strategy was simply to remove the hooks that had any remote bearing and claim fault of the other claims, and then just sit back. They never got back to us.
It seems from follow-ons that their plan started with a claim against Google and Apple, who refused to play ball, and Lodsys took the view that unless they did play ball, then they would hit their customers instead, which they did.
One very significant step we took at the end of the year was to experimentally try using the ad mediation service MoPub, which was still in beta at the end of 2011. We had been recommended at Droidcon to consider them. This had been a period for experimenting with advertising options, starting with Admob and then switching to the mediating service Adwhirl, which added access to Millennium Media. Finally we have been switching to this mediating service MoPub, giving us access to additional networks, including Jumptap and InMobi. It was a learning process and as the number of networks expands the complexity of optimising this increased. We had been working very closely with MoPub to help them tune and develop their system.
One key attraction of MoPub was that they offered the possibility of auto-balancing networks. In the initial phase they manually balanced networks for us, adjusting eCPMs depending on what traffic each network provided. This close relationship with MoPub was very helpful in allowing us to better understand the ad network business.
We had a party, but no-one took pictures. The year had seen a number of other contracts licencing out our apps, not listed above. This included ASBISC in Cyprus, Ematic USA, Exent USA, Sonic Boom USA and a significant contract with PC Treasures that provided income for many years.
We now had 11 apps on the Google Android store, which was later renamed "Google Play" and which we will use in further references. Android at this time had some serious fragmentation, with Android 2 being more of a mobile design and Android 3 only for tablets. Added to this was Android 4, which was intended to be a re-merge back to a single version. Supporting all these added a lot to our work as it became an issue trying to support these different versions and also nuances linked to individual devices.
Work on Spades shifted to trying versions of Monte Carlo. My first deviation from the original game used a full evaluation rollout, re-cycling the old evaluation. This yielded a substantial improvement, but was still vulnerable. After working with Dou Di Zhu, the researches at York took our Spades game engine and started experimenting Monte Carlo with our engine late 2012.
This was an important addition to our Android apps. Its original purpose was to provide both a mechanism to allow our apps to cross-promote each other and to also allow control of the ad networks. The basis of this was to have a text file stored on the internet that our apps would habitually load in order to pick up config instructions. Initially this would provide a fork so that we could access two different mediators. The motivation for the latter was that MoPub were still in an immature state and managed to crash in some versions. We wanted to have the means of manually switching between mediators if an issue occurred.
The format for mediator selection was as follows:
In this case mediator A1 was MoPub and A2 was Admob. In this case each letter indicates an app, so that from this "B" is Backgammon and "C" is Chess, who were here set to use MoPub. This was very flexible.
The cross-promotion part simply provided a long list of adverts that could be shown, each assigned to one or more apps with different probabilities.
|B1T::+bIf you like this game, you might enjoy Google Play's top ranked Backgammon, played by millions worldwide!|
If one app wanted to potentially show more such ads than another app, it could have a duplicated and edited entry. The app would keep a record of which was the last ad shown and then when next showing an ad would step through these until some probability threshold triggered an ad. This system did not exactly determine the probability that any one ad might show, but simply provided a rank against all competing ads. This allowed ads to simply be added without needing to change other ads to re-balance.
This system has continued and evolved. Of course if millions of apps are reading this file each time they are run then the system could easily overload. To ameliorate this each app kept a "most recent" copy of this file used and one parameter in file dictated how often this would be re-read. If a read failed then it would back-off and use the old version. If the system was still overloading the site, we could tweak the parameter to cause the apps to load less often.
This system has expanded and taken on many more admin tasks, now providing 39 different config commands. This is very useful as it allows us to control apps already in use, not just new releases. If there is an issue, we can then mod this file, which will change the existing app behaviour. If we want we can, with a single command, turn off all ads or switch networks with a single command, although this may take a little time to ripple through all the users.
This type of mechanism was much later on introduced by Google as "Features", allowing running apps to be controlled via the console. However we got there first.
This was our first Android app to use the Monte Carlo method. If you check back to one of the first articles for 2007 you will see "Predicting Game States in Imperfect Information Games" that describes the inference system used in a Gin Rummy program written some time ago and a predecessor of this app. As indicated in the article the inference system it used was ideal for using with Monto Carlo and indeed we did exactly that. The engine at the top level plays a very high skill level, so needed to be clearly weakened for lower levels.
Figure 54: Our Gin Rummy app for Android
Amazon was by 2012 already an immensely powerful force in the market, with a bunch of their own mobiles and tablets using their own flavour of Android. The format of these devices did not seem attractive as they immediately force you to view an ad on start-up and thereafter the format of the interface is disturbingly different to regular Android devices. However Amazon managed to pitch their devices at a very attractive price point and clearly are successful. We had already checked out rival app stores to Google Play and, if anyone was going to succeed, Amazon was. So we posted our apps there. This imposed some branching of the apps, which was inconvenient. We also needed AIFNET to tell our apps where the app stores were.
At various points we had considered making use of analytics to find out what our users actually preferred and did with our programs. Up until this point we endlessly made intelligent guesses, but analytics would free us from this and we would be able to find out what users really wanted.
Initially we considered Flurry, but then elected to use the Google Analytics. This was a game changer and removed the stress of guesswork. It was wonderful to have exact, but completely anonymous, figures for whether or not users had sound on or sound off. Measuring these things by assessing our own personal preferences was likely way out, as we were far removed from the average user. In many instances these were a succession of binary choices, but we also found out the win rates against each play level. We also found out which background art they preferred. This is all very good info.
Our end of year was looking good, with apps well established on Google Play and a well-organised analysis and tracking of these. We had missed a few Xmas meals after the new family addition. This time we expanded with many other friends and colleagues.
Figure 55: Our XMAS party, inviting many friends too
By the start of 2013 it was already clear that we were in healthy shape. Our apps were earning well and we were well-placed in the charts. That took some stress away, however we still had to remind ourselves that we were still a very small company with almost no resources. There were very powerful players out there in the casual games market, with multi-million dollar budgets that might choose to blow us away by out-spending us on promotion, so we could not afford to be complacent.
The year start was monopolised by new input from the York group on Spades, but we did provide a new app Solitaire and had our first Windows 8 product. Finally later in the year we presented our Spades work at AIIDE at North Eastern University, Boston. It was also our first dip into Windows 8. Later in the year HRH Princess Anne was given a presentation of the work on Spades at Royal Academy of Engineering Summer Soirée -Engineering: Design for Living at York University.
Figure 56: Prof Peter Cowling explains to HRH Princess Anne the work on Spades and MCTS
The York group had worked for a while on our spades engine and manage to create a variant of Monte Carlo Tree Search (MCTS), called Information Set MCTS (ISMCTS) that provided a version of our spades that beat our existing spades by a substantial margin. This was exciting news so we quickly prepared for a new re-release.
However this really really did not go to plan. One characteristics of MCTS is that given all moves lead to about the same outcome, that it will more-or-less choose at random. Our direct testing had not picked this up and the release version was greeted by a storm of complaints, so we had to move quickly to rectify this.
An issue with Spades is that humans are less aware of when a hand is already lost and instead will play to try and win, even when actually a lost cause. So the program appeared to play very weak moves, but did so knowing it no longer mattered. The ISMCTS version beat the old version by a substantial margin, but was actually perceived to be much, much weaker.
We floundered for some time coming to grips with this, applying methods to deal with the anomaly. The chart below shows the performance of the 4 different versions of Spades, where the "defective" new version was Pure ISMCTS.
Figure 57: The performance of the various versions of Spades
After our prolific year the year before, this time we only managed one new app for the market, but this still needed to be written from scratch. On the engine side there was the issue of being able to generate solvable deals. We wrote a solver, maybe not the fastest, that allowed us to create sets of Easy, Medium and Hard puzzles. We also provided random deals which might not be solvable.
Part of this requirement was the need to provide a compact database of solutions and there we managed to do very well. Our article Pushing compression limits using Plausibility analysis shows how we managed to compress this overall by about 100-fold, and in one extreme case by 1500-fold. A version of this article was later on published in GAME AI Pro 3 - Collected Wisdom of Game AI Professionals.
Net this was a pleasing product but, despite all our sophisticated cross-promotion from all our many existing apps, this one struggled to be very highly placed in the charts, although many of our earlier apps were. The writing was on the wall. It was going to be increasingly more difficult to push new titles high in the charts where they needed to be to really succeed.
However, to date, Solitaire is our highest earning app per user of any of our apps.
Figure 58: Our Solitaire app
Looking to find other new ways to make Spades more immersive, we added facial animations to the cpu players. This would made them respond to events such as losing tricks they might have won and also idle animation so that they might glance around them between tricks. As ever, from experience, people do not like having "enhancements" thrust upon them, so this and all such changes we provide the option to switch off. The overall impression though was that these were liked, with a few people being freaked out.
Figure 59: Our cpu character Sarah makes faces!
In collaboration with Ben Winiarczyk of Blit, they took our chess engine and created our first Windows 8 product. The upside is that we could take a dominant position in this new market, which we did. The downside was that Windows 8 apps were still a tiny market. Not much came of this!
Our year also saw some considerable effort trying to agree a contract with Kotori (Gorm Lai) to take our games to iOS, but were sunk in the complexities of the contract, so we eventually backed off! We also signed with Intel to take our games to the Intel store. The latter was not expected to earn us anything, but it looks good to have our apps as the one Intel wanted to show off. I had met them at GDC for a private invite-only gathering, which was conducted as-if a board meeting. It was very civilised! Finally our android apps were taken to the IQZone and Miniclip stores in separate deals.
For our party we repeated the format of the home-hosted buffet party. Gradually we were pulling in more, including researchers from Essex and York University. A good opportunity to celebrate our success!
Figure 60: Home Xmas party in Pinner
The year started with us giving a presentation at GDC San Francisco in the AI Summit. It was a bit of an energy burn but was good to help further focus on what we had done in spades.
We started the process of licencing our game engines to Unbalance in Japan. Part of this was to keep our relationship fresh until some other bigger future opportunity might arise.
This year saw our final new in-house app Euchre. It can be noted that after our rush in 2011 when we launched 7 Android apps, we had dropped down to just one per year since then. Part of this is that we needed new game engines and part the efforts to maintain the existing apps. Our intended model had been to endlessly release new apps, perhaps one per year, but since 2011 the market had exploded. Despite our sophisticated cross-promotion and market analysis, it was hard to help a new app make any real traction. Our only real earners were the apps we established early on.
This is the point where we started licencing our game engines to Unbalance for mobile work. The entry point here was Windows 8, but the intention was that these would also migrate to iOS and Android. The first here were Spades and Backgammon:
Figure 61: Our first Spades and Backgammon on Windows 8, through Unbalance
Again we had a Euchre app written by myself while at Purple Software, but then carried through to AI Factory. However that version was weak and we needed to immediately progress to an ISMCTS version. This offered good promise of a decent performance as Euchre used far fewer cards and for shorter hands, so more amenable for Monte Carlo solving.
Figure 62: Our Euchre product for Android
We were approached by Fuhu to have our games on the Nabi range of tablets. They already had contracts with big publishers including Disney. Although we negotiated but eventually the opportunity passed, this was exotic and worth a mention.
I since purchased one of these and it is a stunning piece of kit, with really good dedicated apps for children. These provide entrancing animated story books, where you turn a page of a book lying down in front of you and the story characters pop out, setting some task. Another app had a world you needed to explore, where you drew your own character and the app animates it. Cool stuff!
In hindsight I think maybe we misplayed this, asking too much. This would have given us good exposure to have been associated with such a quality device. Of course there are no free lunches, and we would still have had to work on our apps to fit this, and maybe that did not make economic sense.
It is hard to claim that this really was any significant benefit, but we commissioned some branded pens for AI Factory! It was something to pass on and, in some small measure, adds to the sense that we are being proactive in our outlook! At the very least we never had to scout around looking for pens again back here :)
Figure 63: Our pens. We also had another type and also LED lights
With success comes piracy and we found that our catalogue of games had been stolen wholesale and re-published in all territories, except the UK. We also had many individual cases of theft, where the pirates did not even remove the credit to AI Factory in the description!
Figure 64: One of the artworks used to promote stolen copies of our apps
All these things burn time. The only consolation is that often they failed to remove our ads, so we earned some revenue from these pirated versions.
A fairly quirky event was having our Chess Free centrally featured in the movie short "The Knight Train". Our chess program played a pivotal role in this cute film. We have had a few other such minor involvements since, always for chess. It was a fun distraction.
Figure 65: The move short "The Knight Train" that featured our Chess Free
Contracts not mentioned above include one with Hydromassage to take games to fitness machines. Our business was now starting to look very stable. We had reached 90,000,000 downloads. Time for a cake!
Figure 66: Our first designed Android cake
This was a significant year as we released no in-house Android app this year, or in any following year. A non-inconsequential point though was that 2 of the 3 people in the company moved house this year! That burns energy and time.
However an important issue was that the return for the last 3 apps Gin Rummy, Solitaire and then Euchre, published over 3 years, showed diminishing returns. With each passing year the Google Play market grows, now over 9x the size that it was at the end of 2011, after we had already published 9 apps. With that increased bulk of rivals came more proactive marketing by other groups, which further buried attention to us and made organic growth harder to sustain on its own. Our strength hung on being in there early with a number of apps, allowing us to establish early "top app of each type" for a number of our titles.
Our reach continued to expand as we were approached to provide games for the US prison service, an unexpected avenue. This project progressed but we would have had to branch our apps and in the end this would be too disruptive.
The Amazon app store was something we gradually neglected as the return was not spectacular and it distracted us from Google Play, where our main business was. It required maintenance of two builds of each app, which was annoying. However Amazon came up with something new, and approached us while this was still a big secret. Their model was different, paying us for hours played on the apps, rather than depending on ad revenue or one-off app purchase. This was not so bad and we earned a respectable income.
Long term though the idea fell away and we imagine the reason for that was the uncomfortable way that users got hold of the Underground store on non-Amazon devices, which needed them to click away warnings of this "unknown" app downloaded from outside Google Play. Also finding the store at all was difficult and somehow did not feel like it was a main stream entrance. Google prohibited this store being on the Google Play store and probably also did not allow it to be advertised via apps on Google Play either. This probably left users feeling uncomfortable and in consequence it failed to gain wide acceptance.
It was an interesting idea with a store with a cool name that perhaps fitted its "anarchistic" role, operating outside the "safety" of Google Play.
Figure 67: The banner of our Amazon Underground presence
We returned to include a partnered development between Tony Warriner and us. I provided the game engines and artistic direction and Tony provided the UI for the product and, through his partnerships, also delivered artwork.
This release product actually provided 3x3, 4x4, 5x5 and Gomoku inside one package, so was much more capable than the rivals. Our primary competitor was actually our US partner Optime with their Tic Tac Toe product (only 3x3). This product has always been the top Tic Tac Toe product, from inception to the current day (2018). It does not have a high rating and has not been updated since 2013, but is still #1 Tic Tac Toe and #99 board game! It has 10m-50m downloads. Our Tic Tac Toe is #3 tic tac toe and #193 board game with 1m+. This is a testament to getting in early!
Figure 68: Tic Tac Toe, including Gomoku
These apps did not exactly follow the AI Factory structure but, in this version and further developed versions, added significant extra gloss, including a diverse set of opponents and a dynamic competition ladder, with cute animations. Characters with look happy or sad, depending on the outcome.
The game engines were programmed using Monte Carlo, not because that was the optimum choice, but simply to experiment with Monte Carlo with a perfect information game.
Although we had just published a Tic Tac Toe that included Gomoku, there was a market for a stand-alone Gomoku as well. This also conveniently could simply re-cycle the existing app. However it was an invite to create a stronger Gomoku, so time was invested in making the game engine stronger and adding more opponents.
In addition to our established periodical, AI Factory has also been feeding into other publications, usually as part of a shared publication, but also with our own chapters in the books Game AI Pro2 and Game AI Pro3. In Pro 2 we published our bespoke method Interest Search, which we have used for some 18 years and finally felt it should enter the public domain. This method massively increased the speed of minimax, allowing substantial strength improvements through much deeper searches. This method was core to the tournament success of the Japanese Shogi program "Shotest". It was also core to our Chess/Chess Free that uses our Treebeard engine.
Figure 69: The first book we published in
Unfortunately a growing new issue that burned up so much time was dealing with bad or rogue ads. Many of these were simply defective programmatic ads but some were malicious. An issue was being able to track them down. With the growing complexity of our ad infrastructure, with dual mediators and many networks, it was hard to find out where any particular rash of ads was coming from. The blunt, slow and costly solution was to simply turn off networks one by one to see who the culprit was. This was expensive: tracking just one ad could easily cost us $10k. The other downside was simply the time burn. We have better things we could be doing.
By now we were topping over 120 million downloads, so the opportunity for user complaints magnified. The upside was that 120m downloads meant that we were doing well!
An immensely important enhancement provided by Google was the new automated A/B testing. We were already able to test in-app artwork and features using Google Analytics and already had a sophisticated procedure to monitor the impact of app changes comparing the download rate with a geometric mean of all apps, to allow filtering of results from natural market fluctuations. However the latter was not perfect and very time consuming. We could also use this to measure changes to the store listing, but would still be approximate and time consuming.
Figure 70: a section of the spreadsheet used to record the results of A/B testing
The new A/B testing allowed direct testing of multiple changes in the store listing, critically over exactly the same time period and monitoring the difference in downloads. Finally it continued the experiment until it was able to measure a significant advantage of one test over another. This was amazingly simple, quick to setup and allowed us to easily run many tests in parallel. This was the highest return for effort we had had. Overall we increased the net downloads over all apps by 11.28% and up to 12% for one simply tweak. Sometimes adding just a single word to the 80-character description might have a big impact.
With more funds we experimented with video for the app store from a new company GBoom/AppVJ. The results were pretty good, but sadly this did not show any measurable impact in download rate, according to the A/B testing we did. The products were pleasing though, with a nice snappy voiceover. They explained the apps well. You have to try these things.
Figure 71: One of AppVJ promo videos
We had moved house and could invite more people. Our growth continued and the new Android cake celebrated 112,000,000 downloads.
Figure 72: Xmas party with our aquarium program in background
The start of 2016 was a little monopolised by the revelation of the work done by Deepmind into Go. This spurred us into getting a better version of our Go program.
With the surge in interest in Go after the announcement that Deepmind had late last year defeated the European champion 5:0, then the proposed coming match against the world champion Go player Lee Sedol and AlphaGo became the big story. We wanted to exploit this new interest in Go, so re-connected with Hiroshi Yamashita, who had since updated his Go program Aya to use MCTS and was playing much stronger. Again this was a C source, with all comments in Japanese, so was not a cinch to integrate. We needed to be ready for the Lee Sedol match to maximise advantage, and this coincided with GDC SF. I stayed up late watching the matches, which were held in Seoul and the last two coincided with the trip out to GDC San Francisco and the first day of the conference. In the mayhem of this and finalising the release of our updated Go, I managed to miss my flight to the US as I had skimmed the wrong part of the ticket for the departure time. Suddenly my direct flight to SF had to be replaced by an expensive hop to New York, then San Francisco. The "plus" was that the streaming video coverage of the 4th game was shown on the last hop and was excellent. I had a great seat to watch this game, the most interesting yet.
Hiroshi's Go did indeed benefit and we saw a 10-fold increase in downloads. His new engine provided a much better credible opponent, this time stronger than most Go players rather than nearer an average player.
Figure 73: Lee Sedol faces AlphaGo
Spades, although only our third most popular app, was still a very important app for us and (unlike our Chess) invited the most requests to make it stronger. In consequence we felt obliged to concentrate on making this our main engine activity. ISMCTS still felt like a new domain for us and actually new in the field, so we were spending much time looking for new ways to improve it. To help in this task we gradually accumulated more and more beta testers and indeed this proved to be the best way to explore improving it. Users found plays that might be suspect and provided good test cases to analyse. The console testbed we created gradually become more capable, allowing us to simply and easily run long analytical tests on any given position.
We were in better financial shape so were ready to consider more expensive video presentations for our apps. We tried one other new company for just Chess, which anyway was our top product.
Figure 74: The new look video for Chess
Our work profile had continued to narrow as we realised that improving our existing apps was our best plan. The total downloads had increased, but by only 10m. It still all looked good. Our best party yet!
Figure 75: Xmas 2016 cake changed shape a tad.
Of course the usual rounds to GDC SF, Develop Brighton and Droidcon, but again the main focus was Spades. Clearly we had narrowed our work, so that no new projects were discussed. There were products we had it in mind to create, but while other things demanded attention, these could not happen.
GDC has gradually morphed into a chance to reconnect with our existing partners and also colleagues of many years. The energy and professionalism of the many tracks offers inspiration and helps steer us back into appreciating where the games industry is going. Each year we hold a meal at the R & G Kearney.
Figure 76: Our regular hosted meal at the R & G
The significant new change to our Spades was the addition of speech bubbles. This was been a welcome diversion from serial AI improvements, which do not deliver any visible change, just the more abstract "better play". Speech bubbles offered a chance to also design a new framework to manage them. It would have been of no value to simply have AI opponents just make random remarks. These needed to be tied into the game situation. This set us up for a protocol design task to allow the game engine to talk to the UI. The game engine would flag when significant game events had occurred and the UI would register this game event and decide what response might be delivered. It might be a comment to all or just to the partner of that player.
In all we identified 36 possible events and since any event was not going to be tied to a single response, we provided a pseudo-random selection from a number of pre-determined responses assigned to players based on characteristic traits. Even this random selection was not pure random, or a round-robin play, but a system that randomly chose a response from the last "N" responses that had not been played. This avoided the danger of repeated or clustered responses and also any familiar response ordering. In total the app has 812 possible different speech responses.
This was received well, but invited the request to be able to talk back, which we could not easily provide! However we have thought about it, maybe even on an Eliza model.
Figure 77: Spades with its new speech bubbles
We had a lot to be pleased with. We had reached 142,000,000 downloads and the company was looking very strong! I guess after 15 years we by now were getting a little older. It will be a tough call to have the same team still working as hard in another 15 years time!
Figure 78: The annual AI Factory Xmas party with the 142m downloads Android cake.
This year again saw much focus on making Spades stronger, but we also diverted to create a new Backgammon engine. This was a welcome diversion, even though I am not keen on the game! However Spades sucked us back, so the Backgammon project is not complete. As ever simply maintaining the ad networks, keeping up with updated SDKs and dealing with problems has been the overwhelming theme. We have a lot of products and these require a lot of maintenance.
Figure 79: Backgammon is about to make a big jump in performance
Looking back we have come a long way and have been very successful. This has been hard work, but our success owes also to our organisation and good engineering practices. You have to adapt as things change, which is of course much easier for a very small company. As our Japanese company partner indicated, "you need to keep re-inventing yourself to survive". There were a few moments when we might have been sunk, but we weren't. We are grateful for our good fortune!
Another of our team had their first daughter and this adds further to our collective distraction!
Our years have finally fallen into a pattern with GDC SF, Develop Brighton, Droidcon being the shows we always attend. Added to these are visits to the IGGI academic events, designed to marry academia with the games industry. Also are some forays into other academic opportunities, including this year providing a short lecture at Queen Mary UOL on AI Factory and then appearing on the post lectures panel. Our audience was the IGGI group, who we continue to support and be involved with.
Figure 80: the panel at QMUL
GDPR took a big slice out of our 2018. This had been known about for a long time, but the deadline was approached with a crescendo as people struggled to implement it. Companies found that they had to suspend their services (e.g. PInterest), while they discovered that maybe they had not fulfilled the GDPR requirements which threatened multi-million euro fines.
For us we had to implement the needed GDPR dialog boxes inside the app and also manage our newsletter subscription list. The rules are all embracing and are not really designed for many of the areas that the rules apply. GDPR is there to protect from abuse, but at the same time impacts so many benevolent uses of user data. Even my local doctor felt he needed my permission to tell me when my appointment was!
GDPR has been hard work, but we were ready by the deadline and will continue to make sure data is processed properly.
We continued to have issues with an endless flood of accusations that our Backgammon cheated. It is perhaps hard to imagine what people have on their minds, but some accusations came with death threats or threats of violence. This is a new age and people are sometimes too well connected. If you believe something odd and then find someone on-line who also believes it, your certainty multiplies. Once there are hundreds sharing that belief then, like lemmings, the certainty becomes absolute certainty and it then become a mission to "take us down".
We had started at the very end of 2016 to investigate having the apps certified as "fair play". We needed to pay significant money to get a company to analyse our product and then certify (or not) what we already knew was anyway true! This has taken a long time to actually deliver what was needed, but the next release of Backgammon will, for the first time, have a professional body out there expressing their analysed view that, indeed, our app does not cheat!
After each attended event I toss my badge into a box, with some overlooked exceptions. Without this it would be hard to recall just how many events we had attended. It is seems this is at least 50 and maybe 60! The starting points were the ECTS shows, which were a little bleak and downbeat. There were not so many opportunities. As it progressed we attended more games-oriented shows, including E3, Casual Connect, Symbian, EGN, Casual games Seattle, Casual games Austin, GDC Europe, Droidcon and the ultimate GDC San Francisco. The emphasis in attending gradually morphed from pressure to make contacts to eventually almost going under cover. The later shows were more about keeping in tune with the zeitgeist than pursuing business. On the conference side I am a regular at the older Nemog, IGGI and also AIIDE conferences. All these provided good networking and are generally inspiring. I always come out of these with many notes for what we should be considering.
Figure 81: So many trade shows and conferences!!
At some point we will hang up our conference boots!
A big thank you to all the companies we have worked with and the hundreds of millions of players who have supported us, provided feedback and played our games!
We are not done yet, so watch this space!
Jeff Rollason - September 2018