I figured out how to get gifs of object rotations out of Blender + Photoshop today, yes!

Today I worked mostly on office equipment to start preparing for the office environments.

Over the past couple weeks I have been hashing out the details of The Founder's mechanics. Designing a simulation/strategy game has been a really challenging and fun process.

The Founder is still in development so these mechanics are tentative and haven't yet been thoroughly playtested - it remains to be seen whether or not they actually work in practice!

What makes a strategy game

Going in, I kept in mind these elements of a good strategy game:

• Limitations: A limited resource which can be used/applied in various ways. This
  resource can be time or moves/actions or a literal resource like gold.
• Zero-sum: the opting of one decision is always at the expense of alternatives. That is, there are tradeoffs in the ways you apply your resource.
• Commitment: commitment to a particular decision tree branch increases the cost of switching to a different branch
• Diversity: no one strategy which always wins.
• Balance: similar to diversity, every strategy should have a weakness.
• Engaging: provide a stream of simply resolvable yet strategically valuable and nuanced tasks/events/stimuli which are components of broader game goals (victory conditions).

These aren't hard and fast nor are they universal, but I've found these to be most common amongst strategy games that I've enjoyed.

The Founder does not have victory conditions - only survival conditions. There is nothing you can do to "win" the game in the traditional sense. You can only continue to not lose.

Keep it simple

Throughout this process I had to constantly fight an urge to create an accurate and detailed simulation rather than an enjoyable and accessible simulator. It's fun chasing down every detail and trying to figure out how to model it, but you end up with a Borgesian map of a game where you might as well do the real thing since the game is no different. Or a game that is so insanely technical that people need to devote considerable time and attention just to understanding the mechanics.

So things are necessarily simplified, abstracted, exaggerated for the sake of it being in engaging and not drudgery.

The mechanics

The core goals

The core goals here are not so much "goals" as in an end-game condition, but a delaying of an inevitable failure state. You're on borrowed time (and money). In more detail:

• Keep your investors happy. You are beholden to a group of investors who expect that your company always shows a good level of growth, so every year your revenue must increase by at least 10%. If these investors don't like your performance, you lose.
• Don't go bankrupt. If you end up having to pay more than you can afford in monthly costs (salaries, rent, etc), you lose.
• Don't die. You're mortal after all. After living out an average natural lifespan, you die (and you lose).

The core and supporting mechanics

The core mechanic is very simple: make money by making products. Other supporting mechanics are added to make things more interesting and provide more opportunity for strategic decision-making.

Products & infrastructure

Product development is fairly straightforward, but to introduce an interesting strategic element, products require "infrastructure". This includes datacenters, studios, labs, and factories. Certain kinds of products require certain infrastructure, which are easy to intuit - a social network or search engine requires datacenters, for example. A smartphone requires a factory. The idea here is that this infrastructure requirement forces the player to commit to a subset of the products they could possibly develop. If you invest in a lot of information infrastructure (datacenters), then it is at the sacrifice of other products (the zero-sum/commitment aspect I mention above), such as entertainment products (which require studios) or biotech products (which require labs) or hardware products (which require factories).

You are limited in how much infrastructure you can create (thus you cannot just buy a lot of every kind of infrastructure), but opening new offices in new locations increases that limit. Thus you have an incentive to expand.

If your company becomes large and wealthy enough, these infrastructure limits become less important, which is exactly what I want to happen - we see this when companies which start in one industry gradually begin expanding across many different ones.

Products & bonuses

Certain kinds of products enable certain bonuses. Some are simple like bonuses to employee productivity. But some are more complex and meant to express some of the impacts of technology when controlled by particular interests.

For example: the hiring mechanism for employees in the game is one based on information asymmetry. When you hire an employee, you get a fuzzy view of their stats (that is, you cannot see their exact skills, only numbers which may be slightly exaggerated/inflated). That is all the information you have on the employee. Using this information, you make an offer to the employee. The employee has a range they are willing to accept, but to keep your costs low, it is in your interest to try to guess the lowest salary they will take. If you guess incorrectly enough times, the worker accepts an offer elsewhere and becomes unavailable.

If your company develops a successful social network, the dynamics of this minigame change. Now during these hiring negotiations, you have access to more information. You get a more accurate view of their skills. You may be able to see what other offers they've received, thus giving insight into how others value them. You might be able to see how much debt they have and how desperate they are for some gainful employment. Control over that social network gives you significant leverage in the hiring process.

