Introducing Office Workers

by matt v, April 17th, 2015

We’d like to introduce some of the people that will populate the skyscrapers in Project Highrise.

Who are they?
Who is going to be occupying your building? What will they be doing? Those are two of the first questions that you, as the building architect, developer, and manager will have to answer in Project Highrise.

Residential towers are very different creatures from an office block. And a resort tower filled with hotel rooms is unlike either of those. If your challenge is to create a mixed use building, how will you balance the conflicting needs and desires of your two distinct population groups?

Your building will be full of people – there could be hundreds (we’re working on thousands) moving about your building, coming and going, eating and shopping, living and working. Each one of those people will have their own experiences. By and large your success as a developer and manager depends on making sure that those experiences are positive.

So, let’s meet a few of them.

If you’re creating a building to attract Class A office space, here’s your target audience:


They’re going to be coming to work every day in your tower. And office workers are creatures of habit and routine. Ensure that cafes are open in the morning, the food court has enough restaurants and that elevators and escalators are all running smoothly. Oh, and they hate waiting, too. If your cafes start to get crowded, you can be certain that you will hear about it from them.

They will also have different preferences for where they work. Some offices will want to be in high-traffic areas, near elevators or toward the ground floors. Others will want just the opposite – a quiet corner office far from the crowds and above all the traffic noise.

Will they all look like that?
Yes and no. The game will have every skin tone natural to the human race. And maybe some hair colors that aren’t. Clothing will also change color. There are male and female versions of every character in the game.

In addition to walking around the building, they’ll also have a bunch of other actions such as working at their desks or getting irritated when the line at their favorite sushi place is too long.

We’ll be introducing you to more building occupants as the months go by.

Minimum Sustainable Success? Know Your Context.

by robert, April 14th, 2015

I read Dan Cook’s recent gamedev sustainability polemic with anticipation and interest, but I couldn’t make heads and tails of it for a while. Yes, we need to be realistic about projecting revenues, I could not agree with that more! But then the details got murky.

The crux of Dan’s argument seemed to be that: 1. the chance of failure of any individual project is very high, so 2. we need to make tons of projects for a chance of a breakout success, and 3. don’t think a single success is worth very much because it has to pay for past and future failures as well. To explain this claim, he then does a neat walk-through of how many games they made at Spry Fox in the last 5 years (31 prototypes, 11 released projects), and how many actually made money (4 broke even, 3 were successes that paid for the failures).

Except this part made zero sense to me when I read it. Who can make 31 prototypes and release 11 games in 5 years? What time travel dark magic is this? :)  Because in my neck of the woods, it takes at least a year to make a game, and even that’s when you’re very disciplined about sticking to the schedule. Writing a game is a commitment closer to writing a book – and it takes just as much out of you.

Finally it dawned on me. That talk should have been titled differently: “Minimum Sustainable Mobile Success”. And then – then it makes much more sense. Make a ton of little games. Throw them at the wall and see what sticks. Don’t bet your farm on any single title because your success depends entirely on the roll of dice that is the app store featuring and the audience’s fickle response. And don’t make a premium title.

Except… this advice is not at all applicable to the PC market. You know what happens if you try to make a game in a few months and release it? Nothing. It won’t pass Greenlight, it won’t show up on Steam, it won’t get an audience. It might show up on, along with a ton of other minigames that people play for free, but that’s not a way to build revenue. The PC market is a very different beast, and it demands games that are larger, more fully developed, that have more meat on their bones. And players are willing to pay a premium price, if they get what they paid for.

So the tactics for indie survival in the PC world are going to be very different. You still run the risk of the game not doing well, but the shotgun approach is only going to backfire, because that’s not what the audience wants.

Instead, you have to start thinking less like a pop artist releasing singles on iTunes, and more like a book author committing a year or more of their life to a single piece of work. Instead of mitigating risk via quantity, mitigate risk via quality. Just start with the assumption that your game is not going to be a blockbuster – so what can you do to make sure it’s not an abject failure either, and gives you another swing at greater success next time? (And this metaphor is not ideal either, because success is not static, it changes as you acquire a reputation as a creator.) You have to find your fans, and in order to do that, understand who you’re writing for, and understand what is interesting about your game and why they should care. And just as importantly, figure out where your audience is, how to get your game in front of them, and also how many will (realistically) want to pay for it.

