Last week, I had the opportunity to serve on the frontlines with Team Rubicon to support their Midwest flood operations. Team Rubicon, a disaster relief organization comprised mostly of veterans and first-responders, is one nonprofit that Microsoft’s Tech for Social Impact team partners with to support communities in need around the world. My experience reinforced my conviction in the social business model we’re building here at Microsoft to serve nonprofits. This model is not principally about top line revenue or profit optimization, it’s about building a scalable and sustainable way to move nonprofit missions forward through the power of technology – reinvesting any incremental profits back into philanthropy and the community at large. Here’s why I believe in this model:

The site of our work was Pacific Junction, a small community south east of Omaha, Nebraska, just across the Iowa border. Pacific Junction is one of the communities that fell victim to record-setting flooding that recently devastated the Midwest. Flood water surged throughout the town, reaching the roofs of many single-story homes and bringing damaging water currents and mud that destroyed and defaced the homesteads throughout the town. Many residents have been unable to reach their homes for weeks, allowing mold to set in, making homes utterly uninhabitable. While some had flood insurance, many did not. For many, their homes represented a lifetime of hard work and savings now lost in a blink of the eye. With a mission to rebuild communities and lives, Team Rubicon has already deployed over 312 volunteers in Operation Heartlander to provide flood response and recovery support.

We spent the first day in the field focused on assessing damage. On its face, damage assessment is a fairly mechanical process. First, assess the house for visual damage and potential dangers for the first responder team, and then enter the observations into a system to activate “strike teams” for help. However, I quickly learned that the assessment involves far more than creating a work order to activate strike teams: in many cases, it’s the point of first contact with residents who are in one of the hardest and most vulnerable moments of their life. In fact, one of the homeowners we helped was unable to contain their emotion when they learned that Team Rubicon would support them. The assessment process is about showing empathy and taking the time to hear the resident’s story and concerns. It’s about showing respect, as you, essentially a stranger, sludge through a person’s house and life which has been turned upside down. It’s about the deep human connection that is at the heart of Team Rubicon’s work, and so many of our humanitarian partners around the world.

On the second day, I had the opportunity to go out to the field with two strike teams of Team Rubicon volunteers. We went to a house that had its 1,200 square foot basement destroyed by water, mud, silt and debris. The situation looked overwhelming and desperate.

We started by bringing in sleds to haul mud, shovels to scrape, saws to break down debris, hammers and crow bars to peel off molding drywall and ceiling material. We then began clearing large debris – what Team Rubicon lovingly calls “mucking” – shoveling sled-load after sled-load of mud, and hauling it out of the house. Once clear, we began removing drywall and ceiling material to clear the house of mold. At each stage of work, the homeowner worked side-by-side with us, deeply thankful to have the support. After a solid eight hours, the mud was clear, mold removed, and the house was set to dry so that the rebuilding could begin.

I flew home thinking about the experience, and I felt the immense responsibility we have in the technology industry to deliver affordable solutions that work well and work every time.

Technology for many nonprofits is what undergirds and supports the work that happens in places like Pacific Junction. Behind the scenes and often invisible to the work on the ground, it’s the technology that my team is responsible for providing which helps organizations like Team Rubicon. Team Rubicon depends on technology to mobilize volunteers, plan missions, and route strike teams. Any glitches mean that the Team Rubicon volunteers are not able to fully support communities.

I feel energized about my experience with Team Rubicon and more committed than ever to build solutions that truly live up to the demanding environments that so many nonprofits operate in. At Microsoft, we are committed to learning how to better serve this sector each day and evolving our social business model to help move nonprofit missions forward.

I want to thank the Team Rubicon team and all of the first responder organizations working in the Midwest. Microsoft is proud to “step into the arena” with you and be a small part of your mission.

Ancient Egypt has always been a popular setting for games. It is hardly surprising, as with its distinctive art and lavish customs the Land of the Pharaohs is a rich source for game designers seeking inspiration. However, a quick look at the app store reveals that the most popular Egyptian-themed games devote themselves to matching tiles, playing slots or dressing-up princesses. Thankfully, Egypt: Old Kingdom takes a more scholarly approach. As an incarnation of the god Horus, your task is to work alongside the pharaohs in order to overcome the mighty Seth.