Workers

To make products you need employees, so you hire employees and pay them a salary. The amount of money you make for a product generally depends on the quality of that product, which is determined by how skilled your employees are.

Employees have their own sub-mechanics, manifested through their skill attributes which reflect in what ways they contribute to the company. To ensure high levels of productivity, you must keep them happy. And since this is the future we're talking about, there are a lot of different ways to do that ;)

Markets

The products you develop have different appeal to different markets. I'm still working out how these markets are divided, but currently they are distinguished by economic status (low/middle/high income) and geographic region. This creates an economic landscape for the company to expand across; some space to grow as your investors demand. Naturally, there are finite geographic regions and income brackets to expand to, so sustaining growth is hard. The population can expand, but there are ecological limits to what the planet can sustain. In the real world, this problem is skirted around by inventing new market categories, but I haven't figured out way to (or whether I should) express that in the game.

Events

There are is a huge slew of things that happen which are so diverse that a more generalized system is needed to capture them. That's what the event system is for. Your actions make certain events possible, more likely, or less likely, and they can affect your company in a variety of ways. These events are all inspired by real-world events, such as high-profile security breaches, wage-fixing scandals, protests, patent lawsuits, revolution and social upheaval, and so on. If you skimp out on security on a product, for example, security breaches are more likely. Events can, among other things, hurt or boost the public opinion of your company (see below), hurt or boost general market activity, hurt or boost employee productivity or happiness, and so on. By affecting these other intermediary mechanisms, events ultimately impact your ability to make money.

Competition

What's a free market without some competition? A variety of other AI companies try to wrestle market segments out from under you, poach your best employees, or otherwise assault your business. Or you can collude with them. Maybe employee salaries are getting way out of hand because of bidding wars between companies. Maybe you should all just agree to lay off each other's workers, hmm?

The Market

There are "markets" as I've mentioned earlier, but there is also "The Market", in its holy, abstract sense. It is a catch-all for any buying/selling. In other games it might be "the shop" or "the store" or something, where you can buy items or power-ups or upgrades. But just like the real Market, you can buy just about anything here: from perks to keep your employees productive and happy (like an employee shuttle or ping pong tables), to other companies, to government policies.

Public Relations

Managing public opinion is a key to success. People are more likely to buy from companies they feel like friends with. You need to convince the public that you are working for the progress of humanity, that you are laying a bright future for them, brick by brick. That it's in their best interest for you to have access to all their digital activity, or that the restrictions that your products operate with are necessary and benign. Public opinion is managed through a minigame, which I'll explain in another post.

Networking

One thing I really want to emphasize with The Founder is the politics of business. So a big engine of progress in the game is meeting with the right people and building rapport with them. These people can be journalists (provide you boosts in public opinion), investors (provide you with extra cash to burn), other businesses (provide you with opportunities for collusion), or government officials (provide you with favorable policies or grants). Networking is accomplished through a minigame, which I'll also explain in another post.

Verticals & product combos

The game starts out around the information revolution so naturally, your company starts as an information technology company. The products available for you to develop are, for instance, a search engine or a social network.

Over time you may find the options in IT limiting, so your company can expand into different verticals, such as biotech or entertainment, and develop new products under those umbrellas as well. If you're straddling multiple verticals, you can combine products from each as well. You could, for example, combine an entertainment virtual reality product with a social network (from the Information vertical) to develop something akin to Second Life or OZ from Summer Wars. Some product combinations are very successful, some are not and just result in vaporware.

Technology

New technologies can be researched through your company's Innovation Labs. Technology is what unlocks new products to develop and can provide other bonuses as well. This is where the game really takes off: eventually you research distant-future technologies (some which are actually being researched, some which are more fantastic and sampled from different sci-fi universes) like quantum computing, positronic brains, Alcubierre drives, in-vitro meat, telomere restoration, etc.

Money

Money is the main strategic resource and is the bedrock of almost any of the aforementioned mechanisms. Researching technologies, hiring employees, expanding into new locations or verticals, holding public relations events, networking, purchasing things on the market, and responding to events all cost money. So there are many ways to use it; it's up to the player to decide what the most profitable application is.

Balancing mechanisms

The game has to stay challenging and scale properly - as you progress, the failure states outlined by the core goals become harder to avoid (for example, it is difficult to sustain 10% growth every year) without introducing additional mechanisms solely to make things harder. While things get more difficult, if you play your cards right, you:

