Category: News

“We rewrote the game all the way up to the week before release, and there were many conversations still being modified. It was worth it…the downside was that the translation companies and voice recording companies were going bananas.”

– Larian Studios founder Sven Vincke, speaking to PCGamer about the development of Divinity: Original Sin 2.

Larian seemed to hit it out of the park last year with the release of Divinity: Original Sin 2, the well-received sequel to its 2014 tactical RPG Divinity: Original Sin. 

Now, an interesting postmortem feature on the game published by PCGamer sheds light on some of the bumps along the way to Original Sin 2, with devs on the project talking frankly about challenges they faced in overhauling the game’s combat and dialogue systems — even as the studio more than tripled in size.

“Original Sin 2 was the first time where we had sufficient resources to do everything well, and even then we had to scramble,” studio founder Sven Vincke told PCGamer. “We rewrote the game all the way up to the week before release, and there were many conversations still being modified.”

Vincke and other members of the dev team focus on two major efforts in this postmortem: the prototyping and playtesting of a “spicy” Original Sin 2 combat system, and the attempt to revamp the game’s writing with both new dev tools and a bunch of new writers, some of whom had never written for games before.

This seems to have paid off, judging by critical acclaim for the game’s (optional) pre-written “origin” characters and storylines, but it sounds like the extra effort left some on the team feeling a bit burnt out.

“The one thing I don’t want to do again is to write two of them,” said writing director Jan Van Dosselaer. “I wrote Red Prince and Sebille, and I love both characters, but especially near the end it got schizophrenic writing the two of them at a very quick pace. I’d prefer to have just one baby to focus on. You have a lot of these conversations where the characters reflect on things, and I brought all of these conversations together and just spent days writing all the observations of all the characters, working like a machine.”

Notably, these efforts seem to have been aided by an overhaul of the dev team’s dialog toolset, affording them more room to write and design natural-sounding conversations.

“One of the major downsides of Original Sin was that the tool wasn’t dialogue-friendly. You could tell it had limits that made it a lot more difficult to mimic actual conversation, which is why you have parts where you just get to ask a question and then read a block of text,” added Van Dosselaer. “With the new tool we can really recreate proper conversations with banter and a good back and forth. If you look behind the scenes at what dialogue looks like in the editor, then sometimes it’s huge, with all these branches that you’ll never see. It creates all these unique experiences. It’s a lot broader because of that.”

For more interesting insight into the game’s development, do check out the full article over on PCGamer’s website. If you enjoy the bits about how the team dialed in Original Sin 2‘s combat to be interesting and threatening in equal measure, consider checking out Gamasutra’s recent feature on how Larian tuned it for drama.

Now that Rare’s Sea of Thieves has finally launched, the game’s provoked a discussion among its community, game developers, and press about what exactly a game needs in order to be “fun.” Does it need a strong progression loop? Clearly defined objectives? An interface that guides you through every step of the experience? Sea of Thieves lacks all of these things, and yet it’s such a fascinating, delightful experiment to emerge with the backing of a large company like Microsoft. 

To flaunt our feelings about Sea of Thieves, we took to the high seas earlier today on the Gamasutra Twitch channel for a discussion about the game while putting it through its paces. Thankfully, you don’t even have to wait that long to see us get utterly stomped by a band of rowdy teenagers, who according to editor Alex Wawro, ‘very cold-bloodedly [walked] through like “yeah we got em, no they had no treasure, yeah we could do it faster next time.'”

You can watch our full adventure up above, and if you’re looking for more gameplay commentary and developer interviews from Gamasutra, be sure to follow our Twitch channel.

When going back to replay classic games I played as a kid to mine them for knowledge, I always fear that any games from the NES era or earlier are too old to learn much from.

I tend to assume that many elements of modern design will be missing: no training, bad difficulty ramping, haphazard level design, and so forth. Before writing this article, I was under the impression that many “good design principles” I’ve come to know and love were invented during the SNES era and iterated on from there.

