Game-Testers

Game-Tester: sounds like a lazy dream job, doesn't it? Well, maybe you want to read this first.

Finally. Today I made the T22 Game + Tools available for an artist, so he can play, look, give feedback, and hopefully start replacing ugly dummy "Programmer Art" assets with some real awesome stuff. Well, if the .EXE works that is. You programmers all know what happens when giving that floppy with your program to another for the very first time... "Hej? How did that happen? On my PC it always works! What is the errorCode? Access Violation and then a long number you say? Strange...".

But hey, the executable actually worked on another computer (somebody at work was "lucky enough" to give it a shot), though the FPS was like grandpa's siesta. Unlike typical desktop programs, where most issues come from different Windows versions, missing drivers, network permissions, or local user settings, with games your biggest enemy is the videocard. Too old, too new, too nVidia, too AMD. Certain features you counted on may not be available, or shaders get compiled slightly different, causing black screens or glitches. In this case, the game just worked (shockingly, I really didn't expect that in one shot), but his older nVidia didn't like OpenGL ComputeShaders, I think.

Beta Testers

Well, our guy here won a brand new nVidia with an artist contest, so that shouldn't be a problem. More realistic problems could be getting stuck in the game itself. Falling through floors, getting locked in the stairs, just not knowing what to do, corridors too dark, game too boring. Who knows. Of course I play-tested the game like a hundred-trillion times. To check if script-X triggers, or if visual glitch-Y was fixed. And no, I didn't get stuck by bad physics really. I won't say its flawless, but I it ran pretty stable. On my computer at least. 

But testing your own game (or whatever program) so many times, also blinds. You automatically know what to do, and what NOT to do. Subconsciously you just know to stand on the left side of a door when opening it, avoiding a slam-in-your-face. You know an approach angle of 84 degrees works better for that specific ladder. And in a fairly dark game like T22, you know where to go and what to do. BUT, what I don't know: is the game fun to play? And more important, does this horror setting give any goosebumps?

 I see an empty unfinished room. Others may see an uncomfortable scary room. Yet another sees nothing at all: too dark. 10 people, 10 different opinions.

CUT. And… Action

Obviously I played / tested it so many times (and I really mean thousands of times) that there is no surprise at all. I know where to find every ugly bug in the environments, the monster A.I. is predictive, puzzles easy. To be honest, I don't have any fun playing it. Bad game, or just tasted it too often?

I wonder if movie directors like Steven Spielberg has been rewinding every 10 seconds of Jurassic Park a hundred times to tweak and fine-tune. I wonder if they shout "CUT! Stop, dammit" again and again. I hope they have other minions doing that for them, otherwise the final movie Premiere will be a loooong sleepy ride, knowing every inch of that video tape. I wish I had an army of workers doing the fine details of T22 for me, so I could just focus on programming stuff, and directing it on a global level. Then every week, artists would spoil me with fully-finished rooms, animated monsters, or music-pieces. I would use a red and green marker to approve or discard their assets. Being a bit outside of that "development dome", allows to look through different glasses at your work. Sharper, unbiased, loving or hating it.

Back to reality, I'm my own modeler, mapper, scripter, programmer, texture drawer and even audio composer (= Googling for free WAVs) all at once. And not a very good one, except for the programming part maybe. So there is zero surprise in the work being done. Except annoyance about the shortcomings, you know exactly which details have been rushed or skipped.

Script Writers

I underestimated the amount of scripting work that had to be done last half year. With that I mean "programming" the puzzles, triggers and events in your maps. So, what happens if you try to combine the blue key with the red door? T22 is sort of a puzzle game, so there is a lot of scripting. And to make it even more complicated, T22 uses a time schedule. That means certain puzzles or the visual state of a room, may also depend on the day or time. Curtains might be closed during nights, and between 10:00 and 10:30 on day three, something spooky happens on the corridor. Having time dependent scenarios doubles, triples or quadruples the (scripting) work per room

Also testing gets more complicated. You can always try an elevator or monster combat A.I. But puzzles usually require a certain chain of events. Timed events in this case; collect key on day1, do stuff at day2, then item-X appears on day3. And of course, there will be initial bugs somewhere in that chain, so you'll be playing that sequence again. And again. And again. Then it finally fucking works, until you add another side-puzzle that somehow interferes, and disrupts the chain-of-events. Sigh. It’s like Jenga: insert a brick here, another brick falls out on the other side.

Having good tools softens the pain. First of all, you probably want to write down the events and puzzles first, on paper, on a global level. It always helps, having checklists you can confirm. But... in my experience, a creative process (like making a game) doesn't play well with a planning and systematic approaches. You can't squeeze out good ideas on demand. They just happen (or not, most of the time). So after playing the same room for twenty times, you may suddenly get a bright moment, deciding the room needs a bit more spice of this, or a puzzle like that. And once you've added that spooky event, you may still decide it sucks a day later, scrapping it.

 

Having a BehaviorTree editor definitely helps making your game "Behave".

Nonetheless, a list can help staying on schedule, and obtain a feeling of progression. Otherwise you would be tweaking and changing the same parts forever, never satisfied. Second, having some programming help-tools is mandatory. You could hard-code everything in Delphi (or C++, or ...) but assuming your Mappers don't know/have Delphi in general, it's more common to provide a scripting language or techniques like "Behavior Trees" in your (Map)Editors. Engine22 offers LUA scripting, which is pretty cool, yet I still made a lot of (syntax) bugs in the small scripts. Far more robust are Behavior Trees, which were added later on. They are fairly simply to make, and the chance of screwing up is much smaller, as you don't have to type any code or whatsoever.

It took a while to implement Behaviour Trees. Not just the code that can traverse a BT, but also the editor to create them, and the API with functions. As you would do with LUA or Python, also BehaviorTrees require a set of functions. “PlaySound”, “setVisible( entity, true/false )”, “GiveItem”, “check if variableX is > 5”, and so on. You start with nothing, and then the API slowly expands as you need more stuff to accomplish a specific puzzle or event. It costs a lot of energy, but when it works, it works like a charm, and saves a lot of work (and bugs + frustration) on the longer term.

Anyway. I hope our artist can see the potential of the game (demo), and has some time left to help me pimping up some rooms. So I can finally back of the game itself for a moment, focus on improving graphics or fixing whatever bug he finds or tool he needs. I’ve seen the same T22 corridors too many times last years!