Gamers and Testers - Episode 5

career, testing, quality, interview, and gamersandtesters-series
a screenshot of the Return Fire videogame from 1995/1996
Return Fire, 1995 (screenshot of the PC port released in 1996)

Hello there! This is the fifth post of my “Gamers and Testers” series. In these posts, I ask a guest a series of usual (and unusual) questions about their experience of being involved with software testing in the videogame industry.

This post in particular is slightly different than the past posts in the Gamers and Testers series. My guest was not a dedicated videogame tester at any point in his career. His name is Reichart Von Wolfsheild. When I first reached out to him, I was reaching to “a name on an old credits section” of one of my favourite childhood games, Return Fire. Once I started to do some research on who was the man behind that name. Well, words are not enough.

Cover of Return Fire videogame (courtesy of Reichart Von Wolfsheild)
Cover of "Return Fire" (courtesy of Reichart Von Wolfsheild)

Reichart has accomplished so many things that they’re just too many to mention on this post alone or do justice to with a single paragraph: he’s the lead scientist at Prolific Publishing, he’s a true pioneer in the technology world for over three decades, in areas such as Military, Law Enforcement, Movie and TV Entertainment, Gaming and Slot Machines, and Video Games. He’s also an inventor, at one point having been one of the co-hosts of the History channel show “Invention USA”.

Having been the main person creating and guiding the development of the Return Fire videogame series he was not just the one that formed the Testing teams for his software projects, but was also the main person behind the software created to track testing efforts for games like Return Fire, later on having sold that tracking software to United States Department of Defense and law firms.

1. Return Fire was perhaps one of the top favourite games shared among me and some family members. What is(are) ‘THE’ game(s) that are your all-time personal favourites?

At the core, I design games I like to play, so, as a result, my favourite games are those that use the computer simply as a medium for people to play against one another. Together with my amazing team, we pioneered the first games that let you play arcade-style, and over a modem, and with a joystick, and allowing people to text each other at the same time. Common today, but trick back then.

Did we have to add ‘chat?’ No, but this was the most important feature to me for multiplayer games.

I would say the late Danny Bunten’s M.U.L.E is a great example. And it is still my favourite way to teach economics, stocks, markets, etc.

Will Wright’s Raid on Bungling Bay is one of my favourite single-player games, and it was a strong motivation for me to make that type of environment but for more players.

I got into Quake for a while. We would play this in our offices while making other games. While the physics are strange (fake), it is one of the few games that lets you really get into the head of another person you’re battling.

2. Return Fire (RF) (and RF 2) held some innovations that even for today’s standards not a lot of AAA titles take into account (or on the other hand cut corners on) and that gamers miss out on: from rare gems like supporting “couch” co-op gaming in split-screen out of the box, and at the same time allowing for networked play with others, plenty of content (missions) from the get-go, … Do you feel that a lot of care/love/attention to detail which was very apparent in some past titles is getting watered down through times?

Clearly. Games need to be made in phases. There is no hard and fast rule, but you want to get your core game mechanics in place and make sure they are fast enough. Then you want to start fine-tuning the game-play. It has to be addicting (a word we never would have used back in the day). Then, for me, comes the ‘polish’, those little things that make you laugh, and that you remember about a game years later.

Most games have such tight budgets in terms of money and time, there is little room for this last phase. I often would try to get them all in while we were bug testing at the end. Since ideally the ‘polish’ is not creating new bugs. Funny, the more bugs we have, the more ‘polish’ we get.

Two of my friends - Brett and Louis - that founded Westwood Associates (Command & Conquer) would have big meetings and simply ask ‘what is the worst thing about our game at this point in development?’ and they would make sure each round of that they took the worst part and made it into the best part. I began using that as well. Making video games is not quite like anything else out there, and having made many products in my life in many industries, video games need more ‘philosophy’ than almost anything else I know of. The next closest thing I can think of is house architecture. Did you plan for where the sun will be? Did you plan for where the sun will be in 6 months? If I were to make games today, I would start with 100% simple wire-frame (think Jez San’s Star Glider, or arcade coin-op Star Trek, or Battle Zone, also made by two old friends of mine, Sam and Roger).