Seth is a bit of a pain and as the god of chaos, he is eager to unleash a catalogue of disasters upon the land. We begin our journey in Memphis, but this is Egypt, not Tennessee, so the job is to build pyramids rather than Graceland. However, it isn’t wise to attempt to run before we can walk like an Egyptian. The Old Kingdom was around for hundreds of years and before we can even think of building mysterious pyramidical buildings we will need to first establish our tribe.

Initially, Egypt: Old Kingdom seems rather complex and intimidating; it feels like a crash course in ancient Egyptology. However, settle into the game’s steady flow, and it soon becomes clear that the game isn’t actually that daunting at all. The tutorial introduces you to the bare basics and then leaves you to discover the rest as you play, but that’s OK because the range of available options never becomes too intimidating. It turns out to be a Civilization-style game that does away with a lot of the micromanagement aspects and instead focuses on the deployment of your workers.

At the beginning of the game, the map is shrouded in fog and you will want to send out workers to explore new areas. When a worker is sent to a new region their choice of actions will be limited by geographical constraints. Hills are great for constructing barracks, new homes and numerous other types of buildings. Fertile floodplains will yield a choice of extra crops. Some areas will already have resources that you can gather or packs of wild beasts that you can either hunt or worship.

Success depends on efficiently acquiring and managing supplies of the game’s six resources. Food enables you to feed and increase the size of your population; spend ten food and you will be able to place a new worker. The chief sources of food are cultivated fields and fish from regions near the Nile. Production points are mainly used for constructing new buildings; workshops will help you increase your production. Luxuries are usually acquired through trade; they keep your population happy and help pacify angry neighbours. The game’s abstract approach extends to military strength, which just like any other resource is represented by a single number. An effective way of improving your army is by building barracks. Culture points can be used to make new discoveries, with advancements following the usual technology tree approach. For instance, once you have established the local cults advancement, your people can then discover tomb building, which is a great way of improving favour with the gods. Favour points allow you to worship the various gods, each of whom will provide you with a time-limited bonus.

After a few turns, your people will stumble across other tribes. Now you will have the option to forge new friendships or make new enemies. Peaceful options include setting up a simple trade agreement and maybe greasing a few palms. Once relationships get really good you will be able to assimilate the people into your society. Aggressive options include subjugating a tribe in battle or launching a raid but remember that enemies have long memories and they can unite against you. Combat is very simple, just challenge a tribe and wait for five turns, then the army levels are compared. There are no differing units or tactics, but you can call upon the favours of some gods to enhance your combat abilities.

It is odd that the version of the game available depends on your device. On Android, you can download the game for free. This lite version gives you the opportunity to dip your toe into the Nile by playing through the first 50 turns. If you want to see more then you will need to pay to open up the rest of the game. On iOS the lite version seems to have been replaced by a full version that requires a one-off payment.

In the full game, the number of options available is very impressive. Games can be set up that follow the course of history, or you can create your own history in the appropriately named sandbox mode. You can add more micromanagement elements, reduce the influence of the gods in various ways and make things even tougher by limiting your options to save progress. Conspiracy theorists may like to try a game in which the human race is enslaved by aliens, whilst B-movie buffs can create a game in which evil mummies are invading the world. The later options sound like fun additions, but they do cheapen the authenticity of the game. Otherwise, you have to admire the amount of background research that the developers have incorporated. The end result is a richly thematic game that is also educational in an entertaining way. There are even optional quizzes that test your new-found knowledge of all things Egyptian.

Egypt: Old Kingdom has simple but still very thematic graphics. The easily identifiable icons ensure that the screen remains uncluttered whilst the neat animations show at a glance what each of your workers is up to. The full game lasts 300 turns, this seems like a lot, but as there isn’t that much micromanagement to worry about, you can often burn through turns at a rapid rate. Events drive the narrative forward; some of these will be small random incidents like an attack from a pack of hyenas. Others are based on specific historical happenings and the fallout of not dealing with these can be very harsh. Some may feel that the way that these scripted events push you in a certain direction make progress feel too linear. Others may find that the random events are too frustrating; an unexpected famine can really set your plans back. Sometimes these events can be mitigated, for instance, if you have the resources, you may be able to build damns before a flood hits and so avoid the loss of key buildings. Of course, you can always use the options to play a more open-ended game at the expense of historical flavour.

