The Future of Gaming

This guest post comes from Simon Cave, one of our project leaders, and one of the driving forces behind Mirametrix Gaming. 

Lennart Nacke on Biometrics

As part of the Mirametrix Gaming team, I recently attended the Montreal International Game Summit (MIGS) to get the pulse of what’s next in gaming. There were tons of great sessions on video game production (how to write scripts, how to make a story realistic, how to create texture and realistic faces and so on), but what I was really interested in was the future of gameplay itself. What technologies can we expect to change gaming in the next 5 to 10 years?

Attending the biofeedback talk by Lennart Nacke, assistant professor at UOIT and head of their HCI and Game Science Group, was a no brainer for me. His talk explored the potential of biofeedback (using instruments that provide feedback on physiological functions) to improve game design and, in some cases, add new forms of interaction.

The main issue with biofeedback is that it mostly measures physiological states that are not easily controllable (e.g. EEG, pulse rate).  For these things, biofeedback can give game designers valuable insight into how users respond to their game experience, but would most likely be an ineffective way to interact directly with the game itself.  And yes, most of these technologies are too invasive at this point to expect the average gamer to use (captors placed on the cheeks and between the eyebrows, for example).  But I still believe that breakthroughs in these areas may very well broaden our definition of what gameplay is at some point.

Gaze tracking is an example of a technology making the transition from an analysis tool to an interaction technology. Emotional analysis doesn’t look like it may be that far behind.  The advantage these technologies have is that people have found ways to collect and analyse this information without any form of physical contact with users.  Emotion is also already tied to what is considered an important part of the gaming experience.  As one audiophile noted, composers are paid to put emotion into games (Apologies, we can’t remember who it was!); What if games could also adjust audio or other content to your current emotional state in addition to your point in the game? It remains to be seen what kind of benefit this will have for gamers, but who knows, the analysis tools of today might turn out to be the game changers of tomorrow. It’s something worth following.

And what of today’s game changers? They seem to have taken their cue from Halting State. Ingress and Canadian based Clandestine Anomaly promise to bring gaming to the everyday.  With the growth in mobile technologies, expect more on the social gaming and augmented reality front.

Being the non-techie in the room

When I started at TandemLaunch, I came straight out of university and the closest thing I’ve ever came to an engineer was the plumber at my parent’s house. I had no idea what an FPGA was, never heard about C++ and only had a vague idea how computers work. Applying for a job at a tech start-up seemed kind of ballsy, but that’s how I am.

But I’m realizing more and more that a lot of project managers don’t have a clue what their engineers are doing (or are supposed to be doing.) The number of project managers who have a background in engineering is declining steadily – thanks to specialized degrees in project management and the flood of MBAs who think project management is “no big deal” because they took a class in it.

So how do you deal with this lack of knowledge? How do you get the engineers to respect you, even though they know much more than you about the work? Here are a couple of things that I found useful.

Be honest. Don’t pretend to know something you don’t. People with domain expertise will figure you out in a second. Pretending is never a good idea – and can destroy your credibility when you are called out on it. So just admit you don’t know. This is generally a good piece of advice – if you don’t know something, just admit it. Use your project management skills to gain credibility within your team instead.  Don’t make the fatal mistake of building a project plan in isolation of the project team that will be executing on it. Draw on your team (that’s why they’re there).

Be open. One of the things I love about the engineering team at TandemLaunch is that every single one of them is completely passionate about what they do. They just love their job. And as soon as you show interest in it and ask questions, they will love to teach you. Remember you are a part of a project team: a group of people with different skill sets working together towards a common objective.  Take the time to appreciate their contribution as much as you hope they will appreciate yours.

Learn. This is not just for your job, but for your life in general – why not learn coding? Sure, I’ll never be a software engineer, but at least I am able to understand what the engineers are talking about. The great thing is that there’s tons of free stuff out there. The standard sites are codeacademy, codeschool and udacity. There are also python classes over at kahnacademy. Which one is the best depends on what you want to do with your code. For web, JavaScript, HTML, Ruby and CSS are the ones to choose. For a more “hardware” approach (computing and the like), C/C++, Java and python. You could also look into some scripting language like perl, which is more for text/file processing. For something more UI oriented, C# and VB are the way to go.

Show your value. There are a couple of things that engineers – as a whole- are not really keen on or are not in a position to do. That’s why your role exists! So demonstrate your value here. In general, this seems to boil down to exact specifications. Nothing drives engineers crazier than ever-changing specs.

And if you want to hear this story from the other side, there’s an excellent blog post on the care and feeding of software engineers by Nicholas Zakas.