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.


Welcome to the Gold Rush

by matt v, May 8th, 2014

1849 is now available worldwide for PCs, Macs, and iOS and Android tablets!

For PCs and Macs, you can get the game at many of your favorite game stores. Visit the game’s site for a full list of stores where it is available.

Tablet versions are available from the AppStore and Google Play.

And finally, a big thank you to our beta testers and early access players. Your feedback and help in development was invaluable!

1849 Early Access Update 3 – San Francisco and Sandboxes

by matt v, April 18th, 2014

We’ve released our third content update to 1849’s early access. If you have the early access version of the game, the main menu will let you know that updates are available.

Here’s what’s new in this version of the game:


  • Sandbox mode has arrived. You can build a city anywhere you’d like on the map that’s not in the Pacific Ocean. You’ll get a procedurally-generated map based on your location that is adjusted for terrain (mountains, plains, foothills, etc.), precipitation, resource availability, and starting lot size. Some quests will be thrown your way, but other than that, it’s up to you to build your dream California Gold Rush city.
  • Trees and rocks where there were not trees and rocks. We’ve added obstacles to most of the maps. They’ll require you to spend some resources to clear out of your way, but they’ll also provide you with bonus resources. And if your city is on the ocean or a bay, there’s a coastline now.
  • And welcome to the final 5 city scenarios. In addition to the previous 15, you can now build a northern nexus of trade in Colusa, exploit the richness of California’s agricultural bounty in Woodland, strike out into the far north in Oroville, dig for black gold in Mariposa and then show off all of your wealth by turning San Francisco into a city of manufacturing and mansions.
  • We’ve also made numerous interface changes and some edits to existing scenarios. You can read full release notes on our forum.

For the next few weeks, we’re getting 1849 all dressed up for it’s May 8 debut, so please continue to share your feedback and report any bugs either by sending them directly to me or by posting them in the beta section of our forum.

You can still join us in the early access beta if you haven’t!

Steam Greenlit 1849 Today!

by matt v, April 3rd, 2014

Thanks to all of you and your many votes, we made it through Greenlight today! We cannot thank you enough. We’re excited and humbled by making through so quickly!

We invite everyone to sign up for email updates. We’ll keep you updated as we finish up our early access beta and get 1849 ready for its Steam debut. You can also get the early access edition from that page and visit our player forums.

We said we could not thank all of you enough, so here’s one more: THANK YOU!

1849 Early Access Update 2 – The Mother Lode

by matt v, March 29th, 2014

We’ve released our second content update to 1849’s early access. If you have the early access version of the game, the main menu will let you know that updates are available. If you don’t have the early access version, it’s available at IndieGameStand.

Here’s what we’ve added:

  • Five new scenarios: You can head into the deep woods in Ukiah, gather supplies for a new expedition in Benicia, dig  into the Mother Lode in Sonora, create a steam ship network in Martinez and indulge in Sonoma wines in Santa Rosa.
  • Hear the sounds of the Gold Rush. Now you can hear the clang of the hammers, the thud of the ax and din of your towns with new sound effects.

You can visit the forum for a complete listing and the details of this release. Our next update will be out in a few weeks and you can expect more scenarios, an automated trade system, some new songs in the soundtrack and maybe a few more surprises.

We’re also on Steam Greenlight!
Please vote for us to be released on Steam:

1849 Early Access Update 1: The Way to San Jose

by matt v, March 6th, 2014

We’ve released our first content update to 1849’s early access. If you have the early access version of the game, the main menu will let you know that updates are available. If you don’t have the early access version, it’s available at IndieGameStand.

Here’s what we’ve added:

  • Five new scenarios: You can stock up on food and drink in San Jose, dig for gold with the jumping frogs of Calaveras County, head into the unknown northern Sierra Nevada in search of a new claim, embrace the good life by making fine wine in the Napa Valley, and join the otters searching for sardines in Monterey Bay.
  • Break out the headphones and turn up the speakers because we’ve added the first few tracks to 1849’s soundtrack! Just be warned – the tracks may get stuck in your head.
  • No more windowing. Full screen mode is now available.
  • Wandering peeps. You’ll now see a lot less of our friend the farmer. Houses now generate all types of NPCs and there’s a surprise new one in the game.
  • Trade UI updates. Many of you have asked for it, and now it’s here. When you open the trade menu, you’ll now be able to see the amount of inventory you’ve got in storage right there in the menu. No more clicking back and forth.

We’ve made some other changes here and there. And for the profoundly curious, you can check out the release notes on the forum. Now it’s back to work getting ready for our next update in three weeks. We’re planning on five more scenarios, sound effects and a maybe a few more surprise updates!

We’re also on Steam Greenlight!
Please vote for us to be released on Steam:

Early Access Available

by robert, February 19th, 2014

An Early Access version is now available for purchase at IndieGameStand. With Early Access, you’ll get access to the current version of the game and to continuous updates. We’ll be adding new scenarios, new content and refining gameplay in the coming months leading up to launch.

We’re also on Steam Greenlight! Please vote for us to be released on Steam:

Announcing 1849

by somasim, February 1st, 2014


Currently under development, 1849 is our first game: a city management simulation set in the California Gold Rush. It will be released for PCs, iPads, and Android tablets, in May 2014.

Visit the 1849 website for more details.

Pioneers! O Pioneers!

by robert, January 24th, 2014

A city bustling with activity:


All the pulses of the world,
Falling in, they beat for us, with the western movement beat;
Holding single or together, steady moving, to the front, all for us, Pioneers! O pioneers!
- Walt Whitman

Screenshot Saturday: Advisors!

by matt v, January 11th, 2014

This week’s screenshots show off our advisor system. The game simulation gets pretty complex: you grow your gold mining towns, while balancing the budget, keeping workers happy, and managing your stores and businesses. But it’s pretty difficult to keep it all in your head all at the same time.

So our advisors are one solution to this: they summarize the current state of simulation, and give you the most important feedback, plus some hints about what to do. Makes dealing with unhappy citizens much less frustrating.

On to screenshots:


Financial advisor tells us whether we’re in the red or in the black, and how the budget is trending


Population advisor summarizes what people want the most, and what they’re complaining about. Also gives you info on workplaces and unemployment (which causes crime when left unchecked)


Also, a nice screenshot of a filled-in town

Check out our Screenshot Saturday on this week’s Reddit (and some other cool games, too!).

Screenshot Bonanza

by robert, December 23rd, 2013

Well, what do you know? We got top votes in last weekend’s Reddit Screenshot Saturday! :)   Check it out here: Screenshot Saturday 150 – (7 + 11 + 13 + 17 + 19 + 23 + 29 + 31)

And here are the most recent screenshots we posted – click through for full size versions. More will be coming soon! :)

UI to start trading with your neighbors

Map that shows who is around you

Once you've traded, a caravan shows up and drops off goods at the general store


A few miner details

by robert, December 6th, 2013

We have many resource conversion chains in the game (there are about 50 different resources). This chain is probably the hardest: iron ore smelted into iron bars, then a blacksmith makes them into pickaxes, which then get used to mine up more iron ore.

It’s tricky because it’s a feedback loop, it takes a lot of workers, and pickaxes are needed for all types of mining: gold, silver, and iron ore. Fortunately many towns make them, so it’s often possible to just buy them already made, at a premium.



Educating Future NPCs

by matt v, December 3rd, 2013

Every NPC hopes to be able to give their young NPCs a solid education. To help them out, we’ve created a school and hired a teacher NPC.

In 1849, you’ll need things like schools and churches to grow your houses into the higher levels.


Older Posts