The point of all this is – if you’re not on mobile, making larger-scoped games, the shotgun approach is not viable. A portfolio of games is a great goal, but as an indie developer it will take you many years to get there. So don’t go wide. Work on minimizing the risk of failure of each particular title, and on building your portfolio over the long term.

As with everything in life, context is key.


Our Next Game – Project Highrise

by matt v, March 19th, 2015

What is it?

In Project Highrise, you build and manage a modern-day skyscraper – a vertical ecosystem of offices, businesses and residences.


A skyscraper is an intricate machine of interlocking systems, which depend on each other in their daily function. Tenants will expect everything to just work, and to have all of their needs met under one roof. It’s your job to keep this machine running smoothly and efficiently. Keep your ear to the ground, but your eye to the future.


When can I play?
Early 2016. We’re planning for an early access in late summer or early fall 2015.


More info?
Learn more about Project Highrise and sign up for our emails here:

Slides from Matt’s Talk at GDC 2015

by matt v, March 13th, 2015

Here’s a PDF of the talk that I gave at GDC 2015. The title of the talk was “How to Make and Self-Publish a Game in 12 Months“.

Quick Summary:
Making your first game as a new indie studio means that on top of actually making the game, you’ve got to do pretty much everything yourself. Self-fund, self-market, self-publish, self-incorporate, self-everything. This talk will chronicle that crucial first year as we made our first game and prepared if for a cross-platform PC and tablet release. There were some great moments and some harsh lessons in that year, with great advice from other game dev friends and mentors. This presentation will share everything that we learned.

Download/view the PDF here.

What we’re playing: Memoir ’44

by robert, January 4th, 2015

I’ve been playing a bit of Memoir ’44 lately. It’s a really well done WWII boardgame, with a light ruleset and short sessions. I’ve seen it compared to Advance Wars or Final Fantasy Tactics, which sounds pretty spot on, actually.

Like many war games, it takes place on a hex board that gets set up differently for each scenario, so you end up with a variety of terrain modifiers (forests, hills, towns) and units spread all over the map, depending on which battle of WWII is being reenacted. The game booklet comes with a number of good scenarios that have different setup and victory conditions, and even though they’re not symmetrical (because neither were the historical battles), you can just play each short game twice, once as axis and once as allied powers, and then use total points from both to determine the winner.

But from a game design point of view, probably the coolest part about this game is actually their treatment of randomness and uncertainty. Costikyan’s book first clued me in to this, and it’s very interesting.

Quick overview: as a commander you control a bunch of units of different types (infantry, tanks, artillery) with different abilities. But you can’t just activate any unit you want – you have cards in your hand that list various possibilities, for example, “activate up to 2 infantry on the left side of the board”, or “no more than 3 tanks at any position”, or “up to 3 units of any type that are damaged”. On each turn, you play one of those cards (and pick up a new one), activate those units, and move and/or attack. Then attacks are done by rolling from one to four dice to determine the result.

So the first source of randomness is the tactical attack die roll, and that’s very easy to understand – the probabilities of a successful attack are easy to calculate, and terrain modifiers just reduce the number of dice you get to roll. It’s a pretty straightforward stationary source of randomness.

But the more interesting source of randomness are the command cards in your hand. The game is cleverly constrained – you can’t activate units unless you have a card for them, so if your base on the left side of the board is being attacked and you only have infantry units there, you better have a card that matches this situation (eg. “activate up to 2 infantry on the left side”), otherwise you’re toast. And of course the cards then become a strategic resource – do I play my left flank card now, or hold it until later for some purpose?

And since card decks are a non-stationary random process, that can also be gamed – you could in theory learn to count cards, to give yourself an edge. I say “in theory”, though, because each session is short enough, and the card deck large enough, that this is unlikely to matter much.

