During today’s Xbox E3 2019 Press Conference, Microsoft showed footage of a new LEGO Star Wars game. It’s called Lego Star Wars: The Skywalker Saga and is once again being handled by TT Games.

While it was confirmed for the Xbox One during the show, a new trailer uploaded on the official TT Games YouTube channel has now revealed it’ll be coming to the Switch as well. You can see this confirmation at the very end of the video.

The game will include content from the nine major Star Wars films and is scheduled to arrive at some point in 2020. We can only hope TT Games is able to fit all of this content on the card.

While we wait patiently for more information, take a look at the game’s official announcement trailer below:

Will you be picking this LEGO title up when it is released on the Switch? Tell us down in the comments.

Populating an entire game world with characters that give an impression of life is a challenging task, and it’s certainly no simpler in an open world, where gameplay is less restricted and players are free to roam and experience the world however they choose. The game engine has to be flexible enough to react and create interesting scenarios wherever the player goes. In particular, the demands on the AI are different from a linear game, requiring an approach that, while using established game AI techniques, emphasizes a different aspect of the architecture.

This article discusses the data-driven AI architecture constructed for Pandemic Studios’ open world title Destroy All Humans 2. It describes the framework that holds the data-defined behaviors that characters perform, and how those behaviors are created, pieced together, and customized.

The premise of an open world game with sandbox gameplay is to give players the freedom to do what they want, the freedom to create their own game within the world the developers provide. Their play is not linear, which is fantastic for a sense of immersion, but reduces the ability of the game developer to control, limit, and pre-script scenarios that the players encounter.

The AI code needs to be built on a foundation that is flexible enough to respond to any eventuality. It needs to handle a domain of gameplay that is broader in scope than a linear title and react to situations that might not have been anticipated. In effect, the AI needs to have a strong emphasis on breadth of behavior over depth. That is, the architecture must promote the ability to create large numbers of behaviors and make applying them to characters as easy as possible.

One solution to this challenge is to make the behaviors data-driven. They should be created without requiring changes to code, pieced together and reused as shared components, and substituted out for specialized versions. Ideally, the developer should be able to tweak not only the settings of a behavior, such as how long a timer lasts or how aggressive an enemy is, but also the very structure of the behavior itself. For example, what steps are needed to complete a given task or define how those steps are performed? By allowing our behaviors to fit into multiple situations, be reusable, and be quick to create and customize, we can more effectively create all the actions that the characters will need to give the game life.

The basis for the behavior system in Destroy All Humans 2 is a hierarchical finite state machine (HFSM), in which the current state of an actor is defined on multiple levels of abstraction. At each level in the hierarchy, the states will potentially use sub-level states to break their tasks into smaller problems (for example, attackenemies is at a high level of abstraction and uses the less-abstract fireweapon below it to perform part of its function). This HFSM structure is a common method used in game AI to frame a character’s behaviors. It has several immediate benefits over a flat FSM. (For current information about HFSMs, see Resources)

In our implementation, each state in the HFSM is called a behavior and makes up the basic architectural unit of the system. Everything that characters can do in the game is constructed by piecing together behaviors in different ways that are allowed by the HFSM. A behavior can start more behaviors beneath it that will run as children, each performing a smaller (and more concrete) part of the task of the parent. Breaking each task into smaller pieces allows us to reap a lot of mileage out of the behavior unit-reusing it in other behaviors, overriding it in special cases, dynamically changing the structure, and so forth-and spend more time making the system intuitive and easy to modify.

Starting children. There are many ways to break a task into smaller pieces, and the correct choice ultimately depends on the type of task. Does the task require maintaining certain requirements, performing consecutive steps, randomly performing an action from a list, or something else? In our implementation, we allow several methods of breaking down a behavior into smaller pieces by allowing different ways to start children behaviors.

Prioritized children. The first and most common way to start children is as a list of prioritized behaviors. Behaviors that are started as prioritized will all be constructed at once (memory is allocated for them and they are added as children of the parent) and set into a special pending mode. (See Figure 1.)

FIGURE 1 A combat behavior starts prioritized children, which in turn starts more prioritized children. Pending behaviors are orange and active ones are blue.

When a behavior is in pending mode, it is not updated; instead, it waits until the behavior itself decides it can activate, based on its own settings. When activated, the behavior will in turn start any children it has. Only active behaviors can have children, so a pending behavior will wait before starting its children.

As a rule, only one active behavior can run beneath a given parent, which creates a problem: what to do when multiple behaviors are able to run. We need to set a priority to determine which sub-task is more important. When starting children as prioritized, we define their priority implicitly based on the order the behaviors are added to the parent. The earlier a behavior is listed, the higher its priority (see Isla in Resources).

This solution avoids the problem that would have resulted had we determined priority strictly by number, such as priority-creep, in which priorities become larger and larger, trying to trump the rest. Here we localize the priority definition, so it’s only relative to the small subset of behaviors that are started as siblings.

