.NET Core 3.0 Preview 7 is now available and it includes a bunch of new updates to ASP.NET Core and Blazor.

Here’s the list of what’s new in this preview:

• Latest Visual Studio preview includes .NET Core 3.0 as the default runtime
• Top level ASP.NET Core templates in Visual Studio
• Simplified web templates
• Attribute splatting for components
• Data binding support for TypeConverters and generics
• Clarified which directive attributes expect HTML vs C#
• EventCounters
• HTTPS in gRPC templates
• gRPC Client Improvements
• gRPC Metapackage
• CLI tool for managing gRPC code generation

Please see the release notes for additional details and known issues.

Get started

To get started with ASP.NET Core in .NET Core 3.0 Preview 7 install the .NET Core 3.0 Preview 7 SDK

If you’re on Windows using Visual Studio, install the latest preview of Visual Studio 2019.

Note: .NET Core 3.0 Preview 7 requires Visual Studio 2019 16.3 Preview 1, which is being released later this week.

To install the latest client-side Blazor templates also run the following command:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview7.19365.7

Installing the Blazor Visual Studio extension is no longer required and it can be uninstalled if you’ve installed a previous version. Installing the Blazor WebAssembly templates from the command-line is now all you need to do to get them to show up in Visual Studio.

Upgrade an existing project

To upgrade an existing an ASP.NET Core app to .NET Core 3.0 Preview 7, follow the migrations steps in the ASP.NET Core docs.

Please also see the full list of breaking changes in ASP.NET Core 3.0.

To upgrade an existing ASP.NET Core 3.0 Preview 6 project to Preview 7:

• Update Microsoft.AspNetCore.* package references to 3.0.0-preview7.19365.7.

That’s it! You should be ready to go.

Latest Visual Studio preview includes .NET Core 3.0 as the default runtime

The latest preview update for Visual Studio (16.3) includes .NET Core 3.0 as the default .NET Core runtime version. This means that if you install the latest preview of Visual Studio then you already have .NET Core 3.0. New project by default will target .NET Core 3.0

Top level ASP.NET Core templates in Visual Studio

The ASP.NET Core templates now show up as top level templates in Visual Studio in the “Create a new project” dialog.

This means you can now search for the various ASP.NET Core templates and filter by project type (web, service, library, etc.) to find the one you want to use.

Simplified web templates

We’ve taken some steps to further simplify the web app templates to reduce the amount of code that is frequently just removed.

Specifically:

• The cookie consent UI is no longer included in the web app templates by default.
• Scripts and related static assets are now referenced as local files instead of using CDNs based on the current environment.

We will provide samples and documentation for adding these features to new apps as needed.

Attribute splatting for components

Components can now capture and render additional attributes in addition to the component’s declared parameters. Additional attributes can be captured in a dictionary and then “splatted” onto an element as part of the component’s rendering using the new @attributes Razor directive. This feature is especially valuable when defining a component that produces a markup element that supports a variety of customizations. For instance if you were defining a component that produces an <input> element, it would be tedious to define all of the attributes <input> supports like maxlength or placeholder as component parameters.

Accepting arbitrary parameters

To define a component that accepts arbitrary attributes define a component parameter using the [Parameter] attribute with the CaptureUnmatchedAttributes property set to true. The type of the parameter must be assignable from Dictionary<string, object>. This means that IEnumerable<KeyValuePair<string, object>> or IReadOnlyDictionary<string, object> are also options.

@code { [Parameter(CaptureUnmatchedAttributes = true)] Dictionary<string, object> Attributes { get; set; }

}

The CaptureUnmatchedAttributes property on [Parameter] allows that parameter to match all attributes that do not match any other parameter. A component can only define a single parameter with CaptureUnmatchedAttributes.

Using @attributes to render arbitrary attributes

A component can pass arbitrary attributes to another component or markup element using the @attributes directive attribute. The @attributes directive allows you to specify a collection of attributes to pass to a markup element or component. This is valuable because the set of key-value-pairs specified as attributes can come from a .NET collection and do not need to be specified in the source code of the component.