If you can’t make the game work, and be fun, and engaging in wire-frame, do you really think fancy graphics and GPU tricks are going to save it?

The greatest compliment you can get from the old video game designers is ‘you gave great thumb.’ which was a reference to the pain one incurs in their thumbs when a game is so good you just play it way too long and realise you’re actually in physical pain because of it.

3. RF1 and 2 always come to my mind as examples of games that expose complex gameplay elements in a clear/crisp way while at the same time being well crafted and thought-out in terms of what happens in edge cases (leaving map area, disconnecting, getting stuck, destructible materials and environments, etc.). What are some of your top guiding key principles in terms of Testing that allowed for that demonstration of craftsmanship?

I grew up in an odd way, a common topic in my family was game theory, military strategy, etc. But also, just the act of working out backwards and forwards how to solve problems.

A game my father played with me was to imagine you were simply dropped off in the middle of some random city. You have nothing, and everyone you knew is simply gone. Literally, step by step, what would you do? You have no money, you know no one, but, you have to survive, and hopefully thrive.

It was sort of a role-playing game, my father would do his best to be a fair but a realistic Dungeon Master. So asking ‘and what happens if you push the limits?’ is a constant question. You can see similar things in movies and TV shows. The Prisoner is a great example. How to keep everyone on the ‘island’? And with no budget? They picked a giant white balloon. My first question when we designed Return Fire was ‘are we doing the crappy Atarian Loop (as I called it) or, what happens at the edge of the map?’ Almost instantly The Prisoner popped into my head. They already solved this problem, but we had the budget for a full-on submarine with a heat-seeking missile.

I love any game that lets you just explore and ‘feel’ the environment. Like Quake, physics don’t need to be real, but everything needs to be consistent.

CNET's Desmond Crisis interviews Reichart Von Wolfsheild Return Fire II.

4. From your experience as a leader, what kind of different elements do you believe make a Software Tester successful in testing efforts of a videogame product as opposed to a typical product?

You need clever people. We used to do our internal testing. We built this into the cost of making products (still do). But publishers have their own testers. Our goal was to make sure we had logged any bug or even potential for a bug before the publishers found them. It was great pride we could constantly say ‘yeah, we know about it, it is already being fixed.’ And I would reward the testers for this as well.

So the key ability is to model and plan how things are most likely to fail, and then go and try to make that happen. Most test teams I’ve talked to copy a test plan from a previous product, and then just do obvious stuff. Yeah, that is not going to work out well.

Also, internally, having the testers compete with one another is a lot of fun. Ranking the quality of their bugs and tallying that. Look, if you are into games, make everything into a game. This is a good place for competition.

5. You had mentioned in private that you had created the QA & Test teams for RF, as well as the software tools used to track testing efforts of games like Return Fire and that some of these software tools you now sell and maintain outside of videogame-production context, like Defense and Law firms. What were the most useful ideas and findings that helped shape these tools?

That is an easy one. I created a super clean simple way to encode the nature of bugs even back when we were using sneaker-nets to exchange our bug lists.

Here it is (Severity):

But this was paired with (Frequency):

Now, when you put these together, magic happens. Because, first, this sorts itself from most important to least. And that includes the frequency. A crash bug that happened once should scare the hell out of everyone. So we address those first. We do our best to reproduce it ASAP. Any bug that can be reproduced can be fixed usually pretty easily.

But a bug that happened once, or randomly, that is where you must put your energy first.

Having this model of issue tracking is infused in every single Project Management feature I build. I’m all about Accountability and Transparency. I use those to mean ‘never let the ball drop’ and make sure you have teamwork that can see what you are doing and help if needed.

I think a lot of companies waste an amazing amount of time because people are so secretive with what they are working on, or don’t seek help from others.