If you have even a passing interest in Egyptology then Egypt: Old Kingdom comes highly recommended. The streamlined civilisation building works well, although Civ veterans may find the range of control too limiting. The main choice appears to be between focusing on using military strength or diplomacy to bring the other tribes under Horus’s wing. With only six resources to worry about, it is easy to quickly assess how much you are producing and spending without the need for complicated menus. Furthermore, since the options in each region are limited by geographical constraints, the range of choices never becomes overwhelming. In fact, the exhaustive historical setting can make the game seem deeper and more complex than it actually is.

GDevelop, the open source 2d game engine I dubbed “the Ultimate Beginner Engine” just had another release, bringing it to version 5.0 beta 66.  This release brings several new features including new tweening capabilities, the ability to save your project to multiple projects to be more version control friendly and a new experimental video object.

Full details of the release from the release notes:

New features

• New behavior: Tween, to animate objects position/angle/properties (thanks @Wend1go!)
  
  • See “Pairs” starter game for an example of using tweens to animate objects.
  • Tweens are run using Shifty.js tween engine (thanks @jeremyckahn).
• Add support for saving a project as multiple files, ideal for team work and using version control systems (like git, mercurial, svn, etc…)
  
  • In the game properties, choose “Multiples files” and save the project.
  • Layouts, external events, external layouts and functions will be saved into different json files.
  • Make sure to make a backup of your game!.
  • Be sure not to erase any of the multiple files, or GDevelop will be unable to open again your project.
• New option: Extract Events to a Function, to automatically create a function from selected event(s).
  
  • Select an event, right click and choose Extract Events to a Function in the menu. Parameters will be automatically filled with objects, behaviors and groups.
  • Read more about it on the wiki.
• Experimental new object: Video (thanks @Bouh!)

Improvements

• Add variable and object thumbnail icons in the event sheet (thanks @blurymind!)
• Add tooltips in the scene editor, when hovering an instance (thanks @blurymind!)
• Autosave is now made for the project when a preview is launched (thanks @blurymind!)
  
  • If the editor crash, or the autosave is more recent than the file, GDevelop will ask if you want to open the autosave.
  • Autosave is created next to the original file, with a “.autosave” extension.
• Update rendering engine to Pixi.js v4.8.6
• Add checkboxes to filters by conditions/actions in the Events Search (thanks @Bouh!)
• Show object name in menu when pasting and show hint if pasting as global (thanks @blurymind!)
• Add setting to set the maximum framerate (FPS) of the game. Default is ~60fps.
• Show resource name when hovering thumbnail (thanks @blurymind!)
• Improve events function performance
• Add support for groups inside events functions.
• Updated translations.

Bug fixes

• Disable some menu items (disable event/adding subevent) if not applicable (thanks @blurymind!)
• Fix crash when choosing a folder for a new game
• Fix color picker in the scene properties (thanks @KinkGD!)
• Update link to Discord channel (thanks @Bouh!)
• Avoid crashes due to clipboard handling
• Fix crash when using the resource editor in the web-app

You can learn more and download GDevelop here.  It is an open source MIT licensed (core library, IDE is GPLv3) project hosted here on GitHub.

GameDev News 2D

China’s game approval process has undergone a lot of change in the past year or so, including a full-on freeze for most of last year, but more changes are set to hit the program this month including some that expand its reach to cover HTML5 and instant games.

Releasing a game in China requires it to be submitted to regulators and deemed to meet certain content and quality standards before being greenlit to go up for sale, meaning that these regulations are important to know for devs interested in launching a game in China’s sizable market.

Niko Partners has summarized the new and existing regulations China’s State Administration of Press and Publication plans to have fully implemented this month to oversee that process. Each, according to Niko Partners, aims to address issues related to game quality and content, risks of game addiction (especially in minors), and self-regulation for publishers.

Those include some plans that already were put into motion in December 2018 like establishing an ethics committee to evaluate the social values of online games and to restart the previously-frozen approval process that issues licenses for new titles.

Newer policies include an undisclosed limit on the number of games approved per calendar year (less than 5,000 for 2019, by Niko Partners’ estimate), increased research and implementation of anti-addiction systems, especially for mobile games, and rules that require HTML5 games and mini-games like WeChat titles to seek approval before releasing.

