Apotheosis - Recent Challenges And Possible Solutions

I have been testing Apotheosis quite a bit lately, and on a coarse grained scale, I think it's going pretty well. The structure of the game works and has improved with iteration, and the game action is fun (for me at least). One of my regular testers doesn't seem to love it (I don't think it's really his type of game), but the others still seem to enjoy it.

But games don't get finished on a "coarse grained scale." At least, they shouldn't! When talking about some of the finer details of the game, there are some challenges I'm still facing with it. Until these challenges are overcome, I cannot call the game finished. However I do think these challenges are overcome-able! Here are some of the bigger challenges I'm currently facing, and what I'm planning to try to do about them:

Challenge number 1: The Endgame

One of the biggest problems this game has been facing is an end game dynamic that is disappointing. The game is basically a race up some tracks, and players can see how many turns it will take them to "finish" the race, and can sometimes tell whether anybody can stop them. It's super anticlimactic to hear your opponent say "I can win in 6 turns. Can anybody do better than that, or should we just stop now?"

In an effort to keep this from happening, I was looking for a way to add uncertainty to the end game. I thought I had found something, but in my first attempt I implemented it wrong so it didn't work. But after trying it, I started to think it wouldn't be quite right even if implemented better.

My next attempt was a more subtle thing, which won't stop a player from figuring out how many turns it'll take them to "finish," but might obfuscate whether or not someone else can beat them to it (thereby keeping the game interesting enough to play out the last few rounds):

1. Give players a face-down adventure which they could do instead of one of the face-up ones. This way you can't be sure whether your opponent can advance on a track, or what they need to be able to do so.
2. Try player screens to hide resources, so it's harder to tell what your opponents can do.
3. With player screens, maybe add more instances of getting things at random (resource cubes, equipment, Side Quest cards, etc) so that it's not all Hidden Trackable Information (HTI). There are already random equipment draws currently, and we could easily hide the Side Quests in hand, maybe that's enough.

In addition, we required a Tier 3 adventure to actually win the game. That way the final push to win couldn't be sort of cheesed with a surprise bump from a side quest (because that's kind of anticlimactic), or using the worker space that inefficiently moves you up a track (because that's not only anticlimactic, but also basically unblockable, which means you can see it coming several turns ahead, leading to the problem I'm looking to solve)

Having tried this format once so far, I think it has helped a little bit, but may not have completely solved the problem.

One thing that occurred to me as I was thinking about this challenge is that there are games -- popular, well received games -- that have a similar dynamic. Just about every time I played the 2014 title Istanbul, by Rudiger Dorn, I was able to see that I could "finish" the race to 5 gems in 4 or 5 turns, and often I could see whether or not anybody could stop me or beat me to it. That made the last 4 turns or so feel like something of a slog, but the game hasn't seemed to suffer from it.

So maybe I'm overly concerned about this "problem" in my game. I think if you can call the game in 4 turns or so, it wouldn't be so bad, but 6-8 turns out i maybe too much. So maybe I don't need to solve the problem 100%, but rather make sure that if it DOES happen, it only happens within 4-5 turns of the end of the game.

Challenge number 2: Equipment not pulling its weight

