News – Page 50 – Sick Gaming

Posted on November 20, 2020 by sick skills — Leave a comment

Deep Dive: Evolving the UX/UI of A Total War Story: Troy using user testing & feedback

The Gamasutra Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game, in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.

Earlier installments cover topics such as building an adaptive tech tree in Dawn of Man, achieving seamless branching in Watch Dogs 2’s Invasion of Privacy missions, creating the intricate level design of Dishonored 2‘s Clockwork Mansion, and the tech behind Gears Tactics.

In this edition, Alex Tomakchiev, Lead UI/UX Game Designer at Creative Assembly Sofia, shares how user testing and player feedback helped inform the UI/UX driven design of A Total War Saga: Troy‘s ‘End Turn’ button.

The Beginning (Iteration #1)

Let’s start by looking at one of the most important UI elements in turn-based games – the End Turn button. For a long time during development, our End Turn button looked and behaved very much like it does in Total War: Warhammer II. It used an hourglass icon and if you had pending actions it would show you a different icon for every action.

The end turn button represented by the hourglass.

When you clicked on the button, it would select a game object or open a panel to prompt you to act on the corresponding action before ending your turn.

An example of the Royal Decrees notification shown on top of the End Turn button.

This was a good quality-of-life feature that helped remind players of all the actions they hadn’t yet completed, but it also had a downside. We would only display the End Turn button after you had resolved or skipped all of your pending notifications, which in mid-to-late game meant that you might have to go through 20+ clicks before even seeing the End Turn button.

However, we didn’t give this much thought since we had gotten used to this behavior ever since WH2. Our core players had also seemingly gotten used to it, but then we started doing user tests and quickly ran into unexpected problems.

The Test

One of our tests was with a group of gamers who had never played a Total War game before and had little to no experience with turn-based strategy games. Now, I know what you’ll say. “Why would you test people who’ve never played Total War when you have people who’ve been playing it for 20 years?” Don’t worry, we asked them, too. But Troy was initially released for free on the Epic platform which meant that we’d have a huge influx of players who were completely new to the franchise. We needed data on what the player experience would be for those people.

Spoiler alert – it wasn’t great.

So, we prepared a build, organized the test, invited people and started observing them as they played. At this point we were feeling pretty confident with the game, but then people started playing and reality hit us in the face.

One person has spent 40(!) minutes on their first turn because they couldn’t figure out how to end their turn.
Another asked “What do I do now?” after they’ve done most of what could be done on turn one.
A third recognized the importance of the End Turn button, but because they had pending actions, they were seeing an icon to issue a Royal Decree. Once they did that, they completely ignored the button for the rest of the playthrough because they thought it was a button for decrees, not for ending a turn.

Obviously, this was not the first time user experience we were hoping for. New players had a hard time ending their turn. In a turn-based game.

So, we started scratching our heads and it turned out we were facing a few key issues that all contributed to people not ending their first turn.

The Road to Release (Iteration #2)

Issue 1: It turned out that showing a bunch of notifications and having players go through them before they can end their turn was rather confusing. Regular Total War players were used to it, but new ones? Nope.

Solution 1: We explored two solutions aimed at detaching notifications from the End Turn button so we could have it visible at all times.

The first was simply to make a separate button for notifications and move it next to the End Turn button. It looked a bit like this:

An initial mockup of notifications alongside the end turn button

Solution 2: The second solution was to move all notifications to a new menu and treat it as a “to-do” list. Ultimately, we went with this because we felt it would be more valuable for players to see them all at once instead of clicking through them one-by-one. It also allowed us to expand the text strings and be more specific. If previously we had “Hero not moved” as a notification, now we’d also show the hero’s name, so players could quickly scan and decide which ones they wanted to move and which ones they didn’t.

An initial mockup of the ‘to-do list’ style of notification menu

However, this change also meant we no longer had anything to stop players from ending their turn IF they had pending notifications. Sure, there was a list of them, but there was no guarantee they’d open the list in the first place, we just assumed they would.

We implemented the change, even adding some animations and states to the new Notification button, thinking that would be enough to catch players’ attention.

Issue 2: Remember how I said that initially our End Turn icon was an hourglass?

Now ask yourself: if you see this ⌛ on a button, what would you assume that button’s function is? One of our QAs raised that question shortly before release and my jaw dropped.

I organized a quick survey to ask people exactly that. 100% of the answers were “loading”, “waiting”, “buffering”, “in progress”, “speed up time”, “slow time”… You get the point. It was right in front of our eyes, but we couldn’t see it because we were so used to it.

One of my explanations was that as gamers, we somehow collectively agreed that the hourglass would represent the end of a turn when Heroes 3 used it back in 1999 and we just kind of rolled with it. But for someone who hasn’t played Heroes or another turn-based game it could be very confusing.

A screenshot of Heroes of Might and Magic, showing the hourglass icon used to end your turn

Solution: We changed the icon to a right-pointing arrow like the one used in every media player ever to show the action of “Next”. We were so used to how things were that someone had to actually ask “Why?” to make us even think about it. This is what we ended up using:

The notification list alongside the new arrow icon used for ending a player’s turn

Release And Beyond (Iteration #3)

Then came the release. TROY was claimed by over 7.5m people and we were ecstatic for them to finally play it! They did and they started sharing feedback. Players no longer had a problem ending their turns, but now it was so easy to do it that we started seeing them ending a turn just to then say “Oh, wait! I forgot to move my army!“.

Naturally, regular TW players noticed this and said “Why did you remove my end turn notifications? It helped me when I was playing and now I forget to do things constantly!“. And they were right! We made a mistake by removing a useful feature just to fix another issue.

The problem was that the notifications were still in the game, BUT, players just weren’t opening the list to see them. And why would they? We didn’t make any effort to draw their attention to the list.

Once again, we went back to the drawing board and it turned out the solution was quite simple.

All we had to do was to look back at the original implementation and take what was good about it (in this case, the contextual button before the End Turn button). Only this time, we’d show it just once, with an exclamation mark icon and upon clicking it would open the notifications list. Done.

This allowed us to resolve both issues at the same time – not obfuscating the End Turn button behind 20 other ones, while still retaining the “hey, don’t forget these things you can still do” functionality. We also implemented a little improvement to the layout of the Notifications list – we introduced notifications groups.

The current implementation of the End Turn and Notifications list in the game

Because of the time it took to ship these final iterations, (three months had passed since release) we knew that some players would’ve gotten used to how things now worked and it wouldn’t have been right for us to force this new iteration on them. So we added it as an option instead.

The new notification menu option found in Game Settings

And this is where we are now. It’s a good place. Or so we think for now.

Hopefully this story shows you how one UI element can take so many iterations to get right, as well as share some of the lessons we learned along the way (or at least reinforced our knowledge of) such as:

User testing will show you things you haven’t even considered
Never assume
Look for solutions that work for all types of players
While getting your design right first time should always be the objective; iteration is a necessity to make improvements and to truly achieve a good design solution!
If you can, give players a choice, don’t lock them into your judgement of what’s right

And we are done! I’ll see you next time.

Posted on November 20, 2020 by sick skills — Leave a comment

A quick UX lesson from GDC Masterclass teacher Celia Hodent

How can game developers better design experiences around their players? This often-asked question is one that Celia Hodent has a particularly strong grasp on, given her expertise in the field of User Experience design (AKA UX).

This December, Hodent will be teaching a day-long Masterclass course on player psychology and UX principles. We wanted to give you a taste of her class in advance, so we reached out to her for a quick Q&A that may help you in your day-to-day game development life.

For your benefit, here’s a conversation between Hodent and a hypothetical game developer looking to solve specific challenges with their game based on player feedback.

Hey Celia, I’m a game designer looking to understand more about UX and player psychology. We’re working on an online multiplayer RPG with a lot of moving parts. We have a solid A/B testing process for new features but we’re looking for ways to introduce player psychology into our process.

What are some of the first steps you take in your work when doing this kind of testing? How do you make sure you’re getting useful data out of it?

Gathering data is a great start! But data is not information. Telemetry data is great to figure out WHAT is going on in your game, but not easily WHY. Let’s say that you see that many players are dying from a specific telemetry event (whether it is from a specific AI enemy, against a specific weapon in PvP, or in a specific location). That’s good to know, but it’s not very helpful by itself.

You need to understand why in order to make decisions. Is it because players don’t understand what is killing them? or because a specific weapon is overpowered? or is it because there’s a usability issue leading players to not even realize that they are getting damage? Making shots in the dark based on gut feelings is not an efficient process to solve problems affecting the player experience. In order to get meaningful insights from telemetry data that will help you make the right decisions faster, you need to start by posing hypotheses very early on the development process.

When considering UX and cognitive science, a common hypothesis would be “If players don’t understand how [feature] works, they won’t be able to feel competent at playing the game and they will therefore churn” (not feeling competent at playing is strongly hampering engagement).

If prior to your beta you have conducted playtests where you observed players and asked them questions, chances are that you’ve spotted early on UX issues that will help you anticipate what precise telemetry hooks you will need once the game is launched to make enlightened decisions faster.

In summary, the first step is to very early on think about what players need to understand in your game in order to progress, feel competent, and master it (among many other things). So that you can spot much faster when something goes wrong and fix it. This mindset (which is the essence of UX) is what will help you once you’re in the beta stage.

You can’t “introduce player psychology into the process”. Considering human factors at every step IS the process.

That’s helpful!! Here’s my next question: we’ve gotten some feedback from players over time as we’ve problem-solved various issues that the game seems to be getting easier, but not necessarily more fun. We think we may have overcorrected in our process by sanding off the edges of some encounters.

In your work, what’s been a useful step for figuring out when player frustration is good frustration, versus when it’s frustration developers should be trying to eliminate?

That’s a great question. Fine-tuning the difficulty curve is important to offer a good UX, as it’s one of the key components of game flow, which in turn is one of the three pillars of engageability (along with motivation and emotion).

A game should not be too easy, or too hard. The problem is that different players have different levels of expertise and need different levels of challenge. Also, some games are specifically sought out for their high level of challenge (such as Souls games), while other games can be appreciated when they are more chill. Thus, many factors are at play.

Generally speaking, when a game is too easy players get bored and might stop playing. When it’s too hard, they might rage-quit. This is one of the things that we can only fine-tune once the game is in beta and played by thousands of players, thanks to telemetry data and player feedback.

Both are important to look into, as there can be a big gap between what players say and what they do. But if they say that they find the game too easy in surveys and telemetry data tells you that players are churning, it can indeed be a sign that you need to raise the level of challenge in your game.

If these sound like the kinds of questions you’d ask Hodent if you had the chance, get your own answers and sign up for her GDC Masterclass before seats fill up!

Gamasutra and GDC are sibling organizations under Informa Tech.

Posted on November 20, 2020 by sick skills — Leave a comment

Blog: General tips for ‘Games as a Service’ indie games

<!– –> Gamasutra: Yannick Elahee’s Blog – Updating your games after production, general tips for Games as a Service for indie games

Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC’s registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Games

<!–

View All Submit Event

–>

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

Tips to organize Live Updates for indie games

When your game passes the gold version but still get updates, we call it live ops developement or “game as a service” (GAAS). Big companies are praising live ops and indies are getting in this new trend as well. But this is not a small decision and you should be aware of major challenges. We will talk about:

Changing your production organization
New marketing challenges
Understanding your players expectations
and much more!

Should you do live ops at Release?

If you have a narrative game, live ops is probably not for you! But you can think of new stories in DLC or free chapters to add later.

If your game is not purely narrative, you have a few things to consider before doing live updates:

Do you really want it? Don’t do it if you’re exhausted from production.
Did you bring enough revenue so updates are actually worth the money?
Has your game under-reached it’s potential? Maybe updates can help on long-term sales to catch up!

Yes, those two last points are super hard to estimate. I generally advise to not do live-ops updates if your game has been sufficiently marketed and only generated 25% of it’s production costs during month 1 of release.

Check out this article by Simon Carless to see an average on how much games do 1 week, 1 month and 1 year after release.

https://gamediscoverability.substack.com/p/data-deep-dive-whats-the-long-tail

Reactivity

When creating updates, there is a continuous flow of things developer have to do. Game designers have to tune in new features, developers have to implement new stuff, level designers have to tweak values, graphic artists have to make new mockups and graphic items.

The problem is that now, the time scale is much tighter. They used to have 3 to 6 months to plan ahead and prepare stuff. Now, it’s only 1 or 2 months max. The art direction must stay the same, no bugs should arise from old features, new content has to be even better than the previous one.

In this storm, as a marketer you’ll be the one at the end of the pipeline. Most of the time, everything must be 100% ready before you can speak about it. Players will complain that you’re not talking enough. The truth is if you’re only speaking to say useless things or features that will never see the light, they’ll resent you as well.

The key here is to improve your tools. If you’re fast enough, you’ll be able to put up PR & dev blogs on the fly without spending too much time in preparation. Here are some things you can put up in place:

Learn to make gifs, arts & others on your own. It doesn’t necessarily mean understanding how to design, it can also be using premade assets & fonts from the graphic art team.
Get a good translation pipeline. Try to hire translators who can be reactive and answer emails fast. Getting professional translators is often better because amateurs tend to do it on the side.
For everything mass mailing, use some newsletter system and get something easily editable, with templates and such.
Get a proofreading app. It will help you clean 50% of mistakes on your own and maybe avoid getting an editor.
Have a solid database of organized assets. You don’t want to fetch assets, links, texts for too long!

Hiring & People Management

The problem with live ops is that you probably have 2 years or so behind you. When the game got released, you team might be burned-out. Think abot your structure, getting new people, or putting the current one on new projects!

New people give a new perspective on game design, art and much more. They have a solid base that can get new, exciting, sometimes game-breaking changes.

Be careful to hire people that get, and like the base, the vision. They need to push the game in the best direction possible while keeping the current players happy!

After the release of your game, let your team take holidays or days off in the week. Maybe switch to a 3 days work week during a few weeks or even during this whole new phase can be interesting. You’re going a fresh energy, either from new or former workers.

Game companies sometimes hire third-party studios to create new DLCs and updates ! Motion Twin gave Dead Cells to Evil Empire, they’re now producing DLC with paid and non-paid content. I’ve heard there are other companies more and more doing this!

When releasing a game, it’s interesting to have a clear roadmap. Players love to know what’s coming up, what content is in preparation, how the game will change and evolve.

Be careful though, if you change the roadmap make sure the changes are SUPER visible. Your hardcore fans ARE waiting for some features!

I suggest that you separate your upcoming content into MAJOR and MINOR features.

For instance you can release every 1 or 2 months, 1 major feature, and at least 2–3 minor features. It’s even better if it’s aimed for short, medium or long term game sessions. Make sure every profits from getting a new update!

Community Debugging

Some people take the opportunity of live players to allow them to report bugs. People like to complain when there is a bug, and they like to know it’s acknowledged by developers. There is nothing more frustrating to a player that a recurring bug that never gets addressed!

We’re missing some tools to make this community debugging, but the most frequents are:

Discord, sometimes helped by a bot
Trello, where people can upvote / sometimes create issues
Public repository such as the example of Spellcasters University
Ingame reporting tools, that get more popular but lack an efficient tool that can be easily deployed

Analytics

You can implement Analytics when the release is 75% completed! Too soon and you’ll lack content to analyze. Too late you’ll miss a good chunk of players as well as the opportunity to balance things out!

I’ve struggled with it myself, and built a custom backend! But it was too much work, and I’m now using Game Analytics. It was a bit complicated at first, but now we have pretty interesting marketing & design stats!

Quick & Good promo

Biggest studios get a video trailers to showcase the changes! You can also do one, but it takes new skill you may not have inhouse. I think we’ll see these “promo trailer” more and more.

Be careful though, they take time to make and sometimes don’t gather enough attention because it’s “only” a game update. It depends on the type of new content you’re pushing!

That’s it for now! Have a great day and let me know if you have any questions about live ops for indies.

Tavrox.

I’m making a game called Neurodeck! Check out the steampage!

Related Jobs

<!–

Extra Div –>

Posted on November 20, 2020 by sick skills — Leave a comment

Seattle mobile studio Lightfox nets $3.3 million to bring debut title to market

Seattle-based mobile developer Lightfox Games has secured $3.3 million in seed funding to bring its debut title, Super Battle League, to market.

The investment round was led by March Gaming, with participation from Hiro Capital and 1Up Ventures.

Lightfox was founded in 2019 and has put together a team comprised of industry veterans from companies including King, EA, Disney, Epic Games, and Amazon.

The studio’s debut project, Super Battle League, is being pitched as a 3v3 real-time mixed PvE and PvP multiplier title where players race to see who can beat the boss first. Lightfox believes the game will entice casual players, allowing the company to “capitalize on this underserved part of the market and expand the genre.”

“To date, mobile midcore games have struggled with attracting and retaining a wider casual audience. Real-time multiplayer games like Brawl Stars and ‘battle royale’ games have been successful in offering midcore players a competitive outlet on mobile but haven’t drawn in a more casual audience,” said the studio.

“[Super Battle League] presents as a casual party-based PvE game with its portrait orientation and one-handed play. Depth is subsequently layered in, as players get more exposed to PvP play and work to level up their gear while competing in hundreds of randomly generated arenas,” explained the studio. “

There’s no word on when the title will be rolled out worldwide, although it’s already available in select regions on iOS and Android.

Posted on November 20, 2020 by sick skills — Leave a comment

Nintendo has added cosy AR cabins to Animal Crossing: Pocket Camp

Nintendo has announced that it is adding AR features to its long-standing AC mobile game, Animal Crossing: Pocket Camp. These two new modes – called AR Camera and AR Cabin – let players spend some quality time with their favourite villagers. The first, AR Camera, lets you set up a space for your pal, adding furniture to the scene, and taking a snapshot. AR Cabin, on the other hand, is a little more comprehensive, and lets you enter the same space as the characters.

You can turn this AR Cabin into a cosy hideaway, and overlay the door anywhere in the real world, allowing you to enter whenever you want. Once in your cabin, you can invite up to eight of your favourite villagers to hang out in the space. In celebration of this new mode, Nintendo are also giving away a free month of the Furniture and Fashion plan, which is a great way to get some new clothes and home decorations.

For those unfamiliar, Animal Crossing: Pocket Camp first launched three years ago, and is Nintendo’s free-to-start mobile game. In Pocket Camp you build a campsite and invite friends to come stay. You can also visit different locations, catch bugs, fish, and pick fruit. It isn’t as comprehensive as New Horizons, but it’s still a fun on-the-go experience for any AC fan.

If you want to know more about the AR features, check out the release trailer below:

[youtube https://www.youtube.com/watch?v=OTr21GedotM?modestbranding=1&rel=0&feature=oembed]

AR Cabin and AR Camera launched on November 19, and are available in-game now.

If you want to play Pocket Camp for yourself, you can find it on Google Play and the App Store. For more relaxing recommendations, why not see our list of the best mobile idle games?

Posted on November 20, 2020 by sick skills — Leave a comment

Unity Closing Unity Connect

Unity Connect was first launched back in 2016 as a sort of social hub for Unity developers. Due to declining interest Unity have announced Unity connect will be closing by February 4th, 2021. Users were sent the following email announcing the closure:

Hi User,

Today we’re announcing that on February 4, 2021, Unity Connect, our dedicated talent and sharing marketplace, will shut down. We’re proud of the community that rallied around Connect and we are inspired by the great sharing and discovery that came from it.

We want to make this transition as smooth as possible for everyone who uses Connect. If you are an active user on the platform, click here to learn more about the alternatives that will be provided for some Connect features. If you would like to download any part of your profile, please feel free to do so before we delete your information on February 4, 2021.

If you head on over to the Unity Connect website you will see a notice of the upcoming closure with the following details:

We launched Unity Connect almost four years ago in an effort to provide a free community tool for all users, of all experience levels, to connect with each other. While the product has a loyal following, over the years usage has declined. So, on February 4, 2021, we will retire Unity Connect. Some features, e.g. posting new content, creating job posts, will be locked prior to this date.

We understand that these changes might cause inconvenience, therefore, we have made sure to provide alternatives for some of the most popular Connect features, please read on to learn more.

You can learn more about the Unity Connect closure and the alternative services available for Unity Connect users in the video below.

[youtube https://www.youtube.com/watch?v=4gXx4_7IKEQ?feature=oembed&w=1500&h=844]

Posted on November 20, 2020 by sick skills — Leave a comment

What the Golf’s Snowtime update brings a white – and weird – Christmas

For anyone who hasn’t played What the Golf, it’s a parody golf game which gives the words “crazy golf” a whole new meaning. Each level presents a course with club, ball, and hole – like any golf game – but after that, who knows what will happen?

Perhaps your ball has a mind of its own (literally) or your club turns into a sheep. There is seriously no way to predict what each level will bring, and it’s your job to figure out how to get the ball (or sheep, or tree) into the hole (or mountain, or car). If you’re beginning to think that you’ve figured out the meta vibes of What the Golf: you’d be dead wrong.

Every update for the game has brought new, inventive levels and nothing feels old. The developers have a seemingly bottomless brain-pit filled with physics-based puzzles and quirky alternatives for golf clubs. And the Snowtime update, which went live on the App Store and Apple Arcade yesterday, looks to be more of the same.

For What the Golf’s non-denominational winter celebration, the developers have recruited frozen peas, frozen pizzas, and a frozen landscape for Snowtime fun – after all, there’s Snowtime like the present, right?

[youtube https://www.youtube.com/watch?v=9UaWxylfEMk?modestbranding=1&rel=0&feature=oembed]

There will also be some snowman-related challenges, perfect in case we don’t get an actual White Christmas (which seems unlikely, given we literally never do). Here’s everything included in the Snowtime update (if you can decipher it):

Fetch the pizza quest
Yes now with snow
Pizzas
Extra COOL levels
Frozen peas, pizzas, and popsicles
A moose – NOT frozen!
A snowman trying to keep a snow profile
Did we mention pizza?
Even more chilly physics!

As well as a penchant for puns and pizza, the Snowtime update is sure to bring more inventive levels, dubious humour, and exciting changes to everyone’s favourite parody golf game.

If you like the sound of What the Golf, make sure to also check out the best mobile puzzle games. They might not carry the same irreverent humour, but definitely offer a great challenge. Alternatively, check out our roundup of all the Apple Arcade games to make sure you get the most bang for your buck!

Posted on November 19, 2020 by sick skills — Leave a comment

Video: Making compelling character interactions for VR NPCs

In this 2019 XRDC session, Beast Inc.’s Vivian Tan explains how tools and techniques that are accessible to VR developers, including hand gestures, eye contact, and other forms of spatial interaction, can be used to create compelling AI characters.

In addition to this presentation, the GDC Vault and its accompanying YouTube channel offers numerous other free videos, audio recordings, and slides from many of the recent Game Developers Conference events, and the service offers even more members-only content for GDC Vault subscribers.

Those who purchased All Access passes to recent events like GDC already have full access to GDC Vault, and interested parties can apply for the individual subscription via a GDC Vault subscription page. Group subscriptions are also available: game-related schools and development studios who sign up for GDC Vault Studio Subscriptions can receive access for their entire office or company by contacting staff via the GDC Vault group subscription page. Finally, current subscribers with access issues can contact GDC Vault technical support.

Posted on November 19, 2020 by sick skills — Leave a comment

Don’t Miss: How GoldenEye 007 set a new standard for video game AI

<!– –> Gamasutra: Tommy Thompson’s Blog – The AI of GoldenEye 007

Gamasutra is part of the Informa Tech Division of Informa PLC

<!–

View All Submit Event

–>

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

[embedded content]

AI and Games is a crowdfunded series about research and applications of artificial intelligence in video games. If you like my work please consider supporting the show over on Patreon for early-access and behind-the-scenes updates.

Note: All screenshots and video footage in this article and the video above are taken from an emulated copy of the game. Specifically, the GEPD edition of the 1964 emulator plus the GLideN64 video plugin.

GoldenEye 007: one of the most influential games of all time. A title that defined a generation of console gaming and paved the way forward for first-person shooters in the console market. In this article I’m winding the clock back over 20 years to learn the secrets of how one of the Nintendo 64’s most beloved titles built friendly and enemy AI that is still held in high regard today.

Upon its release in 1997, GoldenEye 007 not only defined a generation, but defied all expectations. A game that Rare, Nintendo and even the Bond franchise holders MGM had little faith in. Released two years after the launch of the film it’s based on and one year after the consoles release to market, it seemed doomed to failure, only to become the third best-selling game of all time on the platform behind only Super Mario 64 and Mario Kart 64, selling over eight million copies. Not to mention earning Rare a BAFTA award for developer of the year in 1998.

It’s a game that carries a tremendous legacy: defining the standards of what we would come to expect from first-person shooters for generations to come, specifically in AI behaviour. AI characters with patrol patterns, enemies that call for reinforcements, civilians that run scared, smooth navigation and pathfinding, a rich collection of animations, emergent dynamic properties of play and so much more. It not only defined a generation, but also influenced the games that succeeded it, from Half Life to Crysis, Far Cry and more.

I’m interested not just in how the AI was designed, but how the hell they even got it to work? If you consider many of the AI techniques I’ve explored such as finite state machines, navigation meshes, behaviour trees, planning technologies and machine learning, none of these were established practices in the games industry when GoldenEye was released. Not to mention the fact the Nintendo 64 is pushing 25 years old and when compared to modern machines had minimal CPU and memory resources. How do you build AI and gameplay systems to run so effectively on hardware that was so tightly constrained?

To find out the truth, I reached out to the ultimate undercover informant: Dr David Doak. David was a pivotal member of the development team for both GoldenEye 007 and – perhaps fittingly for this series – is immortalised as the non-player character players must meet in Facility: the 2nd level of the game. During our interview we explored NPC AI, alert behaviours, sensor systems, navigation tools, performance balancing and much more. So let’s get started in finding out how it works.

Winding back to the beginning, much of what GoldenEye became was devised by two people: Martin Hollis – the producer and director of the game – and Mark Edmonds who was the gameplay and engine programmer. Hollis had originally been inspired by the likes of Virtua Cop, where enemies would jump into frame, take shots at the player and then back off or hide or react to being shot in a dynamic fashion. However, Hollis sought for the AI to be more engaging and reactive, transcending the standard set by DOOM in 1993.

“The important thing is to show the player the AI. There’s no point having sophisticated AI that the player doesn’t notice.
Your NPC’s can be insightfully discussing the meaning of life, but the player won’t notice if the game requires that they swing around a corner and fill the bad guys with bullets. So the intelligence has to be evident. The game mechanics have to showcase the AI. The level setup has to showcase the AI. And it all has to make an actual difference in actual gameplay.”
[Martin Hollis, 2004 European Developers Forum.]

This resulted in guards and patrolling enemies – forcing a more tactical consideration for entering environments. Vision and audio sensors that enabled AI to react to player behaviour – or remain unaware if stealth was employed. Plus friendly and civilian characters that would react to the players presence and either cooperate or run away.

When David Doak joined the project, a lot of the core engine components for 3D movement, rendering and simple AI behaviours were already established by Edmonds. However, over the course of the final two years of the projects character movement, much of the AI behaviour and other core gameplay systems were established, with a lot of moving away from being player-centric, establishing patrol patterns, moving into alarm states, using control terminals, urinals and much more.

To achieve this, Mark Edmonds built an entire scripting system within the C-written codebase, which was constantly being added to and updated as Doak and other members of the team experimented with ideas. Quite often a new idea would be proposed to Edmonds who would ponder the feasibility of it all, then go away and have a working version of it in-engine a day later. This scripting system allowed for developers to link together numerous precompiled actions into sequences of intelligent behaviour based on very specific contexts. These behaviours would spool off their own threads for execution and release resource as soon as possible once the next atomic behaviour was executed, then wait until it’s possible to update once more. These scripted behaviours are not just for the friendly and enemy characters, but even systems such as timed doors and gates and the opening and closing cinematics for each level that take control of the player and other characters in the world.

If you dig into the GoldenEye Editor originally developed by modder Mitchell “SubDrag” Kleiman, these AI behaviours have been reversed engineered into editable Action Blocks for you to build your own behaviours. Enemy guards can react to a variety of different sensory inputs, ranging from being shot, to spotting the player or another guard being shot while in line of sight, as well as whether the guard can hear gunshots happening nearby. In addition NPCs can opt to surrender based on probability but more critically on whether the player is aiming at them, with behaviours shifting in the event the AI knows the player isn’t targeting them anymore. As I’ll explain in a minute, the visual and audio tests required for these behaviours run on tightly constrained and stripped down processes that still achieve impressive results, while running on the N64’s limited hardware.

Based on these conditions, guards can execute a variety of different behaviours, including side steps, rolling to the side, fire on one knee, while walking, while running and even throwing grenades. Much of the rationale for these actions is driven by where the player is relative to them and their current behaviour.

It is for all intents and purposes a rather simple Finite State Machine, whereby the AI exists in a given state of execution into a behaviour until an event in-game forces a transition to another one. This same principle was later employed in Half-Life, which came out the year after GoldenEye in 1998 and the team at Rare were aware of the impact their game had on Valve’s critically acclaimed shooter. Given Valve told them so themselves:

“My favourite moment was meeting the original Valve guys at ECTS, a UK trade show, in 1998 and them joking that GoldenEye had forced them to redo a bunch of stuff on Half-Life. They went on to do all right.”
– David Doak, GamesRadar, 2018.

Now the two most critical elements of the Goldeneye engine for controlling the AI is the camera, as well as what’s known as the STAN system. For ease of rendering, levels are broken up into what are known as ‘rooms’, with even large open levels such as the Severnaya surface broken up into smaller chunks. This helped maintain performance as a form of occlusion culling, whereby only rooms in the cameras view frustum would be rendered. But in turn, AI – for the most part – would not execute their primary behaviours unless they’ve been rendered by the camera at some point. This helps execution costs down, but also lends itself to some interesting opportunities which I’ll come back to later.

But the key system that intersects with the room and rendering behaviour is what was known as the STANs – which is just a four-letter abbreviation of ‘Stand’. Developed by Martin Hollis, STANs are polygonal meshes in given room that would be flagged for use as a STAN and would know which room or hall it is placed within. If an AI character was standing on top of a given STAN, it would only be able to see the player if the STAN the player was standing on was in the current or adjacent room and ran a simple validator that checked whether two STANs could ‘see’ each other. This allowed for a more cost-efficient way to run sight tests, rather than running 3D ray traces that would prove a lot more expensive to run on the hardware. This works remarkably well, but does break in some specific certain circumstances, a notable example is the guards on the dam which can’t see you until you approach their walkways and this is because the STANs at the top of the ladder can only see those at the bottom, meaning you can mess around as much as you like in proximity, but they won’t notice. The second noticeable instance is the spiral path in the caverns, where the NPCs see the path in front of them rather than what’s on the other side of the chasm.

Now with these STANs placed all across each map, there is the opportunity to build atop these polygons that are darted across the map to build a navigation system. In modern games we typically use navigation meshes, which provide a full polygonal surface that dictates where characters can move across a map. Nav meshes didn’t exist in their current form back in 1997, so for GoldenEye the team took the STAN system and added atop it what was referred to as PADs. PADs would sit atop STANs but also be linked to one another, effectively creating a navigation graph through the map. Characters know what room they’re in and can then run a search for a PAD in a destination room if they’re reacting to a nearby commotion, or move across the STANs while in their current room to items of interest.

This is topped off by the audio sensors. These run a simple proximity check to based on characters being within a certain radius of a sound occurring. But it’s also reliant on the type of weapon and the rate it’s being fired. While a silenced PP7 doesn’t attract attention, a standard PP7 is loud, but the KF7 Soviet is even louder, with continuous fire leading to the activation radius reaching maximum level, with only the rocket launcher and the tank cannon being deemed louder.

All of these AI tools and systems are very impressive, it shows a intentionality of design that sought clever and effective means to address specific elements the team wanted to see in the game. But there are still many other elements of how GoldenEye works that required individual bespoke behaviours to be crafted, almost on a per level basis. NPCs did not actively hide behind cover, so levels such as the Silo and the Train required unique scripts to be created for them to stand near specific PADs on the map and react differently depending on whether it was a half or full sized object.

The NPCs are not aware of one another in the map, hence levels where you have to protect Natalya Simonova not only had to ensure that she could move around the level, but custom behaviours were built to ensure enemies don’t shoot at her en masse and also aim at the player. Having characters like the scientists freeze at gunpoint and then run away or even Boris Grishenko who would do as he’s instructed until you stopped pointing the gun at him are more bespoke behaviours that needed to be built for that specific context. This means that many of the principal characters from the story have different custom AI behaviours written to solve specific elements of a given level, with Alec Trevelyan having unique behaviours built for him in all six levels he appears in: Facility, Statue, Train, Control, Caverns and Cradle.

Plus there were issues of level design and pacing that needed to be addressed. The Severnaya exterior levels proved problematic for balancing the AI positioning, so custom level scripts spawn in enemies beyond the fog range that run straight towards the player. But also if enemies are too far away, they simply disable themselves and may later reactive once more.

Arguably my favourite feature, is how GoldenEye is built to punish louder and more aggressive gunplay if the player isn’t progressing through the level fast enough. Remember how I said earlier that NPCs don’t activate their AI behaviour if they haven’t been rendered yet? Well, in the event a NPC can hear a sound, but it’s not been rendered, it will spawn a clone of itself to investigate the source and will continue to do so until either the disturbance has ceased or the camera has finally rendered the character. This is particularly noticeable in levels such as the Archives, where you can easily get trapped in the interrogation room at the start of the level by continually spawning clones.

In order to better pace the overall experience – as well as accommodate for the lack of aiming fidelity in using the Nintendo 64 controller – the transitions and durations of animations were tweaked heavily throughout testing to allow players a better chance of prioritising targets either using auto or precision aim mechanics.

With GoldenEye released, this rendering and AI toolchain was put to good use in later titles, with Rare’s spiritual successor Perfect Dark employing the same systems but included new additions. As mentioned before, GoldenEye NPCs only go into cover a custom behaviour was created for them to do so, but in Perfect Dark enemies are capable of calculating cover positions – including dynamic ones created by anti-grav props. Plus having experimented with vertex shading lighting, vision sensors are impeded by the lower visibility. This same process was later adopted at Free Radical Design for the Timesplitters franchise – given the studio was founded by several of the GoldenEye development team – and required the STAN/PAD system to be built to better support verticality in level design.

While over 20 years old, GoldenEye set the standard that Half-Life any many other shooter franchises have sought to replicate to this day. I hope having watched this video you can appreciate the depth of the underlying systems and the level of dedication and craft required to elevate the project to what it became in the end.

Related Jobs

<!–

Extra Div –>

Posted on November 19, 2020 by sick skills — Leave a comment

Facebook Joins Blender as Corporate Sponsor

Today Blender announced that Facebook would be joining the Blender Development Fund as a Corporate Sponsor. A corporate sponsor is the highest tier of sponsorship and means at least 120K euro per year in financial support, which generally gets translated as two full time developers on the project. Facebook will be joining the likes of Unity, Epic Games, AMD and NVIDIA in the corporate supporter tier.

Details from the Blender announcement:

To support these artists and the countless other animators, researchers, engineers, designers and content creators who depend on open source tools, Facebook wishes to contribute to the development of Blender. Which is why we’re proud to announce that Facebook will join the Blender Foundation’s Development Fund as a Corporate Patron as of Q4, 2020.

We at Blender see this as another important signal of the industry’s willingness to migrate to open source, and contribute to open source’s continual improvement.

Ton Roosendaal,
Chairman Blender Foundation

Facebook currently use Blender in their AR product Spark AR Studio in addition to their ownership of Oculus. If you are worried about the corporate influence on Blender, don’t worry about it, for reasons described in this video. If you want to learn more about Facebooks support for Blender be sure to check out the video below.

[youtube https://www.youtube.com/watch?v=4aNzkxQs-K4?feature=oembed&w=1500&h=844]