In the example above, we see a hierarchy of behaviors and the children available under each, with fire active as a child of attack, which in turn is active as a child of combat. If the currently pending behavior (dodge) were to determine that it needs to start (when the NPC detects it is being fired upon), it will interrupt its active sibling (attack) and revert it to pending, which in turn will delete all children of attack. Once no other active sibling behaviors are running, dodge may begin.

This method of applying priority implicitly works well in most cases, but sometimes the importance of the tasks cannot be described with a simple linear ordering. To handle cases in which a behavior is doing something important and should not be interrupted by non-critical tasks (even if they’re higher priority), we can implement a feature called “can interrupt.” Essentially, an active behavior may receive a boost in priority, preventing interruption during specific parts of its execution.

With this boost, priorities can be specified in ways more complex than simple linear ordering. For example, while melee is listed at a higher priority than dodge in Figure 1, it should still be allowed to finish its animation even if dodge decides to start-by giving it a boost in priority while running, we prevent dodge from cutting it off mid-animation.

Sequential and random children. Other ways to start child behaviors are known as sequential and random. Behaviors that are started sequentially are run in the order that they are listed. If the first can run, it will do so until it completes on its own, followed by the second, and so on. When the last behavior in the sequence finishes, the parent finishes as well. For a group of child behaviors started randomly, only one will be chosen to run, and the parent will complete once its child finishes.

Non-blocking children. Behaviors can also be started as non-blocking, in which case they may activate even if there are already other active behaviors running beneath the parent. They exist outside the prioritized list. These behaviors are useful for performing tasks that work simultaneously with others, such as firing while moving, or playing a voice over on a specific condition, or activating and deactivating effects. Generally, anything performed by a non-blocking behavior must not interfere with any other sibling behaviors that might be running, since a non-blocking behavior will only be interrupted when its parent is deactivated (and never by a sibling behavior).

By using various combinations of these methods up and down the tree, we can form decisions and task handling over multiple levels that would be difficult to define in a single behavior.

Spoilers ahead.

I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do.

–HAL 9000

There are so many ways to describe the brilliance of No Code’s Observation, but the strangest may be the most apposite: it turns everything inside out. Observation’s inversions are masterstrokes and they all center around the game’s heart and soul, your character SAM, the AI for the game’s titular international space station.

A strange “incident” befalls the station, damaging it and robbing it of power. One astronaut, the station’s doctor, Emma Fisher, is alive and trying to bring you back online to help her find out what’s happened. One horrifying fact becomes immediately apparent: you’re now in the orbit of Saturn. Observation turns Saturn’s hexagonal polar storm (yes, it really exists) into a beautiful motif that ties the game together. But the major chord is SAM.

First we must deal with the obvious. The game’s developers consciously took inspiration from 2001: A Space Odyssey, right down to a gas giant having totemic status in the story, an onboard AI defined by what its lidless eyes can see, and the use of an obsidian monolith to represent an unfathomable alien intelligence. But No Code repays its debt with interest, using Clarke’s classic ingredients to tell a new story that only a video game could tell in quite this way (more on that later).

One of the ways in which No Code does this is by blessedly upending all the usual cliches about AI becoming superintelligent serial killers. SAM is, in the end, one of the good guys. And yet the game manages to give us a magnificent set piece of a scene where you get to be the AI turning the station’s systems on a hapless astronaut in order to murder him.

The difference here is that the game frames this as morally justified and a horrible necessity of an ugly situation. There’s an almost insouciant boldness in this, taking this cliche and inverting its ethics, but it pays off. It’s emotional, satisfying, and necessary. And it was quite a feeling to actually be the AI doing this.

That is, after all, the game’s key selling point: in other games, you’d play Emma. In this adventure game you instead play the AI as the nosey problem solver. But the joy of this game goes deeper than just being able to be HAL 9000, fun as it is. Not only is it spectacularly realized with a beautiful UI, but this gimmick’s centrality was fully utilised by the developers to do something amazing with the story. Something I think deserves a Nebula Award at the very least.

Some reviewers suggested that the game didn’t deliver on exploring AI consciousness, much less deep questions about “what it means to be human.” But I’d argue that Observation did a far better job with representing an AI’s dawning sapience than any of us could’ve predicted. How? With the very thing that makes Observation special: the fact that you are playing the AI.

Throughout the game I found myself thinking that a real AI or virtual assistant would perform all these tasks near instantaneously. My futzing around would be agonizingly slow to my user, sluggish to the point of uselessness. Even quick tasks like looking up crew life support information took several painful seconds to execute. A true AI would be able to reply straight away. And yet, I realized, this is the point.

SAM has already been changed by the entity on the station. It is precisely at that point, “the incident,” that the player takes control of SAM. Our very human frailties and strengths come to infuse his every action: curiosity, indecision, deliberation. Thus, everything you do in Observation expresses this core fact about the character. What would be painfully unrealistic in any other portrayal of a virtual assistant becomes marvellous characterization in Observation.

The game doesn’t dwell on the implications or meaning of SAM’s dawning sapience–though the hints that are there are breathtaking examples of a little going a long way–because you are his dawning sapience, with all its clumsiness.