Equipment in this game is basically a secondary resource, a little harder to get, and useful mostly for one particular aspect (an aspect that players could mostly neglect if they wanted to, but theoretically is more efficient if they don't). I think Equipment is nice thematically, but the mechanisms for getting it are a bit overblown and maybe too random for the relatively small role they play.

One solution is to cut Equipment altogether, reducing the number of resources (by 4, technically, since there are 4 types of equipment). Some of my testers seem to think there are too many resources in the game, and cutting equipment would certainly help that. But I fear that would just mean you use the stuff you're already collecting to pay for the valuable stuff Equipment was supposed to buy you, which seems lame to me.

Another solution is to make Equipment a bigger deal in the game. My first attempt at this, partly to try and salvage Equipment, and partly because removing it would mean I'd need to do more updating to the prototype and design work before testing again (and I had other things to test), had to do with the attempt mentioned above to add some uncertainty to the end game. That may work in some format, but having tried it, I'm not sure I like it as much as I'd hoped.

My next attempt was to add Equipment as a cost for the 3rd adventure tier. The 3rd tier requires a few worker levels of any type in addition to what's needed for tier 2, and currently has no additional resource cost (but I think it should). The rewards are a handful of Blessings (which are a flexible commodity), and a track bump (vp) of your choice. Originally, instead of Blessings, the reward was a Spoils -- a special resource you need to do a certain thing (it's kind of like 2 points and a power). The only other way to get those is by (a) Side Quest cards, which cost Equipment, or (b) spending a large number of blessings (which is hopefully inefficient by comparison). So maybe putting the reward back to a Spoils instead of Blessings (which is kind of thematic anyway), and adding an Equipment cost, then it makes some sense: Equipment is always for getting Spoils -- if you do it through an Adventure, then you also get VP, if you do it through a Side Quest, then you maybe get something else with it.

In addition, I added some worker placement spaces that care only about your worker's class (that was partly to address some other issue I was worried about), and one of them lets you get Equipment, so now there are a few ways to get equipment, and a few ways to spend it. Since you can't always guarantee you get the TYPE of equipment you want, I also added the option at one of the worker spots to trade in any 2 equipment for the one you want.

So far I think this is promising, so I'll try it again. I'm sure those same playtesters will still complain there are too many different resources :)