The NES was the Wild West of game development, I thought, lawless and free.

So when I went back on Link’s 25th anniversary to play the first Zelda game and maybe write an article about it, I was a bit gun-shy.

As it turns out, I was totally wrong! Instead of finding something outdated with a ton of nostalgia value, I found an excellent primer in the fundamentals of non-linear game design.

In an interview, creator Shigeru Miyamoto once said that with The Legend of Zelda, he wanted to evoke the feelings associated with exploration in the player:

“When I was a child,” Miyamoto said, “I went hiking and found a lake. It was quite a surprise for me to stumble upon it. When I traveled around the country without a map, trying to find my way, stumbling on amazing things as I went, I realized how it felt to go on an adventure like this.” – via Wikipedia

To achieve this feeling, Miyamoto and company invented a number of really clever tricks to create non-linear levels that are still useful today.

I can still hear the music in my dreams… MY DREAMS!

While going through The Legend of Zelda, I played each level and then did an in-depth analysis of the level on paper. This kind of analysis is pretty standard fare; I do it all the time on colleagues’ level designs. There are a few things I’m always looking for:

• Level Flow. How do the spaces in the level fit together? Where is the player supposed to go, and will she know how to get there?
• Intensity Ramping. Does the intensity of the experience ramp up in a satisfying way? Do monsters get more difficult as the level goes on? Does the player get a chance to learn how the enemies work and then display her mastery later on?
• Variety. Is there sufficient variety in the gameplay? Do enemy encounters frequently repeat themselves? Are the spaces varied in interesting ways?
• Training. If the design requires new skills from the player, does it teach and test those skills appropriately?

In this article, I’ll apply the same methodology to the first level from the original Legend of Zelda. Fortunately, this is made easier by the fact that top-down maps of the level designs are easily and readily available. I’m only going to cover the first dungeon in this article, but the principles apply to all of them.

If you’d like to check them out yourself, you can find the maps I used here: Mike’s RPG Center. (By the way, Mike is awesome and gave me permission to use his maps in this article. Thanks, Mike.)

Breakdown

Based on my memories of the game, one of my assumptions going into this experiment was that the rooms in the dungeons were laid out haphazardly. I always remember getting the feeling that I was navigating my way through the rooms almost randomly, spitting in the designers’ faces and getting to the end only because of my mighty gaming talents!

After analyzing the flow of the dungeons, I quickly abandoned this notion. As it turns out, the dungeon layouts are very carefully planned and the flow is very cleverly executed.

First, I analyzed the critical path. The critical path is the shortest path through a level without using secrets, shortcuts, or cheats. Basically, it’s the path the designer intends the player to take through the level unless she gets really clever.

It’s worth noting that the critical path often doesn’t require a player to complete 100 percent of a level; it just requires her to complete the mandatory objectives within the level.

For each of the dungeons, the critical path is almost always linear. There are very few instances where the player is required to re-traverse ground she’s already seen. The only exception to the linearity rule tends to be two or three rooms at the beginning of the dungeons that allow you to choose between a small subset of rooms.

The player begins in Room 1 and can choose to go to Room 2 or Room 3. Rooms off the critical path are faded (click for full size).

Optional rooms (and sometimes entire paths) branch off from the critical path and reward the player with bonuses. The levels are also full of shortcuts that cut across the critical path. If the player has bombs, for example, she can skip from Room 5 to Room 8 in the above diagram.

The Gamasutra Job Board is the most diverse, active and established board of its kind for the video game industry!

Here is just one of the many, many positions being advertised right now.

Location: Agoura Hills, California

Visual Concepts is one of the world’s top game development studios with a flat, entrepreneurial, and non-corporate work environment. We have a proven track record having shipped over 100 multi-SKU titles to great critical acclaim.

Our studios in Agoura Hills, CA and Novato, CA are committed to gaming and technical innovation and offer top candidates the opportunity to learn and grow with some of the smartest and most creative minds in the industry.