So this combination of two sources of randomness, one of which limits what you can do, and the other determines the outcome of what you did, gives the game a very nice flavor – I’m no longer an omnipotent commander that can move all units at will, instead I have to pick and choose between only a few options at a time, sometimes good but sometimes all unpalatable, and worry about not closing off my future trajectory by doing something unnecessary right now. Kind of like the real world, come to think of it.


1849: Nevada Silver is Now Available

by matt v, September 16th, 2014


Today marks the release of 1849’s first expansion pack. So grab your pickaxe and mosey on over to the Comstock Lode where new fortune awaits in 1849: Nevada Silver.


Here’s some of what’s new in Nevada:

  1. Six new cities/scenarios! They should be pretty challenging – especially the last three once you’ve picked up the basics in the first couple of cities.
  2. There are trains! Now you’ll have to work with trains and their schedules for the delivery of crucial raw materials. The trading system in Nevada is completely redone and you can have some trades repeat as long as you have the cash or resources on hand when the train arrives.
  3. New resources and buildings have been added. Some of the buildings will require you to commit resources to their construction before you can use them. And this being Nevada, there’s a casino.
  4. The last two levels have landmark buildings to construct – the Virginia & Truckee Railroad in Virginia City and the Nevada State Capitol in Carson City.
  5. And a few other surprises await you in the Comstock Lode of Nevada…

Visit the 1849: Nevada Silver webpage to read more about the expansion pack and to find out where you can buy it.

Welcome to Nevada

by matt v, August 13th, 2014

Since 1849 launched back in May, we’ve been working on a few things and one of them is a pretty big expansion for 1849. So today we’d like to introduce everyone to 1849: Nevada Silver.

1849: Nevada Silver will be set during the Comstock Lode, the great silver rush that swept over Nevada after the California Gold Rush. During the Comstock, mining in the Old West went industrial. Gone are prospectors with pans in wild rivers, replaced by teams of men working deep underground extracting tons and tons of ore to be refined into silver and gold.


As you can see in that there screenshot, some new things are in store for Nevada. There’s the iron horse – we’ve added trains and an entirely new trading system. And six new scenarios introduce new resources and buildings.

A few other surprises await in Nevada. We’ll have more details on its release and a call for some beta-testing help in a couple of weeks.

Secret Project mailing list is live.

by robert, August 7th, 2014

We’ve been a bit quiet on the blog. For one, we’re working on some new content for 1849, and we’ll be releasing more details pretty soon.

Second, we’ve just started on a prototype of game #2, tentatively named “Secret Project”. How about that for an original codename. :)

Here’s a little bit of very early concept art: a piece of hand-drawn illustration that we use to explore a context and an aesthetic.




But what’s going on here? Who are those people, and why are they standing at what looks like the lobby of the Seagram Building, by the renowned modernist architect Mies van der Rohe?

Sign up for our Secret Project mailing list and we’ll send you more updates as we continue development!


How we learned to stop worrying and love early access

by matt v, July 1st, 2014

To Kickstart or not to Kickstart.
We should definitely do a Kickstarter for the game. We need to. We have to.
(Two days pass….)
I think I’m on the fence about Kickstarter. Do we really want to make that many t-shirts? But, then, money.
(Two hours pass….)
You’re right. I don’t want to make t-shirts. Screw it. I hear that [developer friend] just spent like a grand on shipping bonuses. No way!
(Two more days…)
Did you see how much [nameless indie game developer] just made on Kickstarter in the first two days? And how many people they got onto their lists? Let’s make a list at lunch for reward gifts.

This went on for several months.

As we made 1849, our new studio’s first title, THIS was the thing that caused us the most disagreement. Not game loop. Not art style. Not font choices. Not gameplay. Not genre choice. Even the logo was easier. And the process of making a logo – any logo – is just awful. It was that issue, to kickstart or not, that proved to be the main casus belli in our nascent gamedev eden.

We were brand new – we were the studio that had brought you absolutely nothing you could play. We had no previous content or community to funnel players to our new game, we weren’t on Steam, we had no content for YouTubers, we had no previous games or a popular or media presence. So we craved attention. We wanted people to know about us, we wanted to get press coverage, but most importantly, we wanted people to play our game. And for a time, we thought Kickstarter was the best way to gain this.