Related to Spoils, it might be nice if  there were 1 more thing you could do with it. Because currently you only need a maximum of 4 or 5 in the game, and you can technically finish (though I don't know if you could realistically win) with only 1. I don't know if I like being able to buy them with Blessings, because that means you can avoid dealing with Equipment altogether. Is that OK?

Star Wars Jedi Fallen Order Free Download

A galaxy-spanning adventure awaits in Star Wars Jedi: Fallen Order, a new third-person action-adventure title from Respawn Entertainment. This narratively driven, single-player game puts you in the role of a Jedi Padawan who narrowly escaped the purge of Order 66 following the events of Episode 3: Revenge of the Sith. On a quest to rebuild the Jedi Order, you must pick up the pieces of your shattered past to complete your training, develop new powerful Force abilities and master the art of the iconic lightsaber – all while staying one step ahead of the Empire and its deadly Inquisitors.

While mastering your abilities, players will engage in cinematically charged lightsaber and Force combat designed to deliver the kind of intense Star Wars lightsaber battles as seen in the films. Players will need to approach enemies strategically, sizing up strengths and weaknesses while cleverly utilizing your Jedi training to overcome your opponents and solve the mysteries that lay in your path.

Star Wars fans will recognize iconic locations, weapons, gear and enemies while also meeting a roster of fresh characters, locations, creatures, droids and adversaries new to Star Wars. As part of this authentic Star Wars story, fans will delve into a galaxy recently seized by the Empire. As a Jedi hero-turned-fugitive, players will need to fight for survival while exploring the mysteries of a long-extinct civilization all in an effort to rebuild the remnants of the Jedi Order as the Empire seeks to erase the Jedi completely.

GAMEPLAY AND SCREENSHOTS :

 
 
 
 

DOWNLOAD GAME:

♢ Click or choose only one button below to download this game.
♢ View detailed instructions for downloading and installing the game here.
♢ Use 7-Zip to extract RAR, ZIP and ISO files. Install PowerISO to mount ISO files.

Star Wars Jedi Fallen Order Free Download

INSTRUCTIONS FOR THIS GAME

➤ Download the game by clicking on the button link provided above.

➤ Download the game on the host site and turn off your Antivirus or Windows Defender to avoid errors.

➤ Once the download has been finished or completed, locate or go to that file.

➤ To open .iso file, use PowerISO and run the setup as admin then install the game on your PC.

➤ Once the installation process is complete, run the game's exe as admin and you can now play the game.

➤ Congratulations! You can now play this game for free on your PC.

➤ Note: If you like this video game, please buy it and support the developers of this game.

SYSTEM REQUIREMENTS:
(Your PC must at least have the equivalent or higher specs in order to run this game.)

Minimum:
• Requires a 64-bit processor and operating system
• OS: 64-bit Windows 7/8.1/10
• Processor: AMD FX-6100/Intel i3-3220 or Equivalent
• Memory: 8 GB RAM
• Graphics: AMD Radeon HD 7750, NVIDIA GeForce GTX 650 or Equivalent
• DirectX: Version 11
• Storage: 55 GB available space

Recommended:
• Requires a 64-bit processor and operating system
• OS: 64-bit Windows 7/8.1/10
• Processor: AMD Ryzen 7 1700/Intel i7-6700K or Equivalent
• Memory: 16 GB RAM
• Graphics: AMD RX Vega 56, Nvidia GTX 1070/GTX1660Ti or Equivalent
• DirectX: Version 11
• Storage: 55 GB available space

Supported Language: English, French, Italian, German, Spanish language are available.
If you have any questions or encountered broken links, please do not hesitate to comment below. :D

Suzy Cube Update: May 25, 2018

#SuzyCube #gamedev #indiedev #madewithunity @NoodlecakeGames 

My apologies! The day just flew right by and I only realized I forgot to write an update about three hour ago! Another packed week, but mostly bug fixes, so let's dive in!

Read more »

Louard's game design sounding board and home of the Pro's and Con's reviews.

Tech Book Face Off: CoffeeScript Vs. Simplifying JavaScript

I really like this setup for a Tech Book Face Off because it's implicitly asking the question of what can be done to improve the quagmire that is the JavaScript language. Should we try to simplify things and pare down what we use in the language to make it more manageable, or should we ditch it and switch to a language with better syntax that transpiles into JavaScript? For the latter option, I picked one of the few books on the CoffeeScript language, aptly named CoffeeScript: Accelerated JavaScript Development by Trevor Burnham. Then, for sticking with JavaScript, I went with a recently published book by Joe Morgan titled Simplifying JavaScript: Writing Modern JavaScript with ES5, ES6, and Beyond. It should be interesting to see what can be done to make JavaScript more palatable.

VS.

CoffeeScript

This book was written a few years ago now, in early 2015, but CoffeeScript is still alive and kicking, especially for Ruby on Rails developers as the default front-end language of choice. CoffeeScript is integrated into Rails' asset pipeline, so it gets automatically transpiled to JavaScript and minified as part of the production release process. If you're already comfortable with JavaScript, and even more so if you know Ruby, then CoffeeScript is a breeze to learn.

The ease with which this language can be picked up is exemplified by the book, since it's one of the shortest books I've ever read on a programming language. Over half of the book has more to do with examples, applications, and other stuff tangential to CoffeeScript, rather than the language proper. The book itself is just short of 100 pages while the content on syntax and usage of the language is condensed into the first half of the book.

As all books like this do, the first chapter starts out with how to install the language and configure the environment. It's pretty straightforward stuff. Then, we get into all of the syntax changes that CoffeeScript brings to JavaScript, which essentially defines the language since all of the features are the same as JavaScript's. Chapter 2 shows how function and variable declarations are different, and much shorter. Chapter 3 demonstrates some nice syntactical sugar for arrays in the form of ranges, and iteration can be done more flexibly with for comprehensions. Chapter 4 gets into the syntax features for defining classes and doing inheritance concisely.

Most of the syntax will look quite familiar to Rubyists, including class instance variables denoted with an '@' prefix, the string interpolation notation, unless conditionals, and array ranges. Here's an example from the book showing a number of the syntax features:

class Tribble
  constructor: ->      # class constructor definition
    @isAlive = true    # instance variable definition
    Tribble.count += 1 # class variable access
  
  breed: -> new Tribble if @isAlive
  die: ->
    return unless @isAlive
    Tribble.count -= 1
    @isAlive = false

  @count: 0            # class variable (property)
  @makeTrouble: -> console.log ('Trouble!' for i in [1..@count]).join(' ')

This code would be about twice as many lines in JavaScript, so the compression is pretty great and the code is much cleaner and easier to understand. Burnham proclaims these virtues of CoffeeScript early on in the book:

Shorter code is easier to read, easier to write, and, perhaps most critically, easier to change. Gigantic heaps of code tend to lumber along, as any significant modifications require a Herculean effort. But bite-sized pieces of code can be revamped in a few swift keystrokes, encouraging a more agile, iterative development style.

Maybe that's stated a bit more strongly than is warranted, but it's still hard to argue with the improved simplicity and cleanliness of CoffeeScript making developers' lives more pleasant.

The last three chapters of the book delve into different frameworks and packages in the JavaScript universe that can be used with CoffeeScript, and the vehicle for exploring these things is a (heavily) stripped  down version of the Trello app. Chapter 5 goes through how to create the front-end portion of the app with jQuery and Backbone.js. Chapter 6 adds a backend server for the app with Node and Express. Chapter 7 explores how to test the app with Intern. All of the code for the front-end, backend, and tests is written in CoffeeScript, and the transpiling is setup to be managed with Grunt. It's nice to see multiple different examples of how to use CoffeeScript anywhere that JavaScript would normally be used, just to get an idea of how to transition to CoffeeScript in multiple ways.

Throughout the book, Burnham presents everything in a straightforward, no-frills manner. Everything is clear and logical, and his concise descriptions are part of the reason the book is so short. He assumes you already know JavaScript—which is much appreciated—and he doesn't go into extended explanations of JavaScripts features. It's just the facts on how CoffeeScript is different and what the syntax is for the features it compresses. It's awfully hard for me not to recommend this book simply because it's so short and to the point. It only took a few hours to read through, and now I know a better way to code JavaScript. There's not much more I can ask of a programming language book.

Simplifying JavaScript

Every language has those more advanced books that assume you already know the language and instead of covering the basics and syntax, it provides advice on how to write idiomatically in the language. I've read these books for C++, Ruby, and JavaScript and found them to be surprisingly enjoyable to read. That was not the case with this book, but before I get too far into criticisms, I should summarize what this book does well.

Simplifying JavaScript is organized into ten chapters with each chapter broken into a set of tips that total 51 tips in all. These tips each explain one new feature of the JavaScript language from the new ES5, ES6, and ES2017 specifications. Some features, like the spread operator take multiple tips to fully cover. Then, the last chapter covers some features of the JavaScript development environment, like npm, that are not part of the language and have been around a bit longer than these newer specifications.

Most of the new features significantly improve and simplify the language, and they include things like:

• new variable declaration keywords const and let
• string template literals, which look much like Ruby's string interpolation
• the spread operator ... for converting arrays to lists and converting lists of parameters to arrays
• the Map object
• the Set object
• new loop iterators such as map(), filter(), and reduce()
• default parameters
• object destructuring
• unnamed arrow functions
• partially applied functions and currying
• classes
• promises and async/await

The arrow functions, spread operator, loop iterators, and destructuring go a long way in making modern JavaScript much more pleasant to program in. All of these features—and likely more in the newest language specs—make CoffeeScript nearly irrelevant, and likely not worth the effort of going through the step of compiling to JavaScript. The language has really matured in the last few years!

Morgan does a nice job introducing and justifying the new features at times:

We spend so much time thinking and teaching complex concepts, but something as simple as variable declaration will affect your life and the lives of other developers in a much more significant way.

This is so true. The code we're reading and writing every day has hundreds of variable declarations and usages, and being able to indicate intent in those declarations makes code much cleaner and more understandable. Getting better at the fundamentals of the language and having these new declarations available so that the most common code is clear and purposeful will more significantly improve code than all of the complicated, esoteric features that only get used once in a blue moon.

These exciting new features and simple explanations were the good parts, so why did I end up not liking this book much? Mostly, it was because of how long-winded the explanations were. Each tip dragged on for what felt like twice as long as it needed to, and the book could have easily been half as long. CoffeeScript showed how to present language features in a clear, concise way. This book took the opposite approach. Then, to make matters worse, it was written in the second person with the author always referring directly to the reader with you this and you that. Normally I don't mind a few references to you, the reader, every now and then, but this was constant so it became constantly aggravating.

Beyond the writing style, some of the justifications for various features didn't hold much water. For example, when trying to rationalize the new variable declarations, Morgan presented an example of code where the variables are declared at the top, and then there are a hundred lines of code before those variables are used again. Then he says, "Ignore the fact that a block of code shouldn't be 100 lines long; you have a large amount of code where lots of changes are occurring." I don't know about you, but I wouldn't declare a variable and then not use it for a hundred lines. I would declare it right before use. He shouldn't have to contrive a bad example like that to justify the new const and let declarations. The improved ability to relate intent in the code should be reason enough.

In another example for why one must be careful when testing for truthy values in a conditional, he shows some code that would fail because a value of 0 is falsey:

const sections = ['shipping'];

function displayShipping(sections) {
  if (sections.indexOf('shipping')) {
    return true;
  } else {
    return false;
  }
}

Ignoring the fact that I just cringe at code like this that returns a boolean value that should be computed directly instead of selected through an if statement, (don't worry, he corrects that later) there is much more wrong with this code than just the fact that an index of 0 will incorrectly hit the else branch. In fact, that is the only case that hits the else branch. Whenever 'shipping' is missing from sections, indexOf() will return -1, which is truthy! This code is just totally broken, even for an example that's supposed to show a certain kind of bug, which it does almost by accident.

Other explanations were somewhat lacking in clarity. Late in the book, when things start to get complicated with promises, the explanations seem to get much more brief and gloss over how promises actually work mechanically and how the code executes. After having things explained in excruciating detail and in overly simplistic terms, I was surprised at how little explanation was given for promises. A step-by-step walk through of how the code runs when a promise executes would have been quite helpful in understanding that feature better. I figured it out, but through no fault of the book.

Overall, it was a disappointing read, and didn't at all live up to my expectations built up from similar books. The tone of the book was meant more for a beginner while the content was geared toward an intermediate to expert programmer. While learning about the new features of JavaScript was great, and there are plenty of new features to get excited about, there must be a better way to learn about them. At least it was a quick read, and refreshing my memory will be easy by skimming the titles of the tips. I wouldn't recommend Simplifying JavaScript to anyone looking to come up to speed on modern JavaScript. There are better options out there.

The Concept Of Tchekhov's Gun In Games

It is always interesting to create a cris-cross between literature and games. In fact, both worlds are intrinsically connected, and this is especially evident in games with narrative, characters, plot twists etc. I like to think about games as "ergodic literature" — an idea previously discussed in this post.

Here, in this short article, I would like to address the concept of Tchekhov's gun applied to games. Anton Tchekhov (1860–1904) was one of the most important voices in Russian literature. He developed the principle that states that every element in a story must be necessary, and irrelevant elements should be removed. Tchekov said that, if you say in the first act that there is a rifle hanging on the wall, in the second or the third act it must be fired. If the rifle isn't going to be used, it shouldn't be hanging there. The Russian author also said that one must never place a loaded rifle on the stage if it's not going to be fired. It's wrong to make promises you don't mean to keep.



What does this principle mean inside the gaming universe? As Tchekhov has postulated for literature, in games we also need to create a sense of order and to make sure every single element is relevant. If the scenery displays a highlighted symbol, it should have some function in that stage, like serving as a hint for a puzzle or as an object that the player must collect in order to defeat an enemy.

To further illustrate this, we can discuss a puzzle from the game Little Nightmares. In the scenery, there is a TV that can be turned on and a door that cannot be opened. But, previously, the player received a piece of information: in the other room there's a bizarre blind create that is attracted to sound. So, you must turn on the TV, get close to the door, and wait until the monster opens it, so that you can walk into the next room. Check the video below:



In this example, imagine if the TV was just a decoration, something useless in the puzzle flux. It would make no sense in the game and it would be contrary to the concept of Tchekhov's gun.

This is the point I wanted to make with this short article: everything must be interconnected and play a role in your game.

I'll talk more about the overlapping universes of literature and games in the next posts.

#GoGamers

People Of Frictional: Gregor Panič

WHO AM I?

Hi there! I'm Gregor and I'm a designer and programmer at Frictional, which means I'm responsible for all the fun events in our levels. Okay, maybe they're fun just for us.

It's me! And the sign on our door, printed on an A4 and a little crumpled...

I'm a more recent recruit, having joined around September 2016. My job description, gameplay programmer / designer, is purposefully vague. While I mainly work on level scripting, I also spend time on AI, gameplay systems and level design. I also worked on our collaboration with the Tobii Eye Tracker, which I will talk about later. The great part about this is that my work never gets stale and almost none of my days feel the same.

I'm originally from a little known country called Slovenia, but I've recently moved to the land of the vikings to become one myself. Or, in other words: I moved to Malmö around two months ago and now work from our fairly new office.

My setup at work - right next to the fanart wall! No deskmate yet, though. :'(

I absolutely adore our office and go there pretty much every day to socialize with and get inspired by my co-workers. I'm also the one who nags everyone with occasional movie and gaming nights, where we usually grab some snacks, relax and watch a horror movie (obviously), or games like FIFA and Jackbox Party Pack!

BACKGROUND

I can't really remember the time when I first started playing games. I do know that around the late 90s my dad brought home an Intel 80186 PC one day, thinking he would use it for work. He was wrong. After he showed me a couple of MS-DOS games and I realized I could make things move by pressing buttons, I became glued to that PC. My parents didn't manage to pry me from it, so I've been playing games ever since. Not on the same machine, obviously.

I played a lot of games, but didn't touch the horror genre for the longest time. I still remember having vivid nightmares and being unable to sleep whenever I saw something remotely scary on television. When I was older, however, a friend of mine bought me Amnesia as a "gift". It was a dare, of course, but because I didn't want to disappoint my friend, I played through it. It was just as scary as everyone was telling me, perhaps even more so.

But while I was playing it I also realized that it was about more than just scaring the living hell out of me. It managed to fully immerse me in its world and story, which I had not experienced to this degree before. This is how I got introduced to the horror genre, and to Frictional, which would later impact my life more than I could have possibly imagined.

Making games has been my dream ever since I can remember. Given how much fun I had playing them, I thought it would be great if I could make my own – which is why I always liked messing around with settings, seeing what I could do with cheat codes, and figuring out damage formulas so I could get an advantage. It wasn't until I got sucked into a game called Jedi Knight: Jedi Academy, however, that I actually made my first array into creating my own content. I made lightsaber hilts, maps, and even modified some scripts to make the game play like I wanted to.

Unfortunately, growing up in Slovenia there was no real game dev scene there, so I forgot about my dream. It simply never occured to me that I could make games for a living. However, since I was already using my computer so much, I thought it would be fun to work in IT. So I learned some basic C++ programming in high school, then went to a computer science university where I learned a lot more about programming and software in general.

For a long time I resigned myself to becoming a web developer, taking some summer jobs and part-time work in that field. The job became more and more mundane and boring, until I finally realized that I couldn't do it long term, and that I had to find something more fulfilling. That is when I remembered my dream of making games, how much fun they brought me and how great it would be to be able to help someone else have the same experience. I already had a lot of programming experience, so I became determined to join the games industry.

I immediately quit my part-time job and started working on my first small game. I wanted to do everything on my own so that I would learn all the intricacies of game development. A year or so of studying and work amounted to Welkin Road, a little puzzle platformer with grappling hooks.

In Welkin Road you use your two grappling hooks to solve movement-based puzzles.

While I was in the process of finishing Welkin Road, I started looking at potential studios I could join. That's when I saw a tweet from Frictional, mentioning that they were looking for a designer / programmer. I didn't think I was ready, but I figured this was my only chance to work with the company, so I sent my resume in anyway.

To my big surprise they offered me a work test, to see whether I was suitable for the role. I gave it my best, but after I sent in my project I tried to prepare myself for the inevitable let-down. Instead I got a positive reply and an invitation to an interview. The final decision came a couple of weeks later.

Spoiler alert: I got the job.

Given that I was a big fan of Amnesia and SOMA, the decision to accept was a no-brainer. However, it took me quite a while to properly register that I had fulfilled my lifelong dream. A year and a half later I realize how lucky I am to be one of the few people who can wake up on Mondays with a smile on their face.

After joining, I immediately started working on my introductory tasks aimed at learning the new tools. I joined at the same time as Max, so we bonded over struggling to understand all the new stuff. When those tasks were done, I started working on my first real project: designing and implementing eye tracking features in SOMA, which I will talk about in more detail in the next section.

A while after I was brought on, the company started looking to set up a studio in Malmö. I already knew that if I wanted to make games, I would most likely have to move, so the decision to move to Malmö didn't take me long to make. Finding a place to stay took a while, but I eventually managed to find a nice apartment and settle in, in no small part thanks to my incredibly kind and welcoming co-workers.

The setup in my new home in Malmö!

FIRING LASERS (more commonly known as Eye Tracking)

As promised, I will now spend some time talking about my adventures in eye tracking. After receiving a unit from Tobii, I first tested it with a bunch of games that already had eye tracking support. Deus Ex: Mankind Divided was a particularly useful use case study, since it had a robust implementation and used the eye tracker in interesting ways. I was initially very surprised at how well the eye tracker worked in that game, and how seamless and intuitive it was to use without putting any strain on my eyes. This gave me the confidence that we could use this to enhance SOMA.

Once I got a feel for what the technology was capable of, I read through Tobii's SDK documentation and code samples to figure out how it all worked. In simple terms, the Tobii eye tracker provides a continuous data stream of screen coordinates that represent the location on the screen the user is looking at. Think of it as firing 60+ laser beams per second from your eyes to your monitor. Bring it on, Cyclops!

After I was done feeling like a superhero, I looked into how we could use this in our own engine, HPL3. Since Tobii's SDK was easy to use, integrating it into HPL3 wasn't too difficult, especially with the help of our engine programmer Peter.

With the technical aspects more or less dealt with, I started thinking about the design of our eye tracking features, and how we could best make use of this technology to enhance the game. This included brainstorming sessions, quick prototyping and a lot of feedback from the rest of the team.

It quickly became clear that while controlling and moving stuff around on the screen with your eyes is fun, it becomes tiring and uncomfortable really fast. For a good experience, the player must never be actively thinking about using their eyes. Instead, the game should react to the player's natural eye movements and try to enhance the experience. A negative side effect of this design principle is that unfortunately quite a lot of features become very subtle and hard for the player to notice consciously, despite having an overall positive effect.

The white circle is where the player is looking.

Another interesting aspect of designing these features was how eye tracking could be used in a very immersive first person horror game. Horror games often rely on where the player is looking to trigger certain events, which always means a certain level of uncertainty about whether the player actually registered what was happening on the screen or not. With eye tracking, this uncertainty became very minimal, which meant that the timing of a lot of the events in SOMA naturally improved.

In the end, we ended up with a number of eye tracking features we were happy with. The most noticeable ones are extended view, which makes the viewport pan towards where the player is looking, and the ability to control the flashlight with your eyes. A number of enemies also react to the player's gaze, such as the flesher monster becoming aggressive when looked at and teleporting when the player blinks, or the deep sea diver stopping when the player maintains eye contact.

Other features are much more subtle and designed to enhance immersion and mood. For example, staring at creepy and gory scenes zooms the screen slightly, giving the impression that Simon is in a trance or shock-like state and can't look away. When the player looks at enemies, the screen distortion effect intensifies to further discourage players from looking at them.

Additionally there are some really secret ones, such as Ross' distorted computer messages appearing exactly when the player blinks, to further reinforce how Ross is inside Simon's head. My personal favorite, however, is a subtle reaction from K8, the incredibly friendly and helpful swimbot, which gives the player a small opportunity to communicate with it.

The developer showcase of eye tracking features.

In summary, working on eye tracking has been an incredibly fun and rewarding experience both because of the challenge, knowledge gained and the creative freedom. Besides, who doesn't enjoy firing lasers with their eyes? The end result hopefully enhances the SOMA experience, even if just a tiny little bit. So if you have the PC version on Windows and a Tobii eye tracker, consider giving an even more immersive version of SOMA a go!

The official trailer for eye tracking in SOMA.

Eye tracking is just a small part of my work at Frictional though, as I'm currently working on one of our next projects. I'm already really proud of what we're creating and I'm happier than ever with my choice to follow my dream of making games. We're all really excited to be able to share more of what we're doing, but until then we'll just keep doing our best. This also reminds me it is time for another gaming night, to keep our spirits up!

Quality Frictional Humour™ from a recent Jackbox Party night.

Wanna see who else works at Frictional? Check out the rest of the People of Frictional posts!

GameFly Experience (Monday Musings 77)

Addendum:
I returned Sekiro and by the next day, GameFly already shipped out a new game! I'm very happy thus far with my GameFly experience.

I decided to take advantage of GameFly's free month trial, and place Sekiro at the top of the list. Given that Sekiro was recently released, and GameFly noting that there's "low availability", I was surprised to see the game shipped out the day after I signed up for the trial! I signed up Monday, shipped Tuesday, and received Friday.

Given the popularity of Sekiro, I thought I had to wait a couple of weeks, at least, to receive the game, so I was pleasantly surprised to see "shipped" when I checked the status the next day. However, I'm not sure how quickly you can receive a game that has just been released that day. Would I have received Sekiro four days after its release date?

Looking through the list of GameFly games, I was impressed that they not only have the triple A titles, but also some niche ones including the Atelier series, that appear to come out yearly. I enjoyed Atelier Sophie, but not to the point where I want to buy future Atelier series at the $60 price point. 

You can keep the game for as long as you want, and once you finish the game, upon receipt, they mail you the next game.

Games in my queue are newly released Days Gone, Dragon Quest XI (as I was considering buying the game), soon to be released A Plague Tale: Innocence, and Red Dead Redemption 2. I'm curious to see for myself if I'd enjoy RDR2, and GameFly gives me the opportunity to do so free, as opposed to having buy the game and not enjoying it. 

As difficult as Sekiro is, even if it takes me 2 months to complete, the rental is nevertheless cheaper than buying the game full price. However, it does appear to be a game I'd like to buy on sale, once the Bundled edition comes out (From software always releases DLCs), so I can return Sekiro and hopefully get Days Gone (also "low availability").

Indeed, a strat that you can use, is to write down a list of all the game titles you're considering purchasing, sample these games, spending a few hours to see if this game is up your alley, and then return quickly to receive the next game. If a game appears to be a must own, then you can buy it without buyer's remorse. 

If you're a slow gamer like me and you like to take months on a game, then GameFly may not be a good option, since it costs $15.95/month for one game out at a time, or $22.95/month for two games out at a time.

So far, I've had positive experience with GameFly, albeit it's only been 1 week's experience. If you have a GameFly membership, please feel free to describe your experiences with them.

The How Of Happiness Review