We’re seeking an experienced Senior Software Engineer, focused on tools development. 

You’re passionate about developing deep, high quality interactive tools used by all disciplines of game development for the creation, visualization, integration, release and testing of game content.  You will develop next generation tools and engines, with a focus on the interactive layer of the two.  You’re experienced creating Windows-based tools used in game development including data/asset management, creation frameworks, and user interface.

You’ll build tools that meet production demands and ensure efficiency and creative opportunity for all members of the development team. You’ll create graphical user interfaces and associated tools that enable the team to intuitively work with various assets and content.

Requirements:

• 3+ years of experience in tools development for console games
• High proficiency in C / C++ / C#
• Fluent in Windows-based development (.Net, etc.)
• Deep understanding of object-oriented programming
• Able to diagnose and solve problems quickly and independently
• Able to learn and master complicated code systems
• Able to write clean, bug-free, well-documented and efficient code
• Bachelor’s or Master’s Degree in Computer Science
• Passion for video games
• Good team player

Additional Skills:

• Experience with web development (HTML, Python, etc.)
• Experience with designing user-friendly UI
• Knowledge of Maya/Max is a preferred plus

Interested? Apply now.

Whether you’re just starting out, looking for something new, or just seeing what’s out there, the Gamasutra Job Board is the place where game developers move ahead in their careers.

Gamasutra’s Job Board is the most diverse, most active, and most established board of its kind in the video game industry, serving companies of all sizes, from indie to triple-A.

Looking for a new job? Get started here. Are you a recruiter looking for talent? Post jobs here.

The video game hardware company Razer has opened up a new online shop to handle the sale of digital games on PC.

The Razer Game Store isn’t an entirely new platform. Instead, the company is selling keys for existing platforms like Steam and Uplay, sometimes with ‘Razer exclusive’ discounts, and letting customers count those purchases toward Razer’s existing loyalty program in the process.

With enough points, that program will turn back around and offer discounts and other perks to players that regularly use the storefront to pick up digital copies of games.

Razer takes special care to note that the keys being sold through its platform are legitimate and obtained through partnerships with developers and publishers,  likely to avoid the reputation some online key retailers have for obtaining game keys through unscrupulous methods.

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

---

This post was originally published on @Ryan_Darcey‘s blog, Making Moves.

DISCLAIMER:  Nothing in this post reflects what 343 Industries thinks or what the future holds for Halo.  This is all from my own dumb brain and I have no idea what 343 Industries is currently up to.  Lastly, I have the utmost respect for everyone that works there and I’m excited to see what they release next!

---

I blogged a while ago about working at Terminal Reality and LucasArts, but have held off on writing about my experience at 343 Industries (343i) until I’ve had some more time away from the studio.  I just hit my 2 year indie anniversary and it feels like there’s enough space between working on Halo and the present moment in order to judge it fairly.  My three years at 343i was a period of growth, but by way of some difficult lessons learned.  I now know a lot more about what I need to satisfy the game dev inside of me and how important it is to find a studio that’s a culture fit (with no one culture being inherently better or worse).

Let’s start with something easier first, though.

At least that’s what I think Seattle wants you to believe in order to keep its growth under control.  It’s absolutely beautiful here, the summers pay off in dividends and the video game industry is very much alive and well.  I most recently moved from San Francisco where the development scene has been hit hard w/ closures and layoffs over the past few years.  As much as I love the Bay Area, I think it’d be hard to move back and find what I’m currently looking for in my life or career…let alone find an apartment.

That said, Seattle is having its own growing pains and there’s much to lament with regard to diversity (or lack there of), but from a video game development stand point I feel like I’m at the epicenter of where all the interesting things are happening.  Especially being a part of the indie scene.  So many AAA devs have left big studios in the area and are starting up exciting projects.  It’s encouraging and it makes the dream seem possible, though I know we’re not all going to make it.

Anyway…that’s my quick love letter to Seattle.  343i brought me up here and that alone made a kind of scary move worth it.