Other new goals of the approval process seek to introduce and encourage self-regulation within China-based game publishers to check content ahead of approval, something that would come from more transparent information on the approval process itself, and goals that aim to promote games that “promote traditional culture” and feature “correct information regarding history, politics, and law.”

The full Niko Partners writeup offers more context for each of these, as well as a list of more specific content guidelines (“there shall be no images of dead bodies or pools of blood in any games,” clearly note if a game is part of a series or risk it being denied due to title overlap) that developers might want to check out as well.

Here is the situation: You have created some sort of data model for representing objects in memory/on disk. Now you need the ability for objects to refer to other objects. I.e., an object needs to talk about another object. Some examples:

• A material object may point to a texture object and say “I want to use this as my diffuse map”.
• An animation object may point to a model object and say “I want to rotate this model around its z-axis”.

How can we accomplish this?

Here are two options:

• Names: Each object is referred to by its name. The name is a string assigned to the object by the user and the user can change this string at will (rename the object).

• GUIDs: Each object is referred to by a globally unique identifier (GUID). The GUID is assigned to the object on creation and never changes. It is guaranteed to only represent this particular object and no other.

Names are resolved in some kind of context (typically the children of the current object). Thus, to refer to an object that is “far away” from us we might have to use a sequence of names to navigate the object tree, e.g., ../../player/head/left_eye. Much like a path in a file system, this sequence of names provides a path from one object in our object tree to another. Note that in this post I will sometimes somewhat sloppily talk about the name of an object when I actually mean the full path to an object.

You might protest that there are other ways of representing references too. For example, an in-memory representation could just use a pointer. A disk representation could use a file offset. Combinations are possible too — for example (filename + offset) to represent an object inside a file. However, it is easy to become confused when considering the myriad of possibilities, so let’s put all of that aside for the moment. In this post, I’m going to focus on the difference between names and GUIDs and in the end we will see how the discussion applies to the other possibilities.

Side note: There is another interesting option apart from names and GUIDs and that is to refer to an object by the hash of its content. With this approach, the same content is always referred to by the same unique identifier (its hash) and if you change the content all the references have to be updated. If you start to think about it, most of git falls out as the result of this single design decision.

Names and GUIDs both have their pros and cons, making it hard to say that one is strictly better than the other:

Each of these points can be argued back-and-forth endlessly. Can’t we auto-assign names to make them easier to come up with? But how readable are names really if most of the things are just named box_723? Can’t we make a tool that looks up a readable name from a GUID? Can’t we also make a tool that automatically patches references when an object is renamed? Etc, etc, etc.

Again, it’s easy to get stuck in the nitty-gritty details of this and miss the bigger picture. To make things clearer, let’s take a step back and ask ourselves:

What is the fundamental difference between names and GUIDs?

Think about it for a bit. Here’s my answer:

A GUID specifies an object identity, but a name specifies an object’s role.

The GUID 90e2294e-9daf-45f0-b75b-01fb85bb6dc8 always refers to one specific object — the one single object in the universe with that GUID. The path head/left_eye refers to whatever object is currently acting as the character’s left eye. It does not always have to be the same object. Maybe the character loses her eye at some point and it gets replaced with a glass eye. Maybe we can spawn multiple instances of the character in different configurations with different kinds of eyes — flesh eyes, robot eyes, anime eyes, etc. Regardless of the setup, head/left_eye will refer to the character’s left eye.

In contrast, if we used a GUID to refer to the left eye and the eye got replaced, the GUID would still refer to the old eye we lost. And a single GUID couldn’t be used to refer to different eyes in different character setups.

The pointers and offsets that I talked about in the beginning of the post are similar to GUIDs, since they reference objects by identity. A pointer always points to the same object. In fact, you could see a pointer as a deserialized version of a GUID — a way of uniquely referencing an object in memory. Offsets too, uniquely identify objects. (But offsets are not permanent, so references must be updated each time a file is saved.)

A name allows for “late binding” of references.

To get from a name to an actual object, we need to resolve the name at some point. This involves matching the path against the object tree and finding the corresponding object. In contrast to a GUID, which always points to the same object, a name might resolve to different things at different points in time, or in different contexts. The reference isn’t bound to a particular target until the name is resolved.

