Tokyo Towers Content Pack

by matt v, September 8th, 2017

The new Tokyo Towers content pack released on Steam and GOG on September 8!

With 10 new apartments, you’ll have many new choices as you seek to master the complicated, crowded (and expensive) world of Tokyo’s vibrant residential market. Ranging from smartly designed micro apartments to palatial penthouses, you’ll be able to design a quintessentially Tokyo residential block complete with matching exteriors and cityscapes inspired by Japan’s unique urban landscape.

Visit the Steam store page for more information about what else is available in the Tokyo Towers content pack!


C# performance tips for Unity, part 2: structs and enums

by robert, August 7th, 2015

This is part two of a previous post on C# performance tips for Unity. If you haven’t seen Part 1, check it out for more background and context!

In the last post, we looked at a number of surprises around memory allocation – such as heap trash being generated by foreach loops, array properties, or variadic functions. Throwaway objects on the heap can easily cause performance hiccups, so the less garbage we generate at runtime, the less we have to worry about memory pressure or garbage collection cost.

After the last post, several commenters on Gamasutra and on Reddit pointed out additional surprising memory allocations in Unity and Mono, when using structs or enums inside generic collections. I benchmarked them in a similar way as last time, and here are some of the interesting results.

In short, there are three more areas to watch out for, where we can observe unexpected garbage generation:

  1. lists of structs (including built-ins like Vector4)
  2. dictionaries keyed by structs
  3. dictionaries keyed by enums

We’ll talk about these in detail. But just to front-load the conclusions, here’s how to fix them:

  • Make sure your structs implement IEquatable<T>
  • Make sure your structs override Equals() and GetHashCode()
  • Add a custom comparer to dictionaries keyed by enums

Pretty simple, huh? More details await. But first, a word or two about autoboxing.

(more…)


C# memory and performance tips for Unity

by robert, April 30th, 2015

(This is Part 1 of the series. Also available: Part 2)

There’s a lot of useful information out there about memory and performance optimizations in Unity. I have myself relied heavily on Wendelin Reich’s posts and Andrew Fray’s list when getting started – they are excellent resources worth studying.

I’m hoping this post will add some a few more interesting details, collected from various sources as well as from my own optimization adventures, about ways to improve performance using this engine.

The following specifically concentrates on perf improvements on the coding side, such as looking at different code constructs and see how they perform in both speed and memory usage. (There is another set of perf improvements that are also useful, such as optimizing your assets, compressing textures, or sharing materials, but I won’t touch those here. Good idea for another post, though!)

First, let’s start with a quick recap about memory allocation and garbage collection.

(more…)


How to tune a simulation game

by robert, April 23rd, 2015

A while back I got asked a question about tuning simulation games. Another developer wanted to know: is there a better way than just tweaking and playtesting? They were working on a simulation title of their own, and dreading the cycle of tweaking numbers and playing and tweaking numbers some more, especially since the cycle wasn’t very fast – simulation tuning problems tend to only show up after a while of playing, and a turbo mode cheat only gets you so far.

This is something we dealt with recently, as we were balancing (and rebalancing) our game 1849, which is a gold rush era city builder / management tycoon game. So I figured I’d repost my answer here as well, in case it helps someone else in the future.

First, a bit of background: 1849 is all about managing the city’s economy. There are about 50 different buildings, and 20 different resources – and each building can produce raw resources (wheat field produces wheat, hunting camp produces leather and meat), convert them (brewery converts barley into beer, gold mine produces gold but consumes pickaxes in the process), or consume them (houses where people live consume all sorts of food and goods resources). On top of that, you have to pay workers’ wages at each resource building, so you want to make sure it’s not sitting idle, otherwise you lose money. Finally you get money by having houses buy resources and consume them (or by trading with neighboring cities). So most of the game is all about optimizing your resource chains and production logistics, and not producing too little or too much.

During the design phase, we mapped out all resource chains as a big graph, to make sure there were no surprises. I no longer have a photo of that anywhere, but it was exactly what you’d expect: a directed acyclic graph, where each node was a building, and each edge was a resource (eg. wheat edges going from wheat farm to the bakery and to the distillery). We did this to verify that we had a variety of chains from sources to sinks, some shorter and some longer, as well as at least one feedback loop (in our case, iron mine consumes pickaxes and produces iron ore, smelter converts that into iron, and blacksmith converts that into pickaxes, which get consumed again by all mines).

Once we settled on resources and buildings, we had to figure out our tuning values: how much wheat is produced per turn? or how much wheat do you need to make one unit of bread? If the values are too generous, the player accumulates a surplus and the game becomes too easy; if they’re too hard, you can fall into a “death spiral” where the player keeps running out of everything, and the workers move out, causing the economy to collapse.

The “brute force” approach would be to just make up some tuning values, and play the game a bunch of times and tweak. That can work sometimes but it’s slow, and we wanted to do it much faster. So we turned to the game designer’s best friend: Microsoft Excel. 🙂 (And I’m not joking about the “best friend” part.)

We built stationary models of a number of test cities – some for small cities, some for large ones, some with specific building combinations in them. By a stationary model, I mean: a model of how much of each resource is produced and consumed on a single turn.

First, there was a master sheet that listed all buildings and all of their tuning values (production and consumption levels, cost, population produced or required):
tuning1

Then there was one sheet per simulated city, which lists all the buildings and how many instances of each we expect to be built:
tuning2

Each city sheet would then pull tuning values from the master spreadsheet, and calculate all resource consumption and production, as well as how much money you’re making or losing, how many workers you need (and therefore whether you have enough houses) and so on. As long as all the numbers stayed around zero, the city was pretty well balanced. If they went too far into positive or negative, they would get highlighted in red or green on the spreadsheet, and it was a signal that this part might need extra attention.

This also made tuning almost instantaneous: if you changed a tuning value in the master spreadsheet, it would propagate intantly to all city spreadsheets, and you can see right away if this helped or harmed any of the test scenarios.

So that’s how we did tuning of all buildings and resources together in a single city. Then to set up difficulty progression between cities in a campaign, we did what a lot of tycoon games do: as the player goes through the game, increase sinks and resource consumption, which puts pressure on the player to produce more and more (while also giving them more money to work with). This was also verified with the tuning spreadsheets – we could tune the master sheet and immediately check how that’s affecting various cities in a campaign.

Also, there were additional details that turned into additional challenges, like adding one-shot timed quests for the player to complete, but those we usually tuned by brute force, since there were few of them and their effects were not as easy to model in our fairly simple spreadsheet.

Hope this is interesting – and maybe even useful!


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.

missinghouses
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

Dr._Strangelove
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:

"doWork":
 "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!


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:


Older Posts