But seriously.  Don’t move here.  It’s terrible.

Halo is one of my all time favorite franchises and the impact it’s had on my career is difficult to quantify.  The controls, the joust, the 30 seconds of fun, the sandbox, the precision tuning, the console multiplayer…the CHIEF!  As a gamer, these things all had a huge impact on my appetite for play.  As a developer, they set a high bar for what I might achieve one day.  For those reasons, I came into 343i with a lot of excitement, but along with that was a healthy dose of trepidation.

When Halo 3 came out, I remember sitting in the matchmaking lobby chatting w/ some other game dev friends and saying “I don’t ever want to work on a Halo game.”  At the time, I thought, “How the hell am I going to make this better?”  Also, I felt like it was going to be difficult for a franchise that established to evolve in significant ways…cause then it probably wouldn’t be Halo anymore.  Turns out, I think this is a real problem for any massively successful franchise over time.  Striking that balance between innovation and staying true to your roots is crazy difficult.

As a developer trying to tackle this problem, you also have to be ready for The Internet.  Here’s a sample of some comments from my 2016 GDC talk about designing Spartan Abilities for Halo 5: Guardians.

• “Here it is, the man who killed the golden gameplay of halo.”
• “RIP Halo.”
• “343 ruined halo.”

This one (among others) actually got removed after I made a joke on Twitter about it.  The screenshot still lives on in my account.  It’s only the tip of this persons rant iceberg.

I don’t need to drone on about how toxic the gaming culture can be.  We all understand how The Internet has both elevated and devolved society.  The examples are endless and reach far beyond our little gaming corner…but, the resentful, hateful view that fans impose on the regular people making their favorite games is pretty kinda bonkers.  My totally unscientific explanation is that the competitive aspect of most games brings out this weird desire to not just win the game, but also win the meta game w/ the developer by being smarter than them.  Or something like that.  I don’t know.  Humans can be dark creatures and other areas of entertainment suffer similar slings and arrows.

Personally, I really enjoy what Spartan Abilities have added to the mix (surprise!), but can’t say for sure that this contribution to Halo was for the best.  Either way, I think it’s clear that established franchises face a very, very difficult problem around choosing where to innovate.  I discuss some ways we approached it for Halo 5: Guardians in my GDC talk, but I’m not going speculate as to what the next best move would be for 343i.  I would love to see some bigger changes, but many other people wouldn’t.  I just want a God of War style 3rd person Spartan brawler spin off.  It’s nice to want things 🙂

But to take a few steps back for a second…if I thought Halo’s success presented big enough problems for me to say that I never wanted to work on it at one point, what changed my mind?

Tim Longo and Chris King.  That’s why I moved up to Seattle to work on Halo.  Tim was our Creative Director on Star Wars: First Assault (SW: FA) and he’s one of my favorite people in the industry.  When he took the Creative Director position up at 343i, that totally changed how I thought about working on the franchise.  Then, to seal the deal, when I interviewed w/ Chris King I knew I would learn a lot working with him (SPOILER: I was right about that).  He reminded me a lot of Ed Kay, my previous design manager on SW: FA and still mentor.  They both have this insane ability to see the space between frames and determine exactly where problems lie, among other very desirable game designer attributes.  They all rolled 20s across the board.

So, I ultimately walked through the door at 343i w/ a lot of optimism for the future.  A big part of that optimism was, “OMG I can’t wait to implement all the amazing processes we had on SW: FA.  Should be SO easy with Tim near the top!”  That. Was. Not. True.  343 Industries is not a 50 person team.  I came in pushing pretty hard for changes to how we planned our work, ran morning stand ups, processed playtest feedback, etc.  Hindsight being 20/20, I pretty much set myself up to fail as soon as I opened my mouth by not recognizing how different this environment was.  I was coming off a career high working with the SW: FA team and was crazy overzealous about trying to help foster the same culture at 343i.  I was trying to square peg a round hole (without placing any judgement on which is the better shape).