But what did we really want?

We took some time to ask ourselves what we would like to get from a campaign on a Kickstarter (or something else like it). At the end of it, when all was said and done and the last sticker was in the mail, what would make us say “well, that was totally worth it”? Given where we were in our development – both of the game and of the studio – I think these were the main things that we were seeking as the results of a crowdfunding campaign:

1. Playerz. We had been bothering our friends and anyone we ran into that seemed remotely interested in what we were doing. “You like games? Here, try ours!” (gets out laptop). But we wanted players that didn’t know us, had never had even a single beer with us, and whose only interest was playing a game that they liked. But we also wanted players that would understand that our game at that point was still buggy, mistuned and incomplete.

2. Beta-stage feedback. The type of feedback we were looking for also played a big part in our decision process. When we were making this decision, we had a game that was nearly feature-complete. The features that weren’t in the game were things that we just had not had time to get in the game yet.

Where have you all gone?

So we weren’t looking for feedback on core design or art direction. We we looking for implementation feedback, like: “Wow, scenario nine is really badly tuned” or “Goodness is scenario three sooo boring”. And more technical things, like “I have a Samsung Tab 3 and your game doesn’t work on it” and “Where have all the sprites gone on my MacBook?” We wanted very beta-like feedback. We had been looking at the game for months and months and desperately needed new eyeballs on our game.

3. Community. We were looking for players, but not just for this one game. Our vision was and remains to create a studio committed to making simulation games. Our hope is that people that like this particular game and our ideas for simulation games would stick around to see what we make and will spread the word.

What was keeping us from doing it right then and there?

But obviously there were things that were keeping us from taking the great crowdsourcing plunge straight away. Otherwise we would have done it and this article would have absolutely no dramatic tension to keep readers engaged to this point. So, what were the things that fed our doubt and stoked debate?

1. Type of engagement. People fund a game on a crowdsourcing platform for lots of reasons. They want the finished game upon release. They want a t-shirt. They want their name in your credits. They want to name a character something really, really silly that you’ll have to live with forever and ever even though you hate it and can’t believe that anyone in the Gold Rush was ever named PinkfaceMcGoo but hey they gave you $100, so there it is…

That’s a convoluted way of saying that we weren’t certain we could equate crowdsourcing participants with beta players. And we wanted players to kick, poke and prod at our game. Many players on crowdsourcing sites feel that by giving you $20, they’ve contributed enough to your game’s development. Would Kickstarter supporters be willing and able to answer questions like: Did the store/trade window make sense? How did this set of scenarios play? Do you get what that button is supposed to do? How about this button or this one – which is better? We needed users to test our user interfaces and players to test our gameplay. Would Kickstarter backer = beta tester?

2. We were sort of done. When we started to consider crowdfunding, we were already significantly along in our development process. It seemed to us that a big allure for many crowdfunding donors is the ability to see how the game dev sausage gets created and that’s at least part of what many are paying for – a greater degree of input into how the game is going to be made. We were at a point where we would have to add items into the game that would be just there for the sake of accommodating backers. For example, we were thinking that one of the items would be that you could name our advisors. But what does a named advisor add or contribute to the gameplay? Nothing, really. The things we came up with for backers all seemed to lie at some point along a spectrum with “very little added” on one end and “nothing, really” on the opposite.

It seemed that going the crowdfunding route would deliver some funding, but would also add considerable work – maintaining the pages, crafting updates, getting rewards together, interfacing with players once we were done to get things in and a few other things. For a small team of two full-time devs, that all started to sound like things that would get in the way of making the game rather than help make the game better. Ultimately, if it wasn’t going to make the game better, why would we do it? And that leads directly into what I’ve named…