When does this happen? You can decide that when you design a system based on your performance/flexibility requirements. For example, you can decide to resolve all references once and only once — when the object is spawned. This is faster, because you only need to look references up once, but it also means that in the case where the eye is removed and replaced, the reference won’t be updated to point to the new eye. So it’s less flexible.

The other option is to resolve the reference every single frame. This can handle objects being removed and/or replaced, but it also means having to pay the performance cost of resolving the reference every single frame.

With this new understanding of the fundamental difference between names and GUIDs we can take another look at the pros and cons we listed above and see if we can understand them better.

Names are fragile — they can break if objects are moved, renamed or deleted

Yes, this is the whole point!

The main reason for using names is to allow late binding. Late binding means we don’t know beforehand what the name will resolve to (or if it will resolve to anything at all). We can’t get the benefits of late binding without also getting the drawbacks.

For instance, in the example above, after the eye has been removed, but before it has been replaced with a glass eye, head/left_eye will not resolve to anything — because the character doesn’t have a left eye. Code that expects to find an object at head/left_eye might break.

A name might also resolve to something unexpected. For example, the eye might be removed and replaced by a little man. Code that was written to deal with an eye, or even with no eye, might break when it finds a little man in the eye socket.

In addition to breaking in this correct way — where a resolve rightly fails because the object doesn’t exist — references can also break in incorrect ways. The resolve might fail, not because there is no eye, but because the user made a mistake. For example, maybe the eye was named LeftEye instead of left_eye.

To an extent — problems like this can be mitigated by good tooling. For example, the tools might warn about unresolved references. The tools might also assist with renaming, so that if you rename left_eye → LeftEye all the references are updated to LeftEye too.

But note that there is an inherent conflict here. The whole point of using names is to allow the references to be more lax and flexible. If the tools are too anal with their warnings it kind of defeats that purpose. For example, it might be totally correct that head/halodoesn’t refer to anything, because the character starts out without a halo — she only gets that once she’s completed the Holy Mission. If a tool spews out false positive warnings about things like this, users will soon learn to ignore them and miss the actually valuable warnings about real typos.

Similarly, tools can’t be too aggressive about updating references when objects are renamed either. Suppose that you designed a really cool robotic left eye for the character. Then you decide that it would look better as the right eye, so you move it into the right eye socket and rename it from left_eye to right_eye. If the references are auto-patched, all references to the left eye will now be changed to the right eye, which probably isn’t correct. For example, if the left_eyebrow had a reference to its eye, and that reference was auto-patched, the left_eyebrow would now think it sits over the right_eye. On the other hand, some references could have meant “the robotic eye” rather than “the eye in the left socket” when they talked about left_eye and those references should get patched. Pretty messy and hard to make a nice UI for, although I’ve tried before.

Names are cumbersome — coming up with meaningful names for everything is a chore

As discussed above, a name isn’t just a string of characters, it is a description of a role, of a relationship. head/left_eye means the left eye object in the head of the character. If you gave it a nonsensical name like bob or an auto-generated name like Object_13 it wouldn’t say anything about the role.

To take advantage of the late binding feature of names you want to use meaningful names that match the concepts that you have in your game. I.e. if your characters can put on different helmets and backpacks you probably need helmet and backpacknames. If helmets and backpacks are just visual features of some character models, can’t be removed or swapped out and don’t have any gameplay purpose, they might not need their own names, they might just be part of the head and body.

You can think of this naming as sort of a “logical rigging” of the model.

So yes, if you want to take advantage of late binding, you do have to spend some time coming up with meaningful names and hierarchies. If all your objects are just named entity_2713 you are basically just using names as IDs. This has all the drawbacks of names (fragility, costly resolution) as well as all the drawbacks of IDs (unreadability). Don’t do that.

Names are expensive — they have to be resolved

Again, late resolve is the point of using names, and it will always have a cost. You can’t get the benefit of late resolve without paying the cost for it.

Of course, it can be more or less costly, depending on how you implement it. My most important performance tip is: be clear about the scope in which names are resolved.

I like to use fully qualified paths. I.e., referring to a character’s left eye would be head/left_eye. Referring to the left eye from the right eye would be ../left_eye. Here,.. goes up to the head and then left_eye descends to the right eye.