The reality is, turns out I don’t really like working for large teams much at this point in my career.  In addition to all the inherent problems to solve around efficiency, it’s difficult for someone like me who enjoys to design, code and influence production processes to really scratch all those itches.  Large teams tend to be a lot more specialized.  That’s just the way it goes.  I was pretty brash about fighting to get code access so I could prototype my designs at 343i.  It really cost me in the end, as I failed to recognize the precarious position I was putting myself and others in.  Eventually, I was granted code access, but then it was taken away.  The reasons for all that are complicated and I’m sure I don’t fully understand them myself.  Either way, the result made me pretty bummed because generally speaking we’re most happy when we’re realizing our full potential.  It’s arguable whether or not I was actually capable of giving more to Halo, but I was left wanting to.

Ultimately, the team size, the focus on specialization and the challenges around navigating Halo’s legacy left me w/ an extremely strong desire to make a stupidly ambitious (still unannounced) game on my own.  So, that’s what I set out to do in the Spring of 2016.  Also, for the record, I’m totally happy to admit those difficulties that I faced at 343i may be the result of my own shortcomings as a developer.

Prior to shipping Halo 5: Guardians, I don’t think I had all the skills required to execute on a level that matched my indie ambitions.  I mean, maybe I still don’t, but I’m definitely much closer having had that experience.  Specifically, the degree to which I was exposed to folks w/ great design sensibilities has had a big impact on me.  I don’t think I’m a natural designer, but I’m a good learner!  Which means I need to surround myself by more talented people in order to grow.  No shortage of them around 343i.  They are stacked w/ amazing developers across the board.  Many “best in their field” types of folks.  That’s one huge advantage to working on a team like that.

So, that’s part 3 of my game dev story.  I remain hopeful that the 4th installment will inject some new highs into my career, but expectations are sufficiently in check -_-  The indie scene is bonkers these days, but I’m dumb enough to think I still might have a chance  ¯\_(ツ)_/¯

It’s been a few weeks since we’ve been able to go live on the Gamasutra Twitch channel. Between GDC and the post-show recovery, we’ve been eager to go live for a couple of weeks. So today, we’re going to be enjoying a nice, casual stream of Sea of Thieves starting at 3PM EDT. 

While we’re still waiting to see if we can get the folks from Rare on, Sea of Thieves is such a unique and compelling experience we wanted to make sure we could discuss it and what impact it might have on the game design world. If you’ve been venturing out on the high seas yourself, come join us and share your thoughts! 

And while you’re at it, be sure to follow the Gamasutra Twitch channel for more developer interviews, editor roundtables and gameplay commentary. 

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

---

A Useful Snippet:

A lot of game developers will instantly recognize this line of code:

value = lerp(value, targetValue, 0.1)

It’s super useful, and can be used for all sorts of things. With a higher constant, it’s a good way to smooth out jittery input from a mouse or joystick. With a low constant, it’s a nice way to smoothly animate a progress bar or a camera following a player. It will never overshoot the target value even if it’s changing, and it changes the speed based on how far away it is so it will always quickly converge on the target. Pretty good for a one liner!

BUT!

Unfortunately it has a couple problems that are often ignored to some extent:

The first is that it’s highly dependent on frame rate. The common advice is to use a fixed time step, but that’s not great advice. If it’s for player or camera animation, you will likely end up with visible jitters. If you change your fixed time step, you need to retune.

The second is that the lerp() constant that you need to use is relatively hard to tune. It’s not uncommon to start adding some extra 0’s or 9’s to the front of the lerp() constant to get the desired smoothing amount. Assuming 60 fps, if you want to move halfway towards an object in a second you need to use a lerp() constant of 0.0115. To move halfway in a minute, you need to use 0.000193. On the other end of the spectrum if you use a lerp() constant of 0.9 you will run out of 32 floating point precision within 7 frames, and it will be exactly at the target value. That is insanely sensitive to hand tune with a UI slider, or even a hand typed value.