3. The Molyneux Factor. We also thought a little about the big Kickstarter and crowdsourcing successes in the past couple of years – those led by Tim Schafer and Peter Molyneux and the like. They did (understatement approaching) alright, I guess. But they also sank pretty significant resources into those campaigns. I mean, Double Fine (brilliantly) turned making an adventure game into a sort of adventure game. In order to do this Kickstarter thing right, to get the most out of it, would we have to stop being game devs and start being game evangelists? We were a small team of two full time devs trying to make a bigger game – something that was going to launch simultaneously on multiple platforms. And we wanted to do it in about a year. We simply couldn’t afford – in terms of both time and money – to take work hours needed to promote and drive a Kickstarter like that. Nor did we have the name recognition and history of many of those crowdfunding successes. There were some big unanswered questions nagging at us: Could we afford the time it would take to do a Kickstarter right? What impact would that have on the final game? Would it smash our finely honed timeline spreadsheets into unrecognizable, unsalvageable bits?

That said…

But that doesn’t mean we don’t like money. Crowdsourcing had and has one undeniable draw, the honey that makes us climb up their great trunks and stick our noses into their hives of humming users – sweet, sweet funding. Money. Cash. Dinero. That’s what kept us returning to the idea. While we were mostly bootstrapping our game, it sure would be nice to have some money coming in. Contractors always seem to want to be paid no matter how nice they are.

So there were were, mired in a swamp of hesitation, alternating in a decision polarity with “Kickstarter” at one end and “not Kickstarter” at the other. It seemed that it was really a choice to do one thing (crowdfunding) or not do anything at all – we couldn’t see a compelling thing to put on the other end of the decision other than “not Kickstarter.” For some reason, we just couldn’t see another way to do it. Until we did.

The swamp of hesitation…

Or, I guess we should say until we talked to Emily. We were looking for someone to help us do some media outreach and PR for the game and Emily Morganti came highly recommended from several unconnected people. So we reached out to her. At this point, we were back on the “We’re mostly likely doing a KS” side again. We mentioned it to Emily and her reply was essentially “why on earth would you do that? Why don’t you just put it up for early access and let people play the game?”

And that’s when the light came on and we were able to replace “not Kickstarter” with something we could DO – and something that we could do that would go along with our plans and needs and wouldn’t destroy our timeline. We stripped away the shiny, high-gloss allure of crowdfunding and asked ourselves what, as a new studio, we hoped would be the end result of a campaign, we decided that we could probably get there by releasing an early access beta of our game for sale.

So, what were we looking to get?

Most of the in-game assets were done. The tutorial was essentially in place. The UI was still very much a work in progress. The campaign mode scenarios were not quite halfway done and the open sandbox mode was still just an item on our to-do list. So basically, our hope was that during our early access, we could get players to bang on the game and answer some of those questions. We also hoped that players would find things that we had missed or could no longer see. Again, fresh eyes from fresh players were very much desired.

We were also looking to attract a community of players that enjoy the kind of game that we were making. We knew we were making a very niche title that would appeal primarily to a certain type of player, so we were hoping to get their attention.

So what did we actually do?

It may seem strange to call a marketing strategy “slightly poetic”, but I’m about to do that.

In retrospect, there is something slightly poetic (see?) about what we ended up doing. For our first game, we were making a title heavily inspired by games of yesteryear – old-school, classic city management like what Sierra published in the 90s. It turned out that we also employed a slightly old-school strategy for marketing the game as well – we worked with Emily and created a media plan with timed releases around set milestones.

The first of those is really the one that interests us in this context. We decided to put the game on sale as an “early access” beta on Indie Game Stand, along with a press release that announced our early access starting on February 19, and a web forum where players could give us feedback.

Simultaneously, we set up a Steam Greenlight campaign, which was going to go live at the same time as our “early access” on IGS. Our hope was that the two would cross-pollinate each other – traffic from Steam would send people to IGS to buy the early access if they were sufficiently intrigued by our Greenlight posting, and vice versa, that a player who bought our game on IGS would go vote for it on Steam.