<input class="form-field" @attributes="Attributes" type="text" /> @code { [Parameter(CaptureUnmatchedAttributes = true)] Dictionary<string, object> Attributes { get; set; }

}

Using the @attributes directive the contents of the Attribute property get “splatted” onto the input element. If this results in duplicate attributes, then evaluation of attributes occurs from left to right. In the above example if Attributes also contained a value for class it would supersede class="form-field". If Attributes contained a value for type then that would be superseded by type="text".

Data binding support for TypeConverters and generics

Blazor now supports data binding to types that have a string TypeConverter. Many built-in framework types, like Guid and TimeSpan have a string TypeConverter, or you can define custom types with a string TypeConverter yourself. These types now work seamlessly with data binding:

<input @bind="guid" /> <p>@guid</p> @code { Guid guid;

}

Data binding also now works great with generics. In generic components you can now bind to types specified using generic type parameters.

@typeparam T <input @bind="value" /> <p>@value</p> @code { T value;

}

Clarified which directive attributes expect HTML vs C

In Preview 6 we introduced directive attributes as a common syntax for Razor compiler related features like specifying event handlers (@onclick) and data binding (@bind). In this update we’ve cleaned up which of the built-in directive attributes expect C# and HTML. Specifically, event handlers now expect C# values so a leading @ character is no longer required when specifying the event handler value:

@* Before *@

<button @onclick="@OnClick">Click me</button> @* After *@

<button @onclick="OnClick">Click me</button>

EventCounters

In place of Windows perf counters, .NET Core introduced a new way of emitting metrics via EventCounters. In preview7, we now emit EventCounters ASP.NET Core. You can use the dotnet counters global tool to view the metrics we emit.

Install the latest preview of dotnet counters by running the following command:

dotnet tool install --global dotnet-counters --version 3.0.0-preview7.19365.2

Hosting

The Hosting EventSourceProvider (Microsoft.AspNetCore.Hosting) now emits the following request counters:

• requests-per-second
• total-requests
• current-requests
• failed-requests

SignalR

In addition to hosting, SignalR (Microsoft.AspNetCore.Http.Connections) also emits the following connection counters:

• connections-started
• connections-stopped
• connections-timed-out
• connections-duration

To view all the counters emitted by ASP.NET Core, you can start dotnet counters and specify the desired provider. The example below shows the output when subscribing to events emitted by the Microsoft.AspNetCore.Hosting and System.Runtime providers.

dotnet counters monitor -p <PID> Microsoft.AspNetCore.Hosting System.Runtime

New Package ID for SignalR’s JavaScript Client in NPM

The Azure SignalR Service made it easier for non-.NET developers to make use of SignalR’s real-time capabilities. A frequent question we would get from potential customers who wanted to enable their applications with SignalR via the Azure SignalR Service was “does it only work with ASP.NET?” The former identity of the ASP.NET Core SignalR – which included the @aspnet organization on NPM, only further confused new SignalR users.

To mitigate this confusion, beginning with 3.0.0-preview7, the SignalR JavaScript client will change from being @aspnet/signalr to @microsoft/signalr. To react to this change, you will need to change your references in package.json files, require statements, and ECMAScript import statements. If you’re interested in providing feedback on this move or to learn the thought process the team went through to make the change, read and/or contribute to this GitHub issue where the team engaged in an open discussion with the community.

New Customizable SignalR Hub Method Authorization

With Preview 7, SignalR now provides a custom resource to authorization handlers when a hub method requires authorization. The resource is an instance of HubInvocationContext. The HubInvocationContext includes the HubCallerContext, the name of the hub method being invoked, and the arguments to the hub method.

Consider the example of a chat room allowing multiple organization sign-in via Azure Active Directory. Anyone with a Microsoft account can sign in to chat, but only members of the owning organization should be able to ban users or view users’ chat histories. Furthermore, we might want to restrict certain functionality from certain users. Using the updated features in Preview 7, this is entirely possible. Note how the DomainRestrictedRequirement serves as a custom IAuthorizationRequirement. Now that the HubInvocationContext resource parameter is being passed in, the internal logic can inspect the context in which the Hub is being called and make decisions on allowing the user to execute individual Hub methods.

