Press my Button

Human Machine Interface 

You may have never heard of it, but you used them a million times by now. Although the word "HMI" is more an industrial/PLC term for touchscreens, you could call pretty much anything that lets you operate a machine or device, a "HMI". The thermostat display in your living room, a packaging machine button panel , the dashboard in your car, the control handle on fat aunt Beth's scootmobil, et cetera.

As the name implies, humans communicating with devices somehow. Well, I have made quite some interfaces throughout the years. And like mode & fashion, visual interfaces tend to change like the haircuts from Sixties Beatles to Seventies Bee Gees, from Eighties Rick Astley to Nineties Fresh Prince of Bell air. Large square tiles with simplistic retro symbols are hot now, but what will it be next year? Ten years ago it was much cooler to create an dark icy, complex, "The Matrix" style with lots of small buttons and nerd-information scattered everywhere. When I compare my older programs with the newer ones, they look radically different.

They all have one thing in common though; their users have to be considered either stupid or highly trained, and so the interface has to be as simple or powerful as possible. And this is where our programmer brains short-circuit sometimes. You see, making something easy difficult, is easy. Making something difficult easy, is difficult. Read that again.

Poor Carl

When we create a new program -let's say a packaging machine touchscreen- we programmers have two major flaws. As we designed our own program, we know exactly how to use it, and more important, what NOT to do. We're not able to approach our program without pre-knowledge, with a blanco view, pressing different buttons in the wrong order. Or worse, not pressing buttons because we have no clue what they do, and are afraid of screwing up. If a programmer comes explaining things, he's like "Oh that's simple. Press here, here, then here, and then –oops.. hey, that shouldn’t be there! Weird. Little bug still in this version I think. Well, in that case press there, and then you're done. Simple right?!!". 

61 year old Carl, who grew up in a barn without electricity, fought in the Great War, and used the first gas-driven telephone when he was 19, nods "Yes, I understand". But the cartoon-dream-cloud above his head says "..........". Most people will say "yes". Because we don't want to look stupid. But a good portion of machine operators, desktop office-clerks, or Excel administration nannies, were never trained or interested in computers. Listen young punks, I'm not that old, but even I didn't grew up with a telephone and apps. It’s not a second nature.

This is what you see on the cab-display while driving in transport mode in the harvesters I program. Hate or love the colours, but the point is that a dummy can see what he needs in an eye-blink. Also, the big cartoon buttons seem friendly - you can press them without blowing up the machine or ejecting the seat.

No!

Some people won't say "yes", and will ask though. And that's where our second flaw comes around:

we're arrogant. When that (ugly) lady from the office still doesn't know how to delete an item, when the chief calls in anger that everything is stuck, or when THAT guy complains for the seventeenth time, we're inclined to say: "Screw them". It's their own fault. How many manuals did you write? How many times did you say NOT to drive and press the handbrake at the same time? How many warning stickers are there on that hot oven? From all people, why did they put the analphabetic Indian behind the controls? Why don't they just understand?!

When that picky ass starts telling the font-size should be 1 pixel bigger, the button should be at the top instead of bottom, or thinks an extra confirmation pop-up is annoying, we're inclined to say: "Really?!". What a pile of horseshit. Pressing 1 extra little button, boohoo. LimeGreen background instead of PastelGreen, so what? Again, we fail to see our creation from a different, user, perspective. We make stuff, think it’s cool, and drop it off. Moving that button to the left really isn't that much work, but it's boring work. Our mind-set is already in that next, more interesting project. And of course, nobody really likes it if his plans or design are questioned. Can't they just adapt and deal with it? We're not calling Microsoft every day either, to complain about small letters or hard-to-find settings. But we forget that, when using the same software EVERY day, small annoyances can be become a big aversion. Do you use programs that don't feel good, if you don't have to? Exactly.

Stay cool, have fun.

So I'm making the Engine22 Map Editor (or “MapEd” in short) now. Or well, I've been working on that quite some time now, but recently another guy started using it. Julio, who contributed T22 assets since 2010, got a copy. For two reasons; Giving a toy to play with & Feedback. There has always been a T22 editor, but I never released it. Because I knew the interface was programmed "Rick only". So in the past, I would typically ask an artist to make an asset, say a Sofa. He has no clue what, where, or why, so I also give background information. A sketch, a photo URL, or a list of requirements. He makes the thing in Max, Blender, Maya, or whatever program, sends it to me, and then I would import it into Tower22, using highly sophisticated (read buggy user-unfriendly) software. And 9 out of 10 times, I would make an in-game snapshot plus a list of improvements, and send the object back to the worktable.

It works, and I guess big companies do it like this when outsourcing assets to some other company that "just makes models”, without having to know what this game is all about. But... it's not a playful, dynamic, creative flow of course. Especially not for a creative guy that does this in his free hours. He or she should have some artistic freedom. Fly through a room, have a careful look, then decide "We can really use a pink sofa in this corner!". He or she will make the asset, and import it themselves, get a preview, and tune it until they love it. All in all, a more inviting, as well as more efficient flow, potentially. Keep in mind that artists here work on free will. So “having fun” is a keyword. Giving them a “fun editor” is mandatory.

A broken editor that can’t do shit isn’t much fun though. Most artists, and certainly the skilled ones, have been spoiled with superior tools and engines, like Unreal, Unity or CryEngine. Of course, it’s not like mr. Rick from the Netherlands will do a better job with two fingers in his nose in the late hours. But I do have an advantage though. Since E22 doesn’t have to be an all-round, multi-purpose-ultra-engine that also works on Atari and Cyborg telephone platforms, I can narrow my set of goals. Ultimate goal? Making Tower22. Or at least that G@#% playable demo for a start. Additional goal? Eventually letting other (Delphi) hobbyists using the engine, or parts of, to make a somewhat similar fashioned game.

Artists should be able to import, tune and preview their own stuff this time. Still have a LOT to do though!

Multi-useless Tool

My experience with universal, multi-purpose software, can be described best as “Jack of all trades, Master of none.”. And I’m not talking about game-engines, as I honestly don’t have a lot of experience with them, but just in general. Warehouse, administration and ERP software for example. Since every company knows it all better, these packages are either highly complicated due all customizable parameters (most people I know have no clue how their package really works), or very restricted and therefore a pain in the ass. And in terms of UI, boring. Not intuitive at all, though it’s hard to blame the makers. How the heck should they know whether their software is being used in a paperclip factory, Thai massage saloon, or crematoria? Different story each time. So they have to keep it abstract and thus “bland”.

