#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 »
Thursday, March 5, 2020
Wednesday, March 4, 2020
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.
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:
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.
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:
Morgan does a nice job introducing and justifying the new features at times:
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:
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.
 | 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(' ')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
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;
}
}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
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
Monday, February 24, 2020
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. :'( |
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!
Sunday, February 23, 2020
GameFly Experience (Monday Musings 77)
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
Friday, February 21, 2020
Call For Candidates For IESF's Referee Course.
 |
| Johan van Breda (ZAG Academy) in action at MSSA's National Championships. |
Busan IT Industry Promotion Agency (BIPA), IESF has achieved great strides in this arena and has been able to, as a result, add value to esports championships world-wide.
In 2016 Mind Sports South Africa's (MSSA) candidate (Thomas Brown) participated in the first international referee workshop in Yinchuan on 12 May 2016. Thomas went on to be the first South African to referee a major esports event in Beijing in the Olympic Tennis Stadium.
Thus International Esports Federation (IESF) have requested its member federations to submit candidates for its 2020 Referee Training Course to be held from 24 to 28 February 2020 in Busan, Korea.
The curriculum has been developed by IESF together with game publishers in an effort to ensure that it meets the highest standards.
Candidates for IESF's International Esports Referee program are nominated by member federations until Wednesday, February 12th (KST). Successful candidates will be announced on Friday, February 14th (KST) by IESF.
Thus all Registered Players who are currently qualified as MSSA umpires who are willing to be considered for selection must provide the following to the Board by 10 February 2020:
Thus all Registered Players who are currently qualified as MSSA umpires who are willing to be considered for selection must provide the following to the Board by 10 February 2020:
- Number of national championships refereed by the candidate, and
- Proficiency in English
For more information, please contact mindsportscorrespondence@gmail.com
Also read:
Also read:
- Ensuring gender equity in esports.
- MSSA celebrates its women who have earned Protea Colours.
- Why schools and universities should invest in esports.
- Entry fees for Provincial and National Championships
- How school clubs affiliate for the 2020 season.
- 2020 Calendar of Events
- The various events held by Mind Sports South Africa.
- Why schools and universities should invest in esports
- New National Team Selection Criteria
- Selecting the national Protea teams for Mind Sports South Africa.
- The road to Eilat
- MSSA to nominate candidates for IESF's International Referee Workshop.
Thursday, February 20, 2020
Mouslings!
These are some Reaper Bones figures I bought just because I like them. The paint jobs aren't really anything fancy, but they work.
Subscribe to:
Posts (Atom)