public class DomainRestrictedRequirement : AuthorizationHandler<DomainRestrictedRequirement, HubInvocationContext>, IAuthorizationRequirement

{ protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, DomainRestrictedRequirement requirement, HubInvocationContext resource) { if (IsUserAllowedToDoThis(resource.HubMethodName, context.User.Identity.Name) && context.User != null && context.User.Identity != null && context.User.Identity.Name.EndsWith("@jabbr.net", StringComparison.OrdinalIgnoreCase)) { context.Succeed(requirement); } return Task.CompletedTask; } private bool IsUserAllowedToDoThis(string hubMethodName, string currentUsername) { return !(currentUsername.Equals("bob42@jabbr.net", StringComparison.OrdinalIgnoreCase) && hubMethodName.Equals("banUser", StringComparison.OrdinalIgnoreCase)); }

}

Now, individual Hub methods can be decorated with the name of the policy the code will need to check at run-time. As clients attempt to call individual Hub methods, the DomainRestrictedRequirement handler will run and control access to the methods. Based on the way the DomainRestrictedRequirement controls access, all logged-in users should be able to call the SendMessage method, only users who’ve logged in with a @jabbr.net email address will be able to view users’ histories, and – with the exception of bob42@jabbr.net – will be able to ban users from the chat room.

[Authorize]

public class ChatHub : Hub

{ public void SendMessage(string message) { } [Authorize("DomainRestricted")] public void BanUser(string username) { } [Authorize("DomainRestricted")] public void ViewUserHistory(string username) { }

}

Creating the DomainRestricted policy is as simple as wiring it up using the authorization middleware. In Startup.cs, add the new policy, providing the custom DomainRestrictedRequirement requirement as a parameter.

services .AddAuthorization(options => { options.AddPolicy("DomainRestricted", policy => { policy.Requirements.Add(new DomainRestrictedRequirement()); }); });

It must be noted that in this example, the DomainRestrictedRequirement class is not only a IAuthorizationRequirement but also it’s own AuthorizationHandler for that requirement. It is fine to split these into separate classes to separate concerns. Yet, in this way, there’s no need to inject the AuthorizationHandler during Startup, since the requirement and the handler are the same thing, there’s no need to inject the handler separately.

HTTPS in gRPC templates

The gRPC templates have been now been updated to use HTTPS by default. At development time, we continue the same certificate generated by the dotnet dev-certs tool and during production, you will still need to supply your own certificate.

gRPC Client Improvements

The managed gRPC client (Grpc.Net.Client) has been updated to target .NET Standard 2.1 and no longer depends on types present only in .NET Core 3.0. This potentially gives us the ability to run on other platforms in the future.

gRPC Metapackage

In 3.0.0-preview7, we’ve introduced a new package Grpc.AspNetCore that transitively references all other runtime and tooling dependencies required for building gRPC projects. Reasoning about a single package version for the metapackage should make it easier for developers to deal with as opposed multiple dependencies that version independently.

CLI tool for managing gRPC code generation

The new dotnet-grpc global tool makes it easier to manage protobuf files and their code generation settings. The global tool manages adding and removing protobuf files as well adding the required package references required to build and run gRPC applications.

Install the latest preview of dotnet-grpc by running the following command:

dotnet tool install --global dotnet-grpc --version 0.1.22-pre2

As an example, you can run following commands to generate a protobuf file and add it to your project for code generation. If you attempt this on a non-web project, we will default to generating a client and add the required package dependencies.

dotnet new proto -o .\Protos\mailbox.proto

dotnet grpc add-file .\Protos\mailbox.proto

Give feedback

We hope you enjoy the new features in this preview release of ASP.NET Core and Blazor! Please let us know what you think by filing issues on GitHub.

Thanks for trying out ASP.NET Core and Blazor!

There is no canonical version of Robin Hood. The earliest printed tales we have date from the 15th century, but it was an oral tradition much earlier. And it seems he wasn’t always the jolly socialist we know and love. These first stories feature many well-known names, but a violent Robin who is more interested in regaining his lands than giving to the poor.