As a new team, we didn’t have direct access to early access on Steam and looking back, I think we’re glad that we went with a smaller outlet than Steam for our early access. On Steam, we probably would have received a significantly greater quantity of feedback and quite possibly less sophisticated feedback. A player that seeks out a smaller outlet for games like Indie Game Stand is more likely to tolerate the constant gardening that comes with an early access offering. Indie Game Stand, for us, turned out to be that third bed, in between Steam and Kickstarter – the one that was just right for what we needed.

After the early access launch, we released regular updates to the game with new content and changes that reflected player feedback. We did regular announcements to people that bought the game in IGS, on our studio website and through our Greenlight listing. We kept those up right until the week before our release.

Some lessons

So, want to give this a go? Here are a few things that we learned and thought were important.

1. Treat early access launch like the real launch. I can’t overstate this one enough. Set dates, and set realistic dates that you can meet. You only get one chance to launch your game and you only get one chance to get attention on your early access. Make sure that everything is ready to go for when you hit “send” on those press releases and emails to journalists. Include download keys in emails to journalists and YouTubers. While this is too early to expect reviews, make sure you’re ready and able to show your game to everyone.

Also, time it well. You wouldn’t release a game the week of E3 unless you’ve got the cash to market it. Or during PAX. Or another time when the game press is likely to be otherwise occupied. Don’t start your early access the third day of GDC. But if you’re going to be at PAX or GDC during your early access, talk about it. Show it off. Again, treat this release like the “real” launch and a live title.

2. Be up front with what’s not done yet. We didn’t have music or sound effects in the game until about halfway through our early access. A number of people commented about how there was no music or FX as if it were an oversight on our part. Just tell people somewhere about the big pieces are that aren’t done. Players and press are a lot more forgiving if they know something is coming. Even if it seems obvious to you (like “of course there will be music”), let people know anyway. I’m just picking on music, but there were other items in our game like that. By addressing what’s on your list and not done yet, you’re far more likely to get people talking about what’s in front of them and reacting to things that ARE in the game.

3. Make a plan for updates during early access. Be sure to parcel out pieces that you want feedback on into more digestible chunks. Our game has 20 game scenarios and I wanted feedback on every single one of them, but if I were to release all 20 right away, I could not be certain that they were all feeling the same level of beta love. By dividing them out, you can make a point of saying “we added five new scenarios”. Players are then much more likely to focus on the new. Also, you as a designer or programmer can focus on the same thing that your players are looking at. It’s actually a lot of fun to be working along with your players like this.

4. Have a release date and try your hardest to stick to it. While there are a lot of people that will happily play a beta version, most people don’t want to see your stinky, buggy game and will be waiting for the final version. Many of your beta players will also be rallying for their Steam key or other final version of the game. We viewed early access as a sort of contract and we tried our hardest to deliver.

5. Talk to people. This goes back a little to what I said about telling people about your game, at conferences, meetups, and anywhere they will listen. But beyond that, make sure that you’re always responding to feedback. You WANT feedback. You WANT their attention. Make sure that you leave time to do that. It’s just as important as arranging UI bits and designing levels. Maybe even more so during the early access.

6. Release all the Krakens. Making a lot of things available at the same time – early access, greenlight, web forum, blog, twitter, press releases, etc. – really helped get attention focused onto our game. If you include links to everything everywhere, it matters much less how someone gets to you. If they land on your Greenlight page, they’ll easily be able to vote for your game, then go to your early access page and then hit your blog and add follow you on twitter without any effort. No matter how they find you initially, they’ll easily be able to interact with your game in all the ways that you’d like.

7. Try to make feedback painless. This is something that we’re still working on – but I don’t think it’s just our team. If more dev teams decide to go this route, I think we need to get our heads together to try to come up with a better way to facilitate a conversation between devs and players – especially around this kind of early access. Forums are clunky. Public comments are mostly worthless. Direct email is OK, but many people are hesitant to do that. So I think this is a lesson incomplete and crossed up with a call to discussion and hopefully action not just for us but for others. It’s something we’ll be looking very closely at as we contemplate our next game.

How we learned to stop worrying and love early access