• have access to newer and fancier products by researching new technologies
• build products better and faster by employing skilled workers
• have favorable public opinion causing consumers to prefer your products over competitors'
• captured other regional markets by establishing locations in those areas
• networked with the right people to protect you in the media and in the government

Getting this balance right will be tricky.

The class I've been teaching this fall at the New School, News Automata, didn't require any previous programming experience, so I wanted to find a way to teach my students some basics. I had a plan where I'd get them setup and rolling with the basics and then transition into a journalism-related program involving some text processing libraries.

But when it came time to teach the class, almost the entire two hours were spent setting up the students' development environments. We were working in a school computer lab so students didn't have access to the permissions they might need to install packages and what not. I figured out a decent workaround, but even then, if you aren't already familiar with this stuff, environment configuration is super tedious and frustrating. It's often that way even if you are already familiar with this stuff.

Later, we tried again: this time students brought in their own computers. But of course, everyone had different systems - OSX, Windows, ChromeOS...and I realized that all the tools which make env setup easier (package managers and so on) require their own setup which just complicated things even further. And the packages I wanted to get the students using involved some lower-level libraries, such as numpy and scipy, required compiling which could take ages depending on what hardware the student had. By the time most of the students had their environment setup, everyone was exhausted and dispirited. What a mess.

So to make this all a bit easier, I put together a system which allows students to share a remote development environment. All I had to do was setup the environment once on my own server, and then students could submit code to it through a web interface. As long as the student had a browser, they could write their scripts. It was a huge, huge time saver - everyone could dive right into playing with some code.

I cleaned up the project and turned it into a package to reuse: Pasture. Now you can install it like you would any pypi package and build something on top of it.

I've included an example from the class I was teaching. I had students try their hand at writing some simple newsfeed filtering algorithms. Building on top of Pasture, students could submit a script which included a filtering function and see a newsfeed filtered in real(-ish) time:

Check out the GitHub repo for usage instructions and the full example.

I'm a big supporter of decentralized internet services but I used to use Evernote because it was really convenient. That's always the problem isn't it? Some things are just so convenient ¯\_(? ? ?)_/¯. A few months ago I began using Linux a lot more and when I discovered that there was neither a Linux Evernote client, nor were there any plans to release one. it seemed like a good opportunity to make the transition to another service.

But I didn't really like any of the other available services, and since most of them were still centralized, so I ended up making my own: Nomadic.

It doesn't pack nearly as many features as Evernote does, but that's ok because I think Evernote has too many features anyways. Nomadic can still do quite a lot:

• GitHub-flavored Markdown
• Some extra markdown features: highlighting, PDF embedding
• Syntax highlighting
• MathJax support
• Automatically updates image references if they are moved
• Full-text search (html, txt, markdown, and even PDFs)
• A rich-text editor - I use it for copying stuff from webpages, though it's not the best at that. It does, however, convert pasted web content into Markdown.
• A browsable site for your notes (Markdown notes are presented as HTML)
• A complete command line interface
• Notes can be exported as web presentations

For someone familiar with setting up web services, Nomadic is pretty easy to install. I'll refer you to the readme for instructions. For anyone else, it's kind of tricky. It would be great to make it non-dev friendly, and I might work on this later if people start asking for it.

Basically, all you do is manage a directory of notes, in Markdown or plaintext. The Nomadic daemon, nomadic-d, indexes new and changed notes, updates resource references if notes move, and runs a lightweight web server for you to browse and search through your notes. That's it.

If you want remote access, you can host Nomadic on a server of your own and put some authentication on it. Then you can SSH in to edit notes and what not. Down the line this kind of support would ideally be built into Nomadic and simplified for less technical users.

Alternatively, you can do what I do - use BitTorrent Sync, which is an application built on top of the BitTorrent protocol for decentralized "cloud" storage. So I sync my Nomadic notes folder across all my devices and can edit them locally on each. On my Android phone I use JotterPad to view and edit notes.

There are a bunch of tweaks and improvements that can be made, but I've been using it for the past four months or so and have felt no need to return to Evernote :)

In it's current state, Argos is an orchestra of many parts:

• argos - the core project
• argos.cloud - the infrastructure deployment/configuration/management system
• argos.corpora - a corpus builder for training and testing
• argos.cluster, now galaxy - the document clustering package
• argos.ios and argos.android - the mobile apps