So it’s fitting that the best part of Nocked! True Tales of Robin Hood, a text and strategy hybrid game about his adventures in Sherwood forest, is how you can shape Robin as you like. Even the gender and love interests of this Robin are yours to make your own. Beyond that, you can fashion Robin’s morality from classic outlaw to a far crueller thief.

You can make Robin a wronged nobleman or a champion of the peasantry. They can be a practical champion or one who dabbles in monsters and mysticism.

Choosing to add supernatural elements to this much-loved fairy-tale is a controversial choice. And it’s something any player has to buy into full-heartedly because it’s everywhere. On the whole, it works, adding a lot of extra choices and colour to the classic stories, as well as allowing the occasional mood change. An early encounter with a ghostly knight on a hill was a welcome touch of horror amid the pageantry. But as the story moves on, it becomes too frequent, becoming everyday and pedestrian when it should be mystical and exciting.

As far as the core characters of the legends go, though, they’re all here and bought to life in vivid colour. Some, like Marian, you’ll meet close to the beginning. Others don’t turn up until you’ve got a good way into the story. The drip-feed helps build the anticipation for big entrances. Bumping into well-known names, like Little John, wielding his staff atop a river crossing, feel like punch-the-air moments.

Of course, none of this would work without some quality writing, and here Nocked! delivers in droves. Descriptions make a great job of setting the scene and drawing characters, who advance in complexity alongside the story. Fantastic art and music help draw you deep into Sherwood. Yet for all that, it’s well-edited and restrained as a good gamebook should be. You’re never too far from making important decisions instead of getting bogged down in reams of text.

Indeed, the writing is so good it does a great job of supporting those decisions. Often, text adventures like this are complete crapshoots where there’s almost nothing to go on other than blind instinct. Nocked!, by contrast, telegraphs potential consequences with great skill, dropping hints to use when choosing your path. You can shape Robin however you like, but when the chips are down it can pay to re-read the passages before a decision.

Some rudimentary strategy elements add depth to your text-based decisions. Early on this consists entirely of resource management. Later you’ll be able to use those resources to make more long term decisions as you build a base of operations deep in Sherwood forest. Some decision options, often the more desirable choices, come with a resource cost which is clearly marked in-game. Where it gets more interesting though is in resource allocation at pivotal moments.

Say you’re in a battle against a group of fearsome bandits. Nocked! neither leaves it all to text or numbers but a mixture of the two. You’ll get to direct the major characters in the scene and allocate your pool of Merry Men to attack, defence or other operations. These choices can have major consequences for how the story plays out.

Yet they actually feel less strategic than making text decisions. The numbers are clear and visible whenever you need them. But the outcome of spending or allocating them to different options doesn’t carry the same sense of hidden hints. This creates an odd contrast, where the subjective decisions feel weightier than what should be objective ones. Nocked! uses numbers creatively, adding timers for tension on top of stats and resources. But while they add colour, they don’t offer any extra sense of control.

Nocked! True Tales of Robin Hood is not a short game, but the many faces you can give to Robin give it plenty of replay value. A bigger question is how many players will want to. This is no Six Ages, with a seamless blend of story and tactics. Rather it’s a top-quality gamebook which throws a few numbers around to add a vague sense of strategy. Fans of the former genre will lap it up; fans of the latter should approach with a bit more caution.

Nocked! was originally released on iOS in 2017, but it made the jump over to Steam last week.

Click Here!

Bigben and developer KT Racing have released a brand new video to show off WRC 8‘s redesigned career mode and we’ve lovingly shared it for you above. ‘Cause we’re nice like that.

A press release supporting the trailer states that the career mode “is traditionally the most popular and most played”, and after discussions with the community, the dev team has aimed to offer gameplay that matches fans’ expectations.

It allows players to become a driver for a WRC team for the first time, having you progress from season to season to compete in the WRC category and ultimately become world champion. It is said that players must excel in the following three major areas:

– Planning the calendar to decide which events to do in between rallies: training, manufacturer challenges, rest, classic events, etc.
– Managing a whole crew comprising six different and interconnected job roles. Players must consider each of their unique characteristics and use them strategically in each rally.
– Upgrading the crew through R&D and a skill tree, which evolves depending on player choices. Every decision has an impact on progression and on the morale of the crew (performance, reliability, etc.).