I’m not going to say that we’ll never ever ever put a project on a crowdfunding site, but we’re currently planning our second game. While we were planning and building our first game, we had many discussions about Kickstarter and when/if/how we would do it. Now we’re glad we did early access instead.
We’re pretty deep into the planning stages of our second game and we’ve got no plans to use that platform or anything like it. But we’re definitely going to do an early access of some type and we’re already thinking about  how to improve on what we did for 1849. The only question for us at this point is how early in the process that will be for game two.

Simulation Engine Part 3: Performance

by robert, May 16th, 2014

It’s been a while since the last installment of this series (see part 1 and part 2). We got a little busy with actually shipping the game. :) But now that that’s done, I have some time to conclude the simulation overview as well.

In previous parts, we talked about how the production rules system is set up, and what kinds of rules and resource conversions it operates on. But how well does it perform?

Very well, it turns out. Our production system is very efficient – in a town with many hundreds of entities, the rule engine’s CPU consumption is barely noticeable in the profiler, even when running on rather underpowered tablets.

Most of the processing power is spent, predictably, on checking conditions. One of the design goals for this system was to make sure conditions can be checked in constant or near-constant time, to help with performance. We have three optimizations in place to help with this: flexible frequency of rule execution, a drastically simplified language for conditions and actions, and an efficient world model that makes querying really computationally cheap.

Condition Checking

Production systems vary in how often the rules should be run. For example, we may want to run rules all the time on each frame, or maybe on a set frequency like 1Hz, or for a turn-based game, on every turn.

Our game’s economy is specified in terms of game clock days, eg. a farm produces wheat every 7 days. So it was sufficient to run most rules once per day, or even less frequently – and we made frequency tunable as needed on a per-rule basis.

Finally, there’s a very simple scheduler that keeps track of which rules are supposed to run when, so that they don’t get accessed until their prescribed time. This is a very simple optimization, but saves a lot of unnecessary work.

Resource Manipulation Language

Resource conditions and updates in our system look like this:

 "inputs": [ "map 5 gold" ],
 "outputs": [ "unit 5 gold" ]

This means each unit only has access to three types of resource bins: “map”, “unit”, or “player”, and it can’t make generic queries like in some other production systems. Here “map” and “unit” are like contextually-bound variables: “unit” refers to the entity that’s currently executing this rule, “map” refers to all tiles underneath the unit, and “player” refers to the entity representing player’s city inventory.

This is a form of deictic representation. Just like in English, the words “this” and “that” have different references depending on context, so in our query system, there are variables like “map”, “unit”, and “player” that are already bound based on context. Game units typically only care about themselves and their immediate surroundings, so that fits very well.

This representation is constrained, but also eliminates a huge and expensive search problem.

(Short introduction to deictic representation is in the Pengi paper by Agre and Chapman – although in that paper it’s cumbersomely called an “indexical-functional” representation. The term “deictic” replaces it later in Agre’s book “Computation and Human Experience”.)

Data Model

Most conditions are resource queries, and most actions are resource modifications. For example: check if there’s gold underground, and if so, consume it and produce gold in my inventory; check if there are workers working here, and if there is gold in my inventory, and if so, move gold over to player’s inventory, and so on.

As we described before, we store resources in resource bins, and those bins are attached to units, map tiles, and the player’s data object. Since there are currently 64 resource types, each resource bin is then implemented as an array of 64 double-precision floats, indexed by resource. In other words: querying and modifying resources in a bin is a constant-time operation.

So a resource query such as “unit gold > 5″ works as follows: first we get a reference to the unit’s own resource bin (via a simple switch statement), then look up resource value (an array lookup), and finally do the appropriate comparison against the right hand side value (another simple switch statement). All this adds up to a constant-time operation.

A query such as “map gold > 5″ is marginally more expensive, because it means “add up gold stored in all tiles under the unit, and check if > 5″. Fortunately, units are not arbitrarily large – the largest one is 2×2 map tiles, which means we execute at most 4 tile lookups, making it still a constant-time operation.

In conclusion

This sums up the performance side of our production system. Adding some specific limitations, and especially by restricting our query language, gave us really good efficiency – which we needed in order to run on underpowered devices such as tablets.


Older Posts