Frequent- or pro-users deserve better:

·         Every unnecessary step is one too many

·         Eliminate anything that slows down the process, or confuses

·         Good looks are nice, but speed & ease should get priority for pro-users.

·         Whereas a non-computer audience will be better off with a very minimal, playful UI

·         Whether you use text or symbols; be clear. Users shouldn’t have to guess what a button does.

·         Be consistent. Looks and procedures should be the same as much as possible.

And last but not least, know your audience. Take their feedback or complaints serious. No matter how stupid or picky it sounds. After all, they’re the ones stuck with your software or device-controls the whole day long. But! With one big side-note: have a vision and lead. You can ask a person what he wants, and implement it exactly that way. But if you ask another person, you’ll get a different story again. And what do you get if you mix 10 different colours? Yep, brown mustard poop. You should decide the main direction, whether to goo blue or pink. Then use the feedback and comments to fine-tune.

Engine22 Map Editor improvements

Now the Engine22 Map Editor. The audience is experienced here, they know how to turn on a computer. That means less concerns about stupidity, but at the other hand a more critical audience, as they know similar software as well. My first mistake was that the initial design had pretty large buttons with icons. The stuff I’m used to when making agricultural machine-cab interfaces. While driving you don’t want to read small letters (some can’t even read). Big simple dumbass indicators is what we needed there. But for a modelling/rendering application, big dumbass buttons will consume a lot of precious space. Turned out my “test guy” didn’t have a very high resolution either, so an awful amount of space was wasted on funky symbols, thick Form headers, and voids. Meaningless stuff.

So I received a whole list of suggestions to “compress”. Got rid of the standard Windows form headers, gone with the big symbol buttons, increase density, move less important functions into a sub-menu or something. Second, a lot of hotkeys had to be added. Yes, moving the mouse from A to B to click, takes a second (and a nano-calory) more than having your other hand pressing the magical combination. Personally I’m not a hotkey guy, as I can’t remember them. Kids still showing me handy shortcuts that have been in Windows for ages J But again, if you had to use this tool a substantial amount of time, anything that adds up to the comfort, should be embraced.

Lots of panels while editing this sofa. But, in contrary to the previous version, you can now move and hide all panels quickly, with shortcut keys eventually.

Third, and probably most important, it must work. That’s captain obvious, but really. Sometimes it’s better to keep half-finished stuff hidden, instead of implying that featureX is operational while it isn’t. A program like MapEd is complex. It has dozens of features. It’s more or less the game + an editor, double trouble! Since the engine core itself is under heavy construction as well, it sometimes feel likes a Jenga tower. Insert a block here, and crap, some other part falls out.

Julio began his journey with importing stuff (OBJ files and textures) to make them “props”. And as Murphy tells, more than a handful of things crashed. Of course there was the usual video-card beef. Shader bug here, OpenGL not supporting that, his screen blurry while my isn’t, et cetera. As expected. But also some of the executables didn’t run due some missing library for 32-bits, and it seems every 3D package does a different job exporting OBJ files, as that didn’t work in one shot either. Polygons messed up, textures upside down, that kinda stuff.

Since Julio is my test-guy, there is room for error in this stadium. But at some point, he will also be an end-user. So be careful with that “room for error”. If something crashed the first 100 times, that fragile feel will haunt your product for the rest of its life, even if the bug has been dealt with. Every update should feel as an improvement, not a wild trail-and-error ride. So I try to avoid a billion updates, and to make things more comfortable, E22 has a tool called “HUB”. This tool checks a FTP server for engine and asset updates. Especially the latter is interesting. When you’re done with an object, material or room, you can upload it within a few clicks. Then other users download it next time they check for updates. Too bad HUB itself still has a couple of issues :p

Making a Playable Demo map