The core of my test philosophy IS to make sure there are focused tasks (issues), and that one person is responsible for getting it addressed (the Doer), and others can watch it and help that happen. It’s all about teamwork. But there is also a person called out as the Lead. They also have a deep responsibility to make sure the description is clear, to make sure the stone moves in the right direction, as in the sport Curling.

6. One could say you are an inventor to the core of your being, taking into account all the things you’ve created. Do you feel that impacts your views on software development and software testing, as opposed to views held by software folks?

Absolutely. When I work on things for the military, it is ever-present in mind that lives are at risk. It’s one thing to ‘do your best,’ it is another to make damned sure nothing fails. I’m simple in my designs and architecture of software. I see everything as a state machine, and most bugs I find instantly are of a nature where I can ask ‘how is it even possible this state happened?

If programmers have bugs that could be solved by a simple model of a state machine, then they are not programming correctly.

You may be familiar with those memes these days of ‘You had one job’ and then show - for example - a road sign truck painting SOTP on the ground.

How was that possible? Firstly, it is often done ‘free-style’ (by hand). Humans can make mistakes, and so, they WILL make mistakes. Some use templates (friskets), even these will fail. This is because the individual letters all have the same rectangle frame. If they added notches so that S could only go next to T, etc. that problem would not be possible. This is just a silly example (although real), but hopefully, this paints a clear picture.

Ultimately, it is not about making things work, it is about making it impossible to fail.

7. Any advice you would give a friend wanting to join the videogame industry as a Software Tester?

It helps a lot to have a basic and healthy understanding of how a computer really works, from the hardware to the drivers to the OS, to the API calls (these days).

If I had to put something on my resume trying to get a job in Testing or QA it would be ‘I don’t report bugs, anyone can do that, my job is to take all the guess-work out of it so the team doesn’t waste time, and we ship a rock-solid product.’

I would go further and point out, testers are there to make the dev team look good, to protect them, and fend off the enemy (which can be both the publishers and the consumers). We want smart testers, we need them.

In an interview, proving you have a philosophy, and a plan for testing and a healthy understanding of the nature of why bugs even happen is what will cinch the deal.

Cartoon of Reichart drawn by the famous artist Van Arno who did the cover of Return Fire (courtesy of Reichart Von Wolfsheild)
Cartoon of Reichart drawn by the famous artist Van Arno who did the cover of Return Fire (courtesy of Reichart Von Wolfsheild)

8. A final offtopic question: Any plans for a Return Fire “HD remake” or even a Return Fire 3?

I think about this often (since I get asked often). Once in a while I will play a game on a smartphone that sort of looks like what we were doing 20 and 30 years ago (you do realise we made Fire Power over 33 years ago). The controls are pretty, the environments get better every day. But, I find I’m just not having ‘fun’. I was looking at a big cowboy game that is in the news right now. It is damn impressive. But a lot of it isn’t. For that much money and effort, wow, it should just be stellar.

As simple as it might seem, it would take a lot of energy to make the controls perfect, especially for each vehicle. This is what I spent most of my time on with each version of the game.

The Jeep drove so fast we realised we simply had to add a sort of ‘locking on’ to the roads. If you could get yourself to a road, the road would help you drive better and faster. This is subtle … but took away the stress while adding excitement and a feeling of exhilaration. So that gives me the urge to do RF3.

I still would enjoy making the game I want to play.

Reichart giving Elon Musk the Edison award for the Tesla (courtesy of Reichart Von Wolfsheild)
Reichart giving Elon Musk the Edison award for the Tesla (courtesy of Reichart Von Wolfsheild)

Thank you Reichart for the time you invested to answer these questions, and thank you, the reader, also for your time reading this post. I hope you’ve enjoyed it. For more information on Reichart you can check out his LinkedIn page.

Feel free to reach out to me with comments, ideas, and suggestions via any of my social media, or by email, which you can find in my Github account. Until next time, take care!