It's an expansive project so there are a lot of random rabbit holes I could go down. But for now I'm just going to focus on the process of developing the clustering system. This is the system which groups articles into events and events into stories, allowing for automatically-generated story timelines. At this point it's probably where most of the development time has been spent.

Getting it wrong: a lesson in trying a lot

When I first started working on Argos, I didn't have much experience in natural language processing (NLP) - I still don't! But I have gained enough to work through some of Argos's main challenges. That has probably been one of the most rewarding parts of the process - at the start some of the NLP papers I read were incomprehensible; now I have a decent grasp on their concepts and how to implement them.

The initial clustering approach was hierarchical agglomerative clustering (HAC) - "agglomerative" because each item starts in its own cluster and are merged sequentially by similarity (the two most similar clusters are merged, then the next two similar clusters are merged, etc), and "hierarchical" because the end result is a hierarchy as opposed to explicit clusters.

Intuitively it seemed like a good approach - HAC is agnostic to how similarity is calculated, which left a lot of flexibility in deciding what metric to use (euclidean, cosine, etc) and what features to use (bag-of-words, extracted entities, a combination of the two, etc). The construction of a hierarchy meant that clustering articles into events and clustering events into stories could be accomplished simultaneously - all articles would just be clustered once, and the hierarchy would be snipped at two different levels: once to generate the event, and again at a higher level to generate the stories.

Except I completely botched the HAC implementation and didn't realize it for waaay too long. The cluster results sucked and I just thought the approach was inappropriate for this domain. To top it off, I hadn't realized that I could just cluster once, snip twice (as explained above), and I was separately clustering articles into events and events into stories. This slowed things down a ton, but it was already super slow and memory-intensive to begin with.

Meanwhile I focused on developing some of the other functionality, and there was plenty of that to do. I postponed working on the clustering algorithm and told myself I'd just hire an NLP expert to consult on a good approach (i.e. I may never get around to it).

A few months later I finally got around to revisiting the clustering module. I re-read the paper describing HAC and then it became stunningly obvious that my implementation was way off base. I had some time off with my brother and together we wrote a much faster and much simpler implementation in less than an hour.

But even with that small triumph, I realized that HAC had, in this form, a fatal flaw. It generates the hierarchy in one pass and has no way of updating that hierarchy. If a new article came along, I had no choice but to reconstruct the hierarchy from scratch. Imagine if you had a brick building and the only way you could add another brick was by blowing the whole thing up and relaying each brick again. Clustering would become intolerably slow.

I spent awhile researching incremental or online clustering approaches - those which were well-suited to incorporating new data as it became available. In retrospect I should have immediately begun researching this kind of algorithm, but 6 months prior I didn't know enough to consider it.

After some time I had collected a few approaches which seemed promising - including one which is HAC adapted for an incremental setting (IHAC). I ended up hiring a contractor (I'll call him Sol) who had been studying NLP algorithms to help with their implementation (I didn't want to risk another botch-implementation). Sol was fantastic and together we were able to try out most of the approaches.

IHAC was the most promising and is the one I ended up going with. It's basically HAC with a modifiable hierarchy. The hierarchy can take a new piece of data and minimally restructure itself to incorporate it.

I rewrote Sol's implementation (mainly to familiarize myself with it) and started evaluating it on a test data, trying to narrow down a set of parameters well-suited for news articles. It was pretty slow so I tried to parallelize it, but just a second process was enough to run into memory issues. After some profiling and rewriting of key memory bottlenecks, memory usage was reduced 75-95%! So now certain parts could be parallelized. But it still was quite slow, mainly because it was built using higher-level Python objects and methods.

I ended up rewriting the implementation again, this time moving as much as I could to numpy and scipy, very fast scientific computing Python libraries where a lot of the heavy lifting is done in C. Again, I saw huge improvements - the clustering went something like 12 to 20 times faster!

Of course, there were still some speedbumps along the way - bugs here and there, which in the numpy implementation were a bit harder to fix. But now I have a solid implementation which is fast, memory-efficient, persistent (using pytables), and takes full advantage of the algorithm's hierarchical properties (getting events and stories in just two snips).

For the past few days Argos has been in a trial period, humming on a server collecting and clustering articles, and so far it has been doing surprisingly well. The difference between the original implementation and this new one is night and day.

At first Argos was only running on world and politics news, but today I added in some science, tech, and business news sources to see how it will handle those.

It was a long and exhausting journey, but more than anything I'm happy to see that the clustering is working well and quickly!