Fortunately, with a little math, both issues are easy to fix!

Improved Version:

The key is to replace the simple lerp() constant with an exponential function that involves time. The choice of exp2() is arbitrary. Any base will work fine, you’ll just end up with a different rate value.

value = lerp(target, value, exp2(-rate*deltaTime))

In this version, rate controls how quickly the value converges on the target. With a rate of 1.0, the value will move halfway to the target each second. If you double the rate, the value will move in twice as fast. If you halve the rate, it will move in half as fast. This is much more intuitive.

Even better, it’s frame rate independent. If you lerp() this way 60 times with a delta time of 1/60 s, it will be the same result as 30 times with 1/30 s, or once with 1 s. No fixed time step is needed, or the jittery movement it causes.

If you are worried about the performance, don’t be. Even mobile CPUs have instructions to help calculate exponents and logarithms in a few CPU cycles. In 2018, you should be much more worried about cache misses than math lib costs, but that’s a post for another day.

Conversion:

So this new version is frame rate independent, and easier to tune. How do you convert your old lerp() statements into the new ones without changing the smoothing coefficients that already work  well at 60 fps? Math to the rescue again. The following formula will can convert them: (Note: Make sure to change the log base if you didn’t use exp2())

rate = -fps*log2(1 - coef)

Recalculate them and don’t look back!

Going Further:

Adjusting the numbers by hand is much easier now, but it’s still not slider friendly. Negative rates cause the math to blow up, and slowing the rate down will be very sensitive. Just add more exponents!

rate = exp2(logRate)
value = lerp(target, value, exp2(-rate*deltaTime))

This will make sliders more intuitive. Moving the slider a certain amount will always change the rate by the same fraction, and you can precompute rate if you want.

Why Does It Work?

Say you are lerping by 0.9 each frame. That means you are leaving (1 - 0.9) = 0.1 = 10% of the remaining value. After 2 frames, there will be (1 - 0.9)*(1 - 0.9) = 0.01 = 1% of the remaining value. After 3, (1 - 0.9)*(1 - 0.9)*(1 - 0.9) = 0.001 = 0.1%. After n frames you’ll have (1 - 0.9)^n of the remaining value. In graph form:

So really all you are doing by repeatedly lerping is evaluating an exponential curve, and that’s why you can replace it with an actual exponential curve based on time.

As an interesting aside, since you are moving partway towards the targe value each frame, you’ll never actually arrive at the target… or will you? float can store ~7 significant digits, and double ~16. Here’s a quick snippet of Ruby code to test what happens:

value = 0.0
target = 1.0
alpha = 0.9
100.times do|i|
  value = (1 - alpha)*value + alpha*target
  puts "#{i + 1}: #{value == target}"
end

And the output?

1: false
2: false
... (more false values)
15: false
16: false
17: true

It shouldn’t be too surprising that precision runs out after the 16th iteration. (1 - 0.9)^17 is quite small. 1e-18 to be exact. That is so small, that in order to store 1 - 1e-17 you would need 18 significant digits, and doubles can only store 16! More interestingly, no matter what your starting and ending values are, it will always run out of precision after 16 iterations. Most game engines use floats instead of doubles, and those can only store ~7 significant digits. So you should expect precision to run out after only the 7th iteration. What about for other constants? (Keep in mind I’m using doubles, and floats would run out in half as many iterations.) For 0.8 you run out of precision after 23 iterations, 53 for 0.5.

With constants less than 0.5 the pattern changes and something curious happens. Say you keep lerping with a constant of 0.5. Eventually, you will run out of precision and the next possible floating point number after value will be target. When you try to find the new value half way between, it will cause it to round up to target instead. If you use a constant smaller than 0.5, it will round down to value. So instead of arriving at target, it will get permanently stuck at the floating point number immediately before it. For a constant of 0.4, the value gets stuck at 70 iterations, or 332 for 0.1.