The game is still scheduled to launch on Nintendo Switch in September this year, bringing new off-road physics for all surfaces, extreme and dynamic weather conditions, 52 teams, 14 countries, over 100 special stages, weekly challenges, and an eSports mode.

Liking the look of this one? Why not drift your way into our comment section and let us know your thoughts?

The Puget Sound region has been home to Microsoft for more than 30 years. As the company has grown, the area has changed. New industries have brought more jobs, fresh opportunities and greater prosperity. 

But new housing has not kept up with job growth, and the Greater Seattle area has become the sixth most expensive place to live in the United States.  

That means many of the workers who make a community function – such as nurses, police officers, teachers and firefighters – can no longer afford to live in the cities or suburbs where they work. 

The problem is particularly acute in the suburban cities around Seattle. Low- and middle-income workers often face long commutes.

[Subscribe to Microsoft on the Issues for more on the topics that matter most.]

Microsoft is committed to helping kick-start solutions to this crisis, and is  investing $500 million to advance affordable housing solutions. Microsoft is also advocating for changes in public policy at city and state levels to address the long-term factors affecting housing affordability.

This commitment is about more than housing. It is about the people who make our communities places we all want to live in.

For more on Microsoft’s initiatives in the Puget Sound region follow @MSFTIssues on Twitter.  

With .NET Core 3.0 Preview 6, we added authentication & authorization support to server-side Blazor apps. It only takes a matter of seconds to wire up an app to Azure Active Directory with support for single or multiple organizations. Once the project is created, it contains all the configuration elements in its appsettings.json to function. This is great, but in a team environment – or in a distributed topology – configuration files lead to all sorts of problems. In this post, we’ll take a look at how we can extract those configuration values out of JSON files and into an Azure App Configuration instance, where they can be used by other teammates or apps.

Setting up Multi-org Authentication

In the .NET Core 3.0 Preview 6 blog post we explored how to use the Individual User Accounts option in the authentication dialog to set up a Blazor app with ASP.NET Identity, so we won’t go into too much detail. Essentially, you click the Change link during project creation.

In this example I’ll be using an Azure Active Directory application to allow anyone with a Microsoft account to log into the app, so I’ll select Work or School Accounts and then select Cloud – Multiple Organizations in the Change Authentication dialog.

Once the project is created, my AzureAD configuration node contains the 3 key pieces of information my app’s code will need to authenticate against Azure Active Directory; my tenant URL, the client ID for the AAD app Visual Studio created for me during the project’s creation, and the callback URI so users can get back to my app once they’ve authenticated.

Whilst this is conveniently placed here in my appsettings.json file, it’d be more convenient if I didn’t need any local configuration files. Having a centralized configuration-management solution would be easier to manage, as well as give me the ability to keep my config out of source control, should there come a point when things like connection strings need to be shared amongst developers.

Azure App Configuration

Azure App Configuration is a cloud-based solution for managing all of your configuration values. Once I have an Azure App Configuration instance set up in my subscription, adding the configuration settings is simple. By default, they’re hidden from view, but I can click Show Values or select an individual setting for editing or viewing.

Convenient .NET Core IConfiguration Integration

The Azure App Configuration team has shipped a NuGet package containing extensions to ASP.NET and .NET Core that enable developers the ability of using the service, but without needing to change all your code that already makes use of IConfiguration. To start with, install the Microsoft.Extensions.Configuration.AzureAppConfiguration NuGet package.

You’ll need to copy the connection string from the Azure Portal to enable connectivity between your app and Azure App Configuration.

Once that value has been copied, you can use it with either dotnet user-secrets to configure your app, or using a debug-time environment variable. Though it seems like we’ve created yet one more configuration value to track, think about it this way: this is the only value you’ll have to set using an environment variable; all your other configuration can be set via Azure App Configuration in the portal.

Using the Azure App Configuration Provider for .NET Core