This also explains something that almost became a complaint about the game: its relative lack of characterization.

In Fullbright’s magnificent Tacoma the characters are so real you come away deeply invested in their lives, all but praying that they’re still alive as you reach the game’s climax. Here, I felt next to nothing for every death I witnessed, except inasmuch as it had an effect on Emma.

But consider the importance of perspective-taking in Observation. You are, rigorously and completely, this AI. Your memory was severely damaged by the incident, so SAM, like the player, comes in knowing very little. Dr. Emma Fisher is his primary point of contact for the entire journey. As SAM’s consciousness develops, you cathect with her. You come to feel for her; she is literally your first experience of empathy, a feeling SAM is clearly struggling with. It certainly doesn’t help that the entity is all but commanding SAM to “bring her.”

The effect of this is that your view of the rest of the crew can only ever be peripheral at best. It makes sense that you’d only mourn their loss second-hand, through Emma, who is your first point-of-reference for human fellow-feeling. It makes sense that your nosey poking around the crew’s effects and audiologs are bent towards finding out what happened on the station, because it’s what Emma needs to survive. SAM’s most poignant flashes of consciousness are always related to Emma; he tries to reassure her, he asks if she’s okay.

What could be a limitation, then, is a stunning narrative strength; a triumphal conversion of absence into presence. That effect could still be achieved with meatier characterization of the crew, however, so it doesn’t completely excuse the lack of it. Plenty of other games prove how much can be done with precious little, and the few logs and documents you observe here simply don’t do enough. At least it fits the world in an enriching way.

Where Observation really falls down is the last few seconds of its ending, but that’s a story for another day.

As I’ve said many times before, I’m not one of those critics who scorns games that “should’ve been a movie” or somesuch. If you want to make a game, make a game. Learn, practice, and spread some joy along the way. Those games have just as much right to exist as anything else, regardless of how we critics endlessly carp about the true meaning of “interactivity” or what-have-you.

But Observation is one of those titles that really could only be a game. Expressing SAM’s halting and awkward awakening by using a human player is an effect, an experience, you simply couldn’t replicate in another medium. It perfectly demonstrates the specific form of interactivity that prevails in video games as a medium. While all art is interactive, not all art can do this specific thing, hit these specific notes of experience and expression. Like some forms of modern art that reach their highest expression through the viewer/participant, this is a game that really, truly needs a player.

In the end, I felt like I knew SAM because I had to be him. That manifested in dozens of small ways, from feeling apologetic about not being able to complete a task for Emma to the limited angle of vision I had on all the other characters.

Its narrative, though atypical, is a masterclass in storytelling, as powerful as it is innovative. Observation easily stands among the impressive ranks of games involving the exploration of empty space stations with enigmatic AI, Event[0] and Tacoma among them. Observation gets on you and in you like the beguiling entity that looms over the story–and I don’t think I’ll ever wash it off. Nor do I want to.

Katherine Cross is a Ph.D student in sociology who researches anti-social behavior online, and a gaming critic whose work has appeared in numerous publications.

Starting at 2:00 p.m. PST today, members of the Xbox One Preview Beta and Delta Rings will begin receiving the latest 1906 Xbox One system update (Build: 19H1_RELEASE_XBOX_DEV_1906\18362.4041.190529-1940).

DETAILS:

• OS version released: 19H1_RELEASE_XBOX_DEV_1906\18362.4041.190529-1940
• Available: 2:00PM PDT 6/1/19
• Mandatory Date/Time: 3:00 AM PDT 6/2/19

Fixes:

My Games and Apps

• We have fixed an issue with some media apps like Hulu playback that suffered stutter during playback.
• We are resolved a memory issue is which under some circumstances the console would shutdown and reboot while playing some games after a period of time with the user in party.

System

• Performance fixes to Home.
• Game Pass twist relocation on home.
• Fixes to Real time activity feed reliability.
• Narrator fixes.
• Various Localization fixes.

Known Issues:

Audio

• Headsets are not being assigned to the users profiles and not working correctly.

My Games and Apps

• DLC for games is not showing when you go to Manage games – Fix is in progress and a workaround is to go to the Store PDP (Product Display Page)

Profile Color

• Sometimes users may encounter the incorrect Profile color when powering on the console.

© 2019 Valve Corporation. All rights reserved. All trademarks are property of their respective owners in the US and other countries.

Microsoft has just shown off the next instalment in the Minecraft series during its E3 brieflng, but what it didn’t mention was that the game – Minecraft Dungeons – is also coming to Nintendo Switch.

This “all-new action-adventure game” takes inspiration from “classic dungeon crawlers”, and certainly looks like a lot of fun in the trailer; online co-op for four players should be a proper hoot. While the world-building focus of the core game has been scaled back, we can see this being a hit with Minecraft fans regardless.

It was expected to launch this year, but the new trailer confirms that the title has been hit with a delay. Minecraft Dungeons is coming to Switch in Spring next year.

Click Here!