It can be tempting to fall into the trap of convenience and say that we should be able to just use the name left_eye to refer to the left eye instead of a full path, but it has scary performance implications. Instead of just searching our children for a name match, we now have to search all our descendants recursively. And if we want this to work from the right eye too, we not only have to search all our descendants, we have to search all our parent’s descendants too. Before you know it, you have to search the entire world for this left_eye. And even if we find it, how do we know it is the “right one” — the one the user meant? Maybe our helmet has a little statue on it, and maybe that statue has a left_eyetoo? How do we make sure we don’t find that one? Messy.

My preferred implementation for resolving paths is to first hash each part of the path (this can be done offline), and then at each step, we match the hash at that step against the hashed names of the current object’s children — either through a lookup table or directly. Maintaining a lookup table is probably only worth it once you start to have hundreds of children to match against.

Even though this avoids really expensive stuff like searching the entire object tree or doing string comparison, it is still a lot more expensive than just following a pointer (which an ID deserializes into).

Names vs GUIDs — The Smackdown

With this deepened understanding — who wins, names or GUIDs?

As discussed above, names have many disadvantages — they’re fragile, cumbersome and costly. But they have two main advantages:

• They express intent. When I refer to head/left_eye it is clear to the reader what I want to refer to. Thus names have a meaning that pointers/GUIDs don’t have. Recording this meaning can be helpful. When we complain that identifiers are unreadable, it is the lack of meaning we talk about — not just the fact that the identifier is a jumble of hex characters. But meaning requires explicit intent. If your object is named entity_23415 — there is no meaning in the name, it might just as well be called cc1b9a7b-a5bb-4355-8cf1-f78b74fe2774.

• They allow for “late binding” of the reference to an actual object. This allows new objects to “take the place”/”fill the role” of the originally referred object. Using this, we can “patch” objects in lots of interesting way. For example, we can take a character, replace its eye with something else and all references to the eye will still work. To do this with GUIDs we need to patch up all references too, so that they point to the “new eye”.

So which is best? It comes down to a judgment call.

My take is this — we’re trying to create a high-performance user-friendly game engine. Thus, we only want to pay the costs of using names (bad performance & fragility) in the cases where we really take advantage of their strengths (intent & late binding). In my experience — most of the times, we don’t need these features. For example, when you are placing a bunch of trees in a level you don’t really care about naming them and you don’t have any need for something else “assuming” the role of one of those trees.

For this reason, The Machinery uses GUIDs as the default way to represent references. When a model refers to a texture, it does so with a GUID. You can move or rename the texture and the model will still keep using the same texture until you explicitly point it to a different one.

But in addition to this, we also explicitly allow for name references in some systems — systems that we think benefit from the extra flexibility:

• Our visual scripting system has a “lookup entity by name” node, allowing entities to be referred to semantically (such as head/left_eye) from within the scripts.

• Our animation system is still under construction, but we plan to have a similar feature there, allowing animations to target loose and flexible things such as helmet/headlight/color.

Having two different “kinds” of references like this is in the engine by no means ideal. Whenever we are designing a system we have to ask ourselves: does this reference need the flexibility offered by names or is using a GUID OK? We are also possibly missing out on some flexibility — in the cases where we’ve decided to use a GUID, it is much more cumbersome for the user to achieve the kind of dynamic retargeting that names make easy.

Still, it seems like the best compromise to me — we get the performance and stability of GUIDs/pointers in the majority of the code, but can still use the flexibility of names in the situations where we think it’s needed.

See also

• Pixar’s USD format uses names for everything. From their viewpoint, having to occasionally fix broken references is worth the extra flexibility they get from using names everywhere. Of course, since they’re not primarily targeting real-time rendering, their performance requirements are different.

• I’ve written about this topic before, if you want to see how my viewpoint has shifted over the years. Note though that the focus of that article is a little bit different. In that article I’m talking about referencing assets/resources on disk, so when I mention a path in that article I mean a disk path. Whereas, in this post, I’m talking more about references in general and I’m not that concerned with exactly how things get serialized to disk.

There was a long journey from a tale about harrowing life of civilians in war – This War of Mine – to a game of society survival and city-builder in Frostpunk. Why am I mentioning the first game in a story about the latter? Because creating the first one was a great lesson for us, the team of designers, to learn how to build a heavy, emotional story filled with difficult decisions and ambiguous moral choices. This is what lies underneath in our strategic game that now is heading to Xbox One.