Once the NuGet package is installed, the code to instruct my .NET Core code to use Azure App Configuration whenever it reads any configuration values from IConfiguration is simple. In Program.cs I’ll call the ConfigureAppConfiguration middleware method, then use the AddAzureAppConfiguration extension method to get the connection string from my ASPNETCORE_AzureAppConfigConnectionString environment variable. If the environment variable isn’t set, the call will noop and the other configuration providers will do the work.

This is great, because I won’t even need to change existing – or in this case, template-generated code – I just tell my app to use Azure App Configuration and I’m off to the races. The full update to Program.cs is shown below.

// using Microsoft.Extensions.Configuration.AzureAppConfiguration; public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureAppConfiguration((hostingContext, config) => { config.AddAzureAppConfiguration(options => { var azureAppConfigConnectionString = hostingContext.Configuration["AzureAppConfigConnectionString"]; options.Connect(azureAppConfigConnectionString); }); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); });

When I run the app, it first reaches out to Azure App Configuration to get all the settings it needs to run and then works as if it were configured locally using appsettings.json. As long as my teammates or other services needing these values have the connection string to the Azure App Configuration instance holding the settings for the app, they’re good.

Now, I can remove the configuration values entirely from the appsettings.json file. If I want to control the logging behavior using Azure App Configuration, I could move these left-over settings out, too. Even though I’ll be using Azure App Configuration as, the other providers are still there.

Dynamic Re-loading

Log levels are a good example of how the Azure App Configuration service can enable dynamic reloading of configuration settings you might need to tweak frequently. By moving my logging configuration into Azure App Configuration, I can change the log level right in the portal. In Program.cs, I can use the Watch method to specify which configuration settings I’ll want to reload when they change.

public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureAppConfiguration((hostingContext, config) => { config.AddAzureAppConfiguration(options => { var azureAppConfigConnectionString = hostingContext.Configuration["AzureAppConfigConnectionString"]; options.Connect(azureAppConfigConnectionString) .Watch("Logging:LogLevel:Default") .Watch("Logging:LogLevel:Microsoft") .Watch("Logging:LogLevel:Microsoft.Hosting.Lifetime"); }); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); });

The default load-time is 30 seconds, but now, should I need to turn up the volume on my logs to get a better view of what’s happening in my site, I don’t need to re-deploy or even stop my site. Simply changing the values in the portal will be enough – 30 seconds later the values will be re-loaded from Azure App Configuration and my logging will be more verbose.

Configuration Source Ordering

The JsonConfigurationSource configuration sources – those which load settings from appsettings.json and appsettings.{Environment}.json – are loaded during the call to CreateDefaultBuilder. So, by the time I call AddAzureAppConfiguration to load in the AzureAppConfigurationSource, the JSON file providers are already in the configuration sources list.

The importance of ordering is evident here; should I want to override the configuration values coming from Azure App Configuration with my local appsettings.json or appsettings.Development.json files, I’d need to re-order the providers in the call to ConfigureAppConfiguration. Otherwise, the JSON file values will be loaded first, then the last source (the one that will “win”) will be the Azure App Configuration source.

Try it Out

Any multi-node or microservice-based application topology benefits from centralized configuration, and teams benefit from it by not having to keep track of so many configuration settings, environment variables, and so on. Take a look over the Azure App Configuration documentation. You’ll see that there are a multitude of other features, like Feature Flags and dark deployment support. Then, create an instance and try wiring your existing ASP.NET Code up to read configuration values from the cloud.

Santorini is an incredible abstract strategy game. Yes, it rehashes the old truism ‘easy to learn, hard to master’ as its tagline, and its artstyle is rife with chibi-style Greco-Roman mythical figures, but trust me, every part of this syncretic approach works. Abstracts have a habit of punching well above their weight, and this one will twist your brain in knots. On a 5×5 grid, players take turns moving figures and placing buildings, step by step, the iconic ivory-and-azur builds of the island Santorini. It is a skillful game with a rich, cutesy presentation.

The core ruleset is wicked simple, but also stays true to abstraction as a genre by offering a robust challenge. Santorini’s masterstroke is to offer an additional layer that gives each player a unique power which breaks the normal scheme of things. Gaia has extra pieces for example, and Artemis can move twice. The game is satisfying even in its powerless, vanilla form, so mixing in these variations makes for a truly infinite challenge. In this, it reminds me of Cosmic Encounter as much as Chess. Both are helter-skelter in its variety, regimental in core procedure. Each turn a piece must move (either adjacently or orthogonally) and then build nearby. A piece can move at most one step up but can ‘jump’ any steps down. The game ends when one player advances their piece to the third level from a lower level. It can also, more rarely, end because the other player cannot make a legal move with either of their pieces. That’s the gist of it, barring certain edge-cases and power interactions.

I had forgotten how rusty I’d become and upon firing up the app for the first time I proceeded to lose to the temptingly-named ‘novice’ AI. A few times. This game has teeth, folks, and its bots will trounce the unwary. Re-learning good play was like revisiting Chess, or perhaps Cinco Paus. Certain patterns and rules of thumb emerge. The center is vitally important, one generally seeks the upper ground to gain the upper hand, and initial placements are almost never around the periphery of the board. It’s difficult to generalize beyond this, but after just a few thoughtful short play sessions, Santorini creates something like a flow state: pure challenge, effortless concentration. Can’t say I’m a grandmaster or that these bouts of time spent were filled with earth-shattering insights, but I can vouch that the flow means it’s an inviting game to lose yourself in.

It’s also an inviting game to learn. The system and rules are so simple as to appear plain, indeed many people bounce off abstracts because they seem ‘dull’, but Santorini has plenty of spirit and style. It’s a good game for kids to pick up, because it has a low barrier to entry and some whimsy to its presentation. Said whimsy belies an absolutely ironclad, zero-variance mental slugfest. ‘For kids’ means the highest praise, cool enough to attract fickle attention but clever enough to hold up over ages. There’s a metagame and deeper level of nuance behind power matchups, but the standard ruleset is extremely refined and punishing. The game has opted for a series of short videos to illustrate bite-sized examples of the game. There’s a mother-lode one for how to play, and a bunch of spin-offs which each explain a specific character’s power. The game also has really clean-cut iconography, with suggestive visual icons for a power above the ruletext and an eminently readable board. The color saturation and architecturally distinct levels make parsing the field at a glance a breeze. So, yeah, it’s polished.

It also has a decent online multiplayer, though here some features are lacking. You find matches either through random pair-ups, or by invitation only with a code. There is an ELO-based ranking system but no official ranked mode. Last but not least, all online multiplayer uses a 45 second turn timer. Usually that’s enough to speed things along without undue pressure, but one would hope that exceptions for particularly vexing turns were possible.

The single player ‘Odyssey’ mode is very fun, structured as a series of God-specific challenges with optional trophies to unlock. Your playstyle and strategic headspace probably has favorite gods and least favorite foes, so if nothing else, Odyssey is a nice way to sample the field. It’s kinda like Splendor’s challenge mode, creating artificial constraints the player has to solve creatively. The game isn’t drowning in content but it is dripping with replayability. Do note that more than a few of the gods are premium DLC, and that their respective parts of ‘Odyssey’ are also locked.

Here at Pocket Tactics, we’re deeply fond of our board game adaptations. Usually they’re a long time coming, and when they arrive they breathe new life into an older, august title. Well, even among these, Santorini is special. For one, its history stretches back a little further than most. It had pretty much become an obscure collector’s item, praised but unknown, from its 2004 self-published version until its 2016 Kickstarter gave it a new art style and high production values, along with widespread, cost-efficient distribution. The game has always been very good, only lately to have been given the just distinction of becoming well-known. It’s even better than most other adaptations, partially because the game is simple, so plenty of attention has been given to bells-and-whistles. There are sophisticated animations, unique effects for each god power, and a full-throated soundtrack.

Santorini is a picturesque dream of an island, and the game with its namesake is as good as it gets. It marries perfectly two distinct brands of appeal, the wildly imaginative to the coldly analytical. Enough beauty and wit are in this one to keep Santorini on a gamer’s homepage and daily rotation for a good while. Great for abstract die-hards, excellent for those just getting their toes wet. The DLC pricing is a smidge high, and the lack of asynchronous multiplayer a little disheartening, but these are trifling drawbacks to a paragon of what abstract board games can be.

Click Here!