As you may have red between the lines, “we” (not much help at the moment :( ) are making a playable demo. Finishing T22 in the current setup will take as long as traveling to the closest neighbour stellar system on a child’s tricycle, so that's obviously not an option. What we can do about that? Make a playable demo, hope you like it, then launch a Kickstarter campaign, fund/gather artists, cross fingers, and kick-ass.

But to let people open their wallets, you'll need to impress first. So, a playable demo. Anyhow, I wasn't planning to write about future plans and strategies. Let's focus on the fun part instead; making game-maps! 

I love painting maps like this in MS Paint. Too bad MS Paint is broken since Win7.

Of course we made some maps before, for the demo movies. But those were usually small, isolated parts, and weren't built for real gameplay. This time, I have a complete (but not too big to avoid endless development) map; a real piece of the actual game. Or at least, we're busy making that.

Easier said than done, of course. And I'm not only talking about writing code or doing the audio-visuals. Talking about the actual game-design and mapping itself. Since this is the first "real" map -meant to be played-, a lot of practical issues come around the corner. Stuff you may not directly think about, when coding, drawing or modelling your next game.

When making a game, or a small demo in this case, there should be some goals, asides from just finishing the darn thing. If you were about to give this demo a try, what should it do to impress? Exactly, a horror game. Scare you. Or better said, since T22 is not really about jump-scares, make you feel very uncomfortable, yet anxious to know what will happen next (after the demo). That should be our main goal. But there are a couple of sub-design-goals as well, on a more detailed layer.

Size does Matter

For one thing, the demo shouldn't be too long, nor too short. 30 .. 45 minutes would be acceptable, 1 hour or even a little bit more, would be perfect. In general I hate to pay 60 bucks for a 6 hour game, but we shouldn't forget this is a demo. There are a few ways to accomplish this “duration” aspect. First option is to make the environment so goddamn big that it simply takes THAT long to get across. Free-roaming games like GTA, Zelda or Fallout rely on large maps. But also linear "corridor" shooters like Half life or Call of Duty need plenty of space to offer some lengthy gameplay. Or very difficult battles that keep you pinned on a certain position. It's not a big surprise though, that, as game are getting easier and the visual content more beautiful (= more work), the length is getting shorter. Most of these shooters are 5, maybe 10 hours at most.

4 hours, 40 hours... Quality also counts. You don't finish a game that takes 100 hours, but has a moldy cheese gameplay. And otherwise I can highly recommend you to play this:

If you're all about lengthy games, this is the shit

Another (better) way to extend the quantity, is to make it replayable. Take Tetris or a Wrestling game. Usually only one stage (maybe a few variants), yet very replayable. The wish of any game developer. Make a minimum amount of content, and get the max out of it by making the game very addictive. A good linear shooter which takes only 9 hours, but is worth a replay, will still give you ~18 hours of fun in the end.

A third option is to make the game Very hard, and/or do a lot of backtracking, so you can basically recycle the environment. Sounds very green. A game like Resident Evil (the old ones) didn't have a massive map, if you simply count the amount of rooms or walkable square meters. Yet it did take some time, as the puzzles were pretty difficult, and the game involved a lot of backtracking. “Stinky balls, forgot the screwdriver in my limited 6-slot inventory to solve that puzzle! Back to the storage trunk, and watch out for zombies. Better take a safer route, as we only have 3 bullets left.” That kind of work.

Beauty, Smart, or Big?

What would be a best-fit for Tower22? Option1, just throwing lots of rooms and corridors on the table, will be very hard. In multiple ways. As you know, unfortunately, pushing out high-quality content with the speed of a mini-gun, isn't our talent. More maps = more work, simple as that. Also, it will be a creative challenge. Since Tower22 takes place inside a, yes, Tower, you can't rely on stretched jungles or rocky mountains. Although a skyscraper has the advantage of being tall, I must say.

But even so, more rooms doesn't make the game more interesting automatically. What could you expect in a tower? Uerhhh... rooms? Corridors? Toilets? Balconies? Elevators? Stairs? Basement rooms? You see, the available options are limited. Exploring 4 apartment rooms will be interesting. Having to explore 400 apartment rooms will become annoying. The trick for us is to make each corridor or room a bit different. Different shapes, different furniture, another wallpaper. But imagine

if you had to make skyscraper with 400 unique rooms. Arh!!

Can't blame them since their game-world is huge, but it's pretty amazing that games like Fallout4 or Crysis3 can get away with recycling the same wall-textures, furniture assets and junk-props over, and over again. You'll see the same sofa's in every house (and there a lot!). Then again, As an action-game, truly unique environments are less of a requirement compared to Tower22.

Well, I can assure you Tower22 isn't only about corridors and rooms. The environment gets more bizarre as you delve deeper (or climb higher, as you wish). And who cares about realism? Still, clearly we have some boundaries, as we have to respect the tower-theme. Making the same type of rooms over and over again, AND making them scary(!) as well, is kinda impossible. Better have a smaller floorplan, and keep some doors locked. Then put some extra love and horror-spices in the available rooms.

However... the game can't be too small either! This is not a linear corridor shooter! Yeah, corridors sure, but forget the words linear and shooter. The type of gameplay involves some monster-chasing, exploration, and puzzling. If the environment is very small and/or linear, the exploration and chasing part won't be very exciting either. The map requires to be a labyrinth, with enough secret places and spaces to hide. How to find the balance?

Braincrackers

As I'm making the first "dummy" (prototype - to be replaced / pimped) maps, I really wonder how much gameplay they will offer. And if they complement the "labyrinth / exploration / scary" components. Maps aren't just random (scary) ideas, they need to forfill those essential parts! And it's very hard to verify that. If you make a World War II shooter, there is plenty of "how-it-should-be-done" reference. Watch “Saving Private Ryan”, play “Hidden & Dangerous”, read “With the old Breed”. But a game like this... Amnesia a little bit maybe, though it's a different environment to begin with (and I never really played that game. Too scary :p).

The labyrinth, hiding and searching part is somewhat doable. Pick a piece of paper or start MS Paint, and make some floorplans. Ensure there are multiple-routes, hard-to-find locations, and think where and how you can block certain paths. Need a key first, need a rope to reach that platform, need a crank to close the bridge, etc. I found this also kinda difficult though. Tower22 is meant to be scary, and therefore somewhat serious. Where games like Zelda or Monkey Island can implement fantasy or ridiculous puzzles ("slap the pirate with a wet towel to get him out of the way"), I'm a bit stuck on real-life scenarios. DoorX needs a key. DoorY too. DoorZ a swipe card... beh, boring. And predictable.

Remember Option3 to extend game-length? Making the game hard? Well, that's another issue. Tower22 should be difficult. But when it comes to combatants... there are none! Or very little at least. You aren't safe in that building, but you won't be throwing Molotov cocktails every 10 meters either. For most of the time, puzzles are supposed to "stop" you. As well as to entertain you. Nothing

wrong with a good puzzle, but if you're only backtracking to find stupid keys the whole time... Yep, the puzzles need to be more creative than just that. Switching my head from rational logic, into weird ingenious braincrackers that can be implemented into a horror skyscraper, is very difficult. In fact, I would love to have somebody helping me on this (so if you have your head filled with ridiculous logic...).

Why do people ALWAYS lose their cranks in games? Why cranks? Honey, can you open the front-bridge? I lost my crank at work.

But other than putting ideas on paper, you need a poor unprepared Beta Tester to check if the puzzles aren't too easy/hard/boring, and if those monster chases work out. Of course. Only problem is... You need a completed map for that first. And if the Beta tester says it sucks, you can redo the whole thing. Fortunately, puzzles or core mechanics like shooting guns or running for a monster, don't require a 100% finished environment. That's why I'm making prototype maps first! Not that it still doesn't take a crapload of work to make those, but at least dropping ugly unfinished maps will hurt less than perfectly looking ones.

Making beautiful maps first, and test them on gameplay later, isn't a wise thing to do anyway. Not only a potential waste of time in case the content doesn’t make it to the final product; you will also get biased. If you put a lot of craft into a map, texture or model, it will stick to you as glue. As you hate to drop your work, modifying maps will mean that you still try to implement what has been done already, even if it really just doesn't fit in the game. Be prepared to throw away "good ideas" like used diapers.

Cabin fever

That introduces yet another problem. The Tower22 main goal is to make you wet your pants. If it does a real good job doing just that, weaker gameplay elements like dumb puzzles, shorter game-length, or stiff controls are forgivable. Man, Silent Hill isn't exactly a *fun* game either. You can't see shit most of the time, and slapping numb bodies with a wooden stick feels really awkward too. But, the game scares you, and the plot is disturbing. That's what you paid for right? Not for boobs, laughs, or slick machete action. You don't buy tickets for Star Wars to see a romantic comedy either. But, how to test if something is scary?

First problem is that, as a developer spending many hours and knowing every triangle and scripted bit, it’s very hard to get spooked by your own product. C'mon, you already know what will happen. And knowing the technical part (and shortcomings), you look at it from a very different perspective. If you and I see a dead body, we're probably like "gross! ". While those CSI dudes are more like "hmmm, hit multiple times by a blunt weapon on the cranium".

But moreover, small maps, big maps, little monsters, huge monsters, that stuff doesn't directly make a game scary. Fear is something... something unexplainable. I mentioned T22 shouldn't rely much on jump-scares. So, buckets of blood and critters jumping through windows aren't going to help us. The key lies within well-done audio-visuals. Jumpy ambient sounds, a bone-chilling soundtrack, corridors with dirty worn plaster walls, an angry lady looking at you from an oil-painting, a claustrophobic atmosphere, unexpected sight-seeing’s... Audio-Visual matter very much for a horror game. Half-finished, untextured ugly looking prototype maps just can't simulate this. Every missing detail or broken bit can completely ruin the experience. In other words, you need a finished environment to test if it's scary. And throw the whole thing away if it isn't. Not exactly effective.

Now (older) Silent Hill games weren't known for superb fancy graphics. But they were consistent. In fact, the foggy, dark-contrast "gritty" visuals made the game so... nightmarish. But if they pulled up the fog-curtain, it suddenly wouldn't be that scary anymore, probably. Consistency my friends.

Need stuff

All in all, putting down the maps is a challenge. The first thing that struck me, are the proportions itself. I made a 80 x 80 square meter boundary for this playable demo. Sounds reasonable for a tower shaped building, right? Fortunately with the new Engine22, I can hit play any time, so the editor launches the real game.exe so you can "walk" (erh, shove like a sturdy bulldozer) through your maps. But using real-life proportions (like a 150 cm wide corridor, 205 cm tall door, or 60 cm deep kitchen block) doesn't automatically result in good results. I was afraid of making the rooms unrealistically large, and the corridors so long that walking through them becomes a boring pain. But testing the actual game, it seems to be the contrary. Nice architectural details like pillars, small height differences or hidden corners are easily overlooked as they are too small. In a matter of a second you already passed them. And it took me only 20 seconds to travel from A to B, which is about 30% of the playable demo area size already.

But before simply stretching the maps, I should note that size can be deceiving. Ever entered an empty new house? Rooms without junk and without measurable reference objects like a table, door, or another human, may appear small. Also bad UV mapping (huge bricks stretched over the wall) will downsize the room visually. Having no obstacles, and a walk-speed being too high, doesn't help either. And of course, tweaking the camera FoV angle –thus having a different perspective- may enlarge or shrink the room. Simply putting the camera 20 centimetres lower ("Toddler view" as one of the guys here once said about the T22 "Radar Demo" ) already makes a perspective difference.

Yet again, it's pretty hard to make conclusions based on empty, unfinished rooms. I believe that simply by doing it, the experience will grow. A list of do's and don'ts, and some well-tuned references should roll out. I'm not looking forward to stretching up the whole demo area though, as all the rooms are connected somehow and packed densely in the available space :(

Expected this corridor to "feel" a lot longer. Is it the unfinished look? Should I increase camera FOV? Slow down the walk-speed? Or do I really have to re-map the damn thing (and shift all neighbor rooms as well)? That's the kind of stuff you probably didn't think about when generating terrific horror-ideas in bed for your game!

Tower22 - 2016

For those not too deep into technical engine stuff; you may wonder where the hell the nice screenshots have been. Once upon a time, I was able to post a few pics (almost) every week. And then... cowboy mouth-organ playing... not much. There’s lots of talks about new engine this, Fuel22 system that, new strategies, and pooh-hah. But, the question remains; You can Talk the Talk, but can you Walk the Walk?

No pics = No good. Usually. Unless we're like Valve working super-top-secretly on Half life3. But no. I certainly won't reveal Tower22 in-game details, but other than that, I'm pretty open about the whole development cycle on this blog. In fact so open, that I'm still planning to release the whole source code + editors. Huh? Where to find it then?

Well, so far nobody really replied on that, and if nobody is dying to give it a try, I'd rather perfect some things further first. You know, putting your baby on the world brings some responsibility as well. Putting people on-Hold forever won't give this engine a boost, but neither does a 3% finished product. And as you may know, finishing 100% is impossible when it comes to writing software. It works like a mathematical graph that climbs very fast at the beginning, then starts to flatten, and never really reaches the 100% target. 99,9 at most. There is always something to fix, to change, to improve, to add. And to drop & redo if you wait long enough.

Anyhow, another year flew by. Our little new born guy went from a never-sleeping crying monster into a walking demolishing monster, and I've been working on the new Engine22 (in a newer Delphi XE3) as well. So, SITREP? Pictures? Good news?

ARRHH *Squeezing* Pressing * Pushing *... And there we have a new Engine22 full-coloured turd. If you blur, colorize and rotate the camera long enough... Then even a quick & dirty dummy corridor like this may do the trick. A little bit.

Thou shall not steal

Let me get back on the pics first. The main reason there were a lot more "back then", is because I cheated, "back then". One of the most important things you'll need to get a 3D scene in shape, is a good pair of socks, textures I mean, and an idea of course. Without proper floor/wall/ceil textures (that nicely fit together as well!), it's pretty much impossible to get any applause. With cheating I mean that I borrowed a bunch of textures from games like Half life in 2010. Allowing me to get somewhere, even without any artists.

Being a good boy with guilt, I knew these assets had to be replaced ASAP with genuine, homebrew, T22 content. But generating a *good* set of textures (seamless, sharp, enough detail, normalMap, glossMap, ...) is an art on itself. I can do some 3D modelling, but textures... Thankfully, some people who saw the first T22 demo contacted me and offered help. Whoopy! Now I could get my very own T22 texture-set, without stealing! And sounds, and better quality 3D-props as well!

And I received some fine stuff indeed. Especially for a hobby game project. Now my goal has never been to defeat John Carmack, or to achieve photorealism. But being able to put the bar high, was exciting. Can't deny, I just like eye-candy. Sure I can play Super Mario with 8-bit graphics, but a horror-game like T22 should look atmospheric and believable at least. This genre simply requires compelling visuals and audio, and relies less on solid gameplay mechanics. In my opinion too many Indy games try to get away with simplistic graphics by putting a "Retro-look, duh" label on it.

That introduced a problem (or two) though. Plus some understanding for the simple Indy graphics. Who's gonna make all those high-quality assets?! Only few guys helped me, and only a few of them REALLY helped me, meaning they could deliver on a more regular basis. Although you can forget the word "regular" here. Somehow, usually only one person at a time, had some spare-time for a week or two. Which resulted in really nice textures/props/sound/drawings. But all in all, the progression tempo was worse than a mobility scooter stuck in a trench.

So there you are. Thou shall not steal anymore, albeit thou won't get new awesome assets either.

And I'm waiting, waiting... waiting for a world to change. But it doesn't change, and I can't blame

the people helping me. They have their own things going on, and especially when putting the quality-bar so high, it takes them a lot of energy to produce those assets. On top, you won't find a lot artists that are willing to share that degree of talent for free either.

You may recognize some HL textures in this old Tower22 shot... Although I did make the TV & glass thing (and map geometry) myself. But yet another problem arises here; it was good enough in 2010, it stinks in 2015. That damn bar keeps lifting itself up. Help!

Fuel22 Strategy

Time to re-evaluate strategies(one year ago). Money. Lead. Guidance. Targets. Tools. Money. Those were the missing chain links. Indy and no money, ok. But high-quality, lots of work and no money? That's a no-no. There are ways to generate some money. Crowdfunding, Kickstarter. But before heading that way, I want some guarantees. I won't announce a super-turbo-project without some basic team & fundaments first. But... how to get a team/artists first, without money? Chicken & Egg story. That's where Fuel22.net came around. I won't explain in too much detail here (has been done before: link). But in short, it’s a webshop. Hold on! A little bit different compared to other existing (big) ones though. It has a planning component that should tackle a couple of the other weak spots; Lead, Guidance, Targets. You see, the idea of this webshop is not to get rich, but to accelerate development. Listen up.

You can hire a bunch of skilled construction workers, but without blueprints and supervision, they

won't do shit except whistling at girls. Instead of mailing artistX, asking if he or she can make a medieval sofa "some day", pretty please, I'll put these tasks + explanation on the webshop. Now basically anyone can (try to) make it. This way it gets more clear what has to be done. And non-secret tasks could be viewed by any visitor in the shop as well. So if you feel you can bake that pavement texture or record crying monkey sounds; be my guest.

BUT, once accepting a task, the clock starts ticking. If you deliver bad work, or not in time, the tasks gets rejected. No more computer-crashed, dog-ate-my-homework, girl-got-pregnant, too-busy-with-FIFA17 excuses. Fuck that, I'm trying to make a game here, don't waste my time if you can't help. But also -fair and square- you get your money reward in return if you did a job well-done. Your asset will be bought via the Fuel22 webshop. By me. And hopefully, by some others as well. Most of the profit shall go directly to the artist, and a small bit goes back into the T22 depot, so I can keep buying stuff from my artists. Hence the name "Fueling"(22). Good for you, good for me.

Will it save Tower22? Who shall say. But some structure and reward(& punish) system is better than nothing at all, right? Only problem is... once again, I'm relying on some charity here. A guy is making this website for me, for free. So, you'll get the usual computer-crashed, parrot-shat-on-homework, floppies-missing excuses. Nah, just teasing. But yes, it's taking too long. Probably I just shouldn't be so picky, and pay the guy. Or let somebody else do it (you know anyone?). For money. In 2016 it's time to kick-ass and chew bubblegum, not to keep waiting forever.

Engine22 - 2.0

I wasn't too much in a hurry last year though. Put T22 in a dormant state, and focussed on rewriting the Engine + Tools. Because that's the other side of the coin. If Fuel22 was finished today, and some artists would be happy to help tomorrow, then... then what? To use the Construction Workers example again, if we have 8 handy hairy bulky chaps on the site tomorrow, you'd better have your materials ready as well. Bricks, hammers, drills, cement mixer... If you don't, they’ll walk away angry again.

One of the problems with the previous Engine/Tower22 build, was the lack of "do-it-yourself" tools. I spent a lot effort in explaining the wishes, helping, and reviewing their work. That wasn't the issue. But they didn't have the Map Editor or game executable. Basically they modelled/painted something in Photoshop, Blender, Maya, Max or whatever program- sent the raw files to me, and then a day later I returned some screenshots + comments. In times where any hobbyist can download Unreal4 and develop & test, this just isn't a playful, efficient, motivating way to get things done.

It's not that I didn't want to give them the tools, but these programs were error-prone, not very user-friendly, and a (proper working) game.exe was missing. Reason? 95% of my energy went into graphics, and trying to complete demo movies (myself mostly), instead of gameplay mechanics, user-friendly editors, and other ingredients a game needs. That had to change. And that was one of the reasons to redo the engine + tools, as well as to open up the source for you guys. Of course I'm a bit afraid people may steal my ideas or code. But then again... What can they steal really? As long as Tower22 isn’t much more than a few demo movies, there isn't much to steal to begin with. Why transform your home into a fortress, if there aren't any visitors?

Maybe I should try to get some visitors (back) first, and loosen up. So, what did 2015 bring us? Some pictures finally?! Well, as I was trying to explain, without any artist input (except for Cesar Alvares audio-track on the Subway demo movie, thanks man!) this year, there aren't any new rooms to show either. Not that aren't new rooms though. In fact, I began modelling the environment for a real playable demo a few months ago (yes, a downloadable & playable demo is the next station, no more movies!).

But those are "placeholder" maps. That means I do a quick & dirty first version, mainly to show how & what, and to test some proportions and geometric shapes. These maps are filled with "hints" (kinda cool new feature if you ask me). I can place text & pictures or website links in my dummy maps. Then a real artist will fly through these maps later on, look at the hints, and replace the ugly textures, poor maps with professional content. But in other words, the new environments pumped into the new engine so far, suck:

I warned you. It's up to the artist to transform this "bunker" into a real room some day, as shown in the hint sketch.

And no, a new engine with fancy shaders won't save the day either. In terms of visuals, the new engine doesn't have very obvious improvements anyway, except that things are done better, easier, smarter, and also faster (FPS went from ~20 to ~55 on my laptop, though it will drop again when more is added, I'm sure). In fact, quite a lot features from the old engine, like particles, water, DoF, or real-time reflections didn't make their way back into the new one yet. But to give you an idea nonetheless:

OpenGL 2.x --> OpenGL 4.5+
Cg Shaders (dead) --> GLSL
OpenCL Compute Shaders --> GLSL
Custom parameter system --> Physical Based parameter system
Lambert & Blinn shading --> Lambert & Cook Torrance
Baked probe lighting (for GI) --> LightMaps + IBL probes + influence maps for semi dynamic lights
SSAO --> SSDO
RLR + 1 realtime cubemap (for reflections) --> RLR(realtime) + IBL probes (static)
Shitty HDR --> Better HDR (better color balance)
Fake parallax (POM) effects --> True tesselation shaders & POM
Deferred lighting --> Tiled Deferred lighting
Simple linear fog --> Fog with light volumes
Layered materials (with Vertex Painting)FXAA Anti Aliasing 

Furthermore (todo) Light-beams ("volumetric fog") via raymarching, Water mirrors, RLR (realtime local reflections), Compute Shader particles + editor (rebuild old system into GLSL), DoF, Lensflares post FX, Sprites, Cascaded ShadowMaps for long-range lights...

Alpha Beta Test

In potential, the new engine should look better. But it's hard to compare at this point, without having a "finished" room & PBR compatible textures. Also, the old engine was tweaked and understood (by me at least). The new engine is still bare-bones, and especially the Physical Based approach may need some time getting used to.

But as said, I tried to focus more on other parts. Graphics are cool, but dated quickly, and not mandatory in such an early stage either. More important is to provide a *working*, fun editor for the artists this time. With a game.exe so they can actually run through their own creations. Therefore the main improvements aren't in the graphics section so far, but in game mechanics like LUA script support, the code fundaments and Map Editor. I can honestly say the map editor feels a lot better, and also the fresh, new, cleaned up code is a huge relief. It just smells more pleasant overall. There is still a lot to do, but adding new features just goes a lot quicker and cleaner, compared to previous work. On the longer term, it should pay back.

Just as important as "looking good", is how to get there. Picking entities, UV-Mappers, shortcut keys, easy to follow buttons/symbols, import/export tools, quickly previewing things, and so on.

Maybe more interesting for you; I "released" the Map Editor one week ago. Not to the public, but to an artist. And I need one or two more artists extra. Before I invite the rest of the world, I want some artist feedback first. I'm pretty sure he can crash the whole damn thing in ways I could never imagine, and instead of trying to code *everything* at once (which is impossible of course), I'll do things on demand. If he says "Rick, these shadows look like puke!", or "Really need some bloody particles here!", I'll give that priority. If he can make some cool-looking Tower22 rooms (for the playable demo btw) with it, we're back in business. Till then... Erh, play some other game ;)

G.I. Engine22

Not the first time I write about Global Illumination... and probably not the last time either. Following traditions, the GI system changes every 8 months or so. Realtime, not realtime, Voxels, Probe grids, mega-fake-awesome GI, and so on. Make up your mind man!

I think I made up my mind this time... although, we'll speak again 8 months later. But for now, I think I got it: Good'Ol fashioned lightmaps.

Say what?! Lightmaps?! It's like NASA bombastically revealing they'll pick up the 1961 Apollo space program again. Lightmaps is like taking a step backwards, to Quake1 or something. You'd better have a damn fine reason to justify this son! And yeah, I do have a reason or two. And if you ask big-boy engines out there, they may come up with the same story. Remember Unreal4 announcing it has true realtime GI, using Voxel Cone Tracing? Finally! But... without saying much, it suddenly disappeared again, not much later. Again, why?!

A Pixel Trade-off

When doing business, there is always this thing called "ratio". Do we supply our new model car with state-of-the-art, but super difficult plasma-driven transmission? Or are we fine with a Volkswagen engine + some cheatcodes? Do we put our precious best-man on this job, or do we give that cheap intern a chance? Chose older but reliable components, or take a chance with new fancy ones? Spray prince Abdul's private jet with real heavy gold, or apply fake gold and keep the thing flyable? Bottom line is, you can't always pick the fastest, safest, most beaty, most elegant, most awesome route. Quantity versus Quality. Price versus Beauty. RAM memory versus CPU performance. Possible versus Impossible. Titanic lifeboats versus a classy ship.

As for Global Illumination -the art of having near-realistic lighting, including indirect light- always boils down to a performance, do-ability, and quality pay-off. One way or another, getting there will eat a serious piece of memory and/or performance for sure. The solutions I have seen and tried don't score very well in terms of "do-ability" either. Usually it's so complex, constrained and relying on approximations, that the outcome is hard to predict and even harder to modify to the artist taste.

But that would be OK, if the quality was, well, OK... but it isn't. Not that they all look bad; certainly VCT was/is promising. But the thing is, gamers are spoiled with semi-realistic lighting for many years already. I'm not talking about dynamic lights (sources that switch, move, dissapear, change, ...), but just about a static scene where the light acts as expected. Darker in the corners, yet not pitch black. Blueish "skylight" falling in from above or through a window. Small gaps and holes feeding atmospheric bits of light into an otherwise dark bunker. Glossy reflections on the floors, but also walls and organic objects.

Halflife2 already had that stuff. On a lower resolution maybe, and yes - all static. But hey, 90% of the environment and lights you'll see in an ordinary game doesn't move or change anyway. Besides, who cares? You as an ambitious programmer maybe, but the average gamer has no clue. And although I actually knew the difference between pre-processed lightmaps and realtime (Doom3 back then) lights, I never thought "Dang, I sure miss some dynamic lights in this game!", while playing Halflife2.

I should stop about "the old days" with Half life2. So, here you go, Portal 2. A bit younger, yet still using ancient lightMaps. But admit, this looks pretty cool right?

But Rick, that was more than 10 years ago again (holy shit). True. But believe me, most of the stuff you see in games is still very static, pre-baked lighting/reflections. Higher quality though. More video-card memory = larger lightmaps = sharper textures.

Now, if Unreal4, CryEngine, Engine22, or whoever abandons pre-baked lighting, and introduces true realtime lighting today... The quality is probably worse than Half life2 from 10 years ago. “Yeah, but its realtime! Look, the indirect light changes if we open or close the door in this room! The ceiling also brights up if we shine our flashlight on that wall in the rear! No more waiting-times for the artist while baking a lightmap!” Cool and the Gang, but again, gamers don't know / don't care. They WILL complain about low-resolution lighting, artefacts, and the ridiculous system requirements though!!

Who am I to say gamers don't care about realtime lighting? That's not entirely true. Features like day-night cycles, local lights also illuminating around the corner, and destructible environments that adapt correctly sure does matter. But, we can fake these things! That's the point. Gamers don't care whether you applied a lightmap, VCT, a realtime photon-mapper, or a brown shit-tracer for that matter. Just as long it looks GOOD, and runs GOOD on their rigs. That's what matters.

The trick is to make a hybrid system. Good old high-quality lightmaps(or probes) for your static scenery -WHICH MAKES UP MOST OF THE GAME!- and realtime hacks for dynamic objects. The latter usually relies on lower-quality, cheap tricks (and that hurts us proud graphics programmers). But we can get away with that. Because dynamic objects are usually relative small (puppet versus building), tend to move a lot, and -I repeat- they only make a relative small portion of the entire scene.

Back to lightmaps then?

It took me quite long to get over this. Lightmapping is a technique from the previous century. So much changed, but we still rely on that old crap to do some decent lighting? It sounds unnatural, and having to apply weird tricks to get the dynamic objects (monsters, barrels, cars, trees) litten as well sounds crappy. This is why I kept investigating real-time techniques. And I'm probably not the only one. Lots of papers out there. CryEngine tried Light-Propagating-Volumes, Unreal4 focussed on Voxel-Cone-Tracing for a while, and so on. But the truth is… nothing beats the old lightmap.

So, while upgrading the Tower22 engine, I wanted to make a more final decision on this one as well. For me it's fun to screw around with techniques, but now that I'm trying to get some tools working *properly* for eventual future Tower22 artist, I really needed something robust. Now artists probably dislike lightmaps for their long build-times. But at least we all know how they work. Like women, can't live with them, can't live without them. If the end results is satisfying, and if the artist has sufficient control over it, lightmaps are (still) an accepted tool.

Nice realtime results. But smart professors please; get the fuck out of that stinky Cornell Box. Games take place in open worlds, with dinosaurs and robots running around, with many more lights. 5 years ago realtime G.I. was within reach, they said. I bet we hear the same story 5 years later. Or at least 8 months later ;)

Engine22 Implementation

Don't know what other engines are doing exactly, but 2015 Engine22 Lightmaps are slightly different than the old nineties-maps though. Yeah, there is some progress at least :) Old lightmaps have a few major issues:

·         They are static! If we switch on/off a light, they don't change!

·         They are useless! to dynamic objects like characters, boxes or furniture that can be moved

·         They are flat! NormalMapping requires more info than just a colour.

·         They are ugly / blocky!

Ugly?

The last point is semi-fixed by the amounts of memory we have available today. More memory = larger lightmap-textures = sharper results. But I say semi-fixed, because STILL, you can see "blocks" or dots sometimes. Real-time techniques like shadowMaps are much sharper in general, because they concentrate on a small area or don’t use stored data at all.

Another little problem is streaming Lightmaps. Old quake or Half life maps were loaded one-by-one.

A game like GTA, Fallout or Tower22 is free-roaming though. No small sub-levels, but 1 huge world. In Engine22, each entity (a wall, pillar, floor, but also a sofa or cabinet that never moves) has its own small lightmap. Resolutions are adjustable per entity, but think about 128x128 pixels or something. When a new map-section is loaded, it will also load the lightmaps as separate images (though they are packed together in 1 file).

A little extra advantage of having separate, small lightmaps, is that the artist can update a local entity only. Click the floor, change some properties or move a lamp, and then re-bake the floor only. Obviously a lot faster than having to re-bake the entire room/scene.

But since GPU's like to batch as much as possible, hopping between lots of separate textures sucks. So, currently, after being loaded, lightmaps are stuffed all together into 1 huge "Atlas-Lightmap" texture. This happens dynamically - subcells of this atlas come and go, as new map-sections are loaded and dumped on the fly while the player moves. Downside of an Atlas texture however, is that the lightmap as a whole is still limited though. So, I might change strategies here.

Atlas showed in the corner... The red space reveals we didn't have a lot of guests at our party. Waste of space really. But keep in mind the scene is still very empty (and ugly).

Flat?

No boobies with lightmaps. As said, normalMapping techniques need to know where the light comes from. From the left? Right? Both sides maybe? An old style lightmap only contains a RGB colour; light "power" that (indirectly, after a few bounces eventually) stranded on that patch of surface. It doesn't remember where it came from though. Problem is that there are infinite possibilities here. If there were 20 lights, light could come from 20 different directions. And even more really, if you count the indirect-bounced light as well. A direction can be stored as a RGB (or even RG) colour into a second texture. But 20 directions? You’re asking too much.

Half life2 "fixed" this with "Radiosity NormalMapping". Difficult words, but the clue is that they simply generated 3 lightmaps instead of 1. One map containing light coming in globally from the bottom-left. One map storing incoming light from the bottom-right. And a third one for light coming in from above, thus mainly skylight or lamps attached to the ceiling. While rendering the game, each pixel would mix between those three lightmaps, based on its pixel-normal. Voila, normalMapping

alive and kicking again. Not 100% accurate, it's an approximation. But at least a brick wall doesn't look flat anymore.

A very, VERY old shot. Actually the very time I tried lightmaps in 2006 or something. Nevertheless, old techniques still seem to work.

I considered using (and still consider) this as well. But... having fairly large textures plus some more other stuff I'll explain later, the memory consumption may rocket-launch. Instead, Engine22 does it even simpler. Dirtier, I might say. Only one additional texture is used, storing the "dominant incoming light direction". So, wherever the most light comes from (typically from above in the open air, or from a window), that direction will be used for normalMapping. It's even less accurate than the Halflife2 approach. But, since E22 doesn't use a single lightmap with just one direction only, the final result will get mixed with other influences as well, making the lack of directional information very hard to tell.

There is one stinky problem though. Transitions from light-to-shade will generate an ugly flattened "band" in between, where the normal bends from one direction to another

in all of a sudden. Didn't find a fix for that yet.

Not saying accuracy can kiss my ass, but the thing with indirect-light is... it comes from all directions. Which makes the overall normalMap effect somewhat "blurred" and hard to verify its correctness. Just as long we see some shades and highlights, we're happy. For now.

Static?

Now the biggest challenge. I mentioned that 90% (just grabbed a good-sounding number here) of game-scenery is static. But how about that other 10%? Ignore it? That wouldn't be a very humane thing to do.

This problem splits into two parts. First of all, lights can change. Sky turns from day to night. Room-lamp switches on and off. Second, dynamic objects can't use lightmaps. Sure we can bake a correct, high-quality lightmap for a rock-object. But as soon as we roll over the rock, the lightmap is wrong. It would have to be re-baked, but that is (WAY) too slow.

Engine22 solves the first problem in multiple ways. For one thing, lights can be fully dynamic, updating its shadowMap every cycle. But the consequence is that they do NOT generate any indirect light. A source like your flashlight will not get involved at all while baking a lightmap. Simply because we never know if & where that flashlight will be. An ugly, yet somewhat effective hack is to add a secondary, larger, weak pointlight to our flashlight. This way the flashlight still illuminates the surrounding room a bit, also outside its primary light-cone.

But more interesting are Stationary lights. These lights can't move, but CAN change colours. Which also means they can be turned on/off (putting the colour on black = off). They can optionally still cast cast real-time shadows, so dynamic entities like our hero will cast a correct shadow on the ground. The lightmap works different for these stationary sources though. It won't capture the incoming light direction or colour - or what's left of the light energy after some bounces. Instead, it only stores the “influence factor”. From 0 to 100%. A RGBA image can hold up to 4 factors this way. Each entity can be assigned to 3 Stationary lightsources, and we reserve the Alpha channel for skylight, which might change as well if you have a weather-system, or day/night cycle.

So this way we have indirect light, and still the ability of switching sources on/off, or playing around with their colours. However, only 3 sources per entity could be a limitation in some special situations (yet the easy way to solve this is simply by dividing a large floor-entity into smaller sections typically). And, it does not support colour-bleeding. If white skylight bounces off a red wall, the surroundings should turn slightly reddish/pinky as well. But since we store an influence factor only, that effect is lost. It is active when using fully static lights though.

Green stuff = skylight. We don't store "green", but just a percentage. So if the sky turns orange, so will the green stuff on the walls and floors here.

Useless for dynamic objects?

As for that other "static-issue", well, that still is an issue. LightMaps are useless for anything that doesn’t like to stay put. Engines often fix this by generating additional probes. Think of small orbs flying in the air, forming a grid together. Each probe would capture incoming light from above, bottom, left, right, et cetera. Same principle as a lightmap really, except that these probes do not block or bounce lights. They capture, but don't influence light photons.

I did this in the older Tower22 engine as well, see this movie

                Youtube Tower22 Subway Test

Works pretty well, but as usual, there are some problems. It's hard to see due all the stuff going on (and blurry video quality hehe), but if you focus on the far background in those tunnels, you'll see some light popping in/out. That's the probe-grid moving along with the camera. The problem with an Uniform 3D grid of probes, is its size. Even though a single probe only contained 6 RGBA values here (can be done smarter with Spherical Harmonics btw), the total amount of probes makes it big. I believe a 128x128x128 Volume texture was used in that demo. Or actually 6 -one for each 3D cubemap-axis (up,down,left,...). So do the math:

                128^3 x RGBA8 x 6          = 48 MB

The grid density was 0.5 cubic meters or so. So, the grid would only cover 64 cubic meters. And since it was centered around the camera, you could only see half of it, 32 meters, forward. All stuff behind those 32 meters didn't get appropriate data.

So much megabytes, and the painful part is that 90% (again, just throwing numbers) is vacuum-space. If no particle or solid entity is placed there, actually sampling the probe, it’s an absolute waste of space. Another awful issue are probes placed behind a wall. The engine tried to eliminate that as much as possible, but still it happened in some situations. It would cause light from a neighbour room -or worse, skylight- to "leak" into the scene.

New Engine22 uses a different approach. The artist will place probes wherever he thinks they should be placed. Typically that is somewhere nearby a bunch of entities, in the middle of a room, along a corridor path, behind windows, or in dark corners. Placing probes sucks, it’s yet another thing the artist has to bother. But the result is FAR less probes... Which allows us to use all those megabytes in more useful ways. Like storing additional information for Stationary lights... Or Reflections. Engine22 uses "IBL", Image-Based-Lighting. Which is fancy talk for just using pre-baked (but high quality) cubeMaps for local reflections. Again, the static vs dynamic issue arises here. I won't explain in detail now, but E22 will mix static reflections with real-time ones, IF possible. So, now that probes are also used for reflections -something that pays off in a more clear, direct way- the extra effort to place them is somewhat justified.

All in all, as you can see, Engine22 doesn't use a single technique for Global Illumination. Lightmaps here, ambient-probes there, a bit of SSDO on top, IBL reflections in the mix, and so on. From a programmers-perspective, it’s a nightmare, making a solid system that uses all those fake-hacks in harmony. But it works. Sigh.

A probe was placed in the middle of the corridor. It gives glossy reflections to the floors and walls, and also provides a small (convoluted) cubemap containing "Ambient" for all incoming directions. The Heart object uses probe-GI, instead of a lightmap. Additionally, SSDO (a screen-space ambient occlusion technique) adds some local shading in- and around the object, as well as on the wood-floor gaps and such.