The Frostpunk: Console Edition story begins in late XIX century during the peak of the rapid industrial revolution of the times. For reasons not understood by scientists, Earth is getting colder and colder until governments have collapsed, organized communities are put to an end, and humankind faces the threat of extinction. You play as a leader of possibly the last society on the planet, trying to recreate a functioning civilization able to survive the unforgiving cold.

First thing you do is gather resources to start a heat generator (loads of coal are going to be needed!) and build a circular city around the huge heat-distributing machine. As people in Frostpunk often say, “Heat is life!” You’ll build streets, tents, houses, cooking houses, coal mines, steam-powered heaters, and lots of other facilities. You’re going to construct hunters’ huts and order workers to hunt down wild animals. The bigger your city grows, the more it will need to consume while sustaining the life of its inhabitants.

City-building is one of the first layers to discover and get you thrilled for the game. And then there’s me and the team of designers’ vision to be realized in Frostpunk – all that morally grey area when you make decisions unsure about consequences. The idea that you can actively rule the citizens by introducing laws and customs that would make them more efficient, better prepared or, ultimately, obedient to your orders. You shape the society accordingly to your will. You’ll learn the hard way if it’s right or wrong to force children to work. If you think that is wrong, what would be your decision when lacking hands to work while people are freezing to death and coal supply is insufficient? When Frostpunk’s story drags you in, you’ll be faced with such morally ambiguous choices.

We also knew that the game’s world had to be larger than the ice crater in which you build the city of New London, as we called it. We knew players would feel a need to seek for knowledge about what happened to the world. Large spaces of frostland have been designed, filled with places to explore and discover. And so, sooner or later, you’ll realize what you have in the city might not be enough to ensure survival. There will be a moment to leave the city and send scout teams to explore and investigate the frozen lands. There will be plenty of things to discover, perhaps other remnants of civilization, groups of survivors or deserted mines.

Now, creating a strategy game for consoles had us rethink how the game’s flow should work. Great efforts have been made to re-design interface and enhance gameplay flow to make all have natural and intuitive feel when played on a controller. We wanted to make sure that gamers not only received the same experience, but one adapted to consoles to make it work smoothly. I believe that had to be done (that’s why it took some time for our team) because the game has huge potential to keep you thrilled and immersed in its world. Follow the news here to learn more about Frostpunk: Console Edition!

At the beginning of 2019, the Humble Store started to offer digital codes for select Switch and 3DS titles. In March, it followed this up by adding a bunch of third-party Switch titles from publishers such as 2K and Curve Digital. The publishing side of Humble also said it would be adding more games soon from various other prominent companies.

The latest games now available on the store are from Sega, Capcom, Team17 and Headup Games. Unfortunately, this section of the website is still restricted to users within North America. As previously noted, the Humble Team is “looking into the future possibility of bringing in more countries”.

Here’s the full list of games now available on the Humble Store (thanks, Nintendo Everything):

SEGA

Puyo Puyo Tetris
SEGA Ages Alex Kidd in Miracle World
SEGA Ages Gain Ground
SEGA Ages Lightening Force: Quest for the Darkstar
SEGA Ages Phantasy Star
SEGA Ages Sonic the Hedgehog
SEGA Genesis Classics
Sonic Forces
Sonic Mania
Valkyria Chronicles
Valkyria Chronicles 4

Capcom

Capcom Beat ‘Em Up Bundle
Mega Man 11
Mega Man Legacy Collection
Mega Man Legacy Collection 2
Mega Man X Legacy Collection
Mega Man X Legacy Collection 2
Monster Hunter Generations Ultimate
Okami HD
Onimusha: Warlords
Street Fighter 30th Anniversary Collection
Ultra Street Fighter II: The Final Challengers

Team17

Mugsters
Overcooked 2
Overcooked Special Edition
Planet Alpha
Raging Justice
The Escapists 2
The Escapists: Complete Edition
The Room
Worms W.M.D
Yoku’s Island Express
Yooka-Laylee

Headup Games

Bridge Constructor Portal
Earth Atlantis
In Between
Runbow
Slime-san
Super Blackjack Battle 2 Turbo Edition
Super Treasure Arena
The Inner World: The Last Wind Monk
Tied Together
Toby: The Secret Mine

Do any of these games on the Humble Store interest